Everything you want to know about Visual Studio ALM and Farming
Brian Harry is a Microsoft Technical Fellow working as the Product Unit Manager for Team Foundation Server. Learn more about Brian.
More videos »
Well, I'm going to try to beat a new path here. We're trying to be more transparent about what we are doing, when we are doing it and why we are doing it. The downside of that can be that we go to far and get beaten over the head with the information we provide :)
Historically, we (DevDiv) haven't released detailed information about what bugs we fix in various releases. At some level it's one of those things that has been around long enough people don't even wonder why any more. I can speculate that it's partially because it's too much work to pull the information together. I'm sure there's a little bit of fear of the "How could you have possibly shipped with that bug" or "... that many bugs" response. It's hard to put bugs in perspective and it's hard to explain in a reasonable way and without a lot of effort all of the conditions that must be in place before a bug is hit.
Well, I'm going to put my head in the noose. I guess you can kick the stool out from under might feet if you like :)
I don't have the bandwidth to document a good customer consumable description of each bug. This list is taken from the titles and areas of the work items in our TFS dogfood server. Not all of them are bugs - some are features. And not all of them matter to you - some are internal infrastructure issues or issues fixed in the SP patching process, regressions introduced by other fixes, etc. I hope the titles are good enough to give you a flavor of what we have done.
One acronym worth understanding is DTS. It stands for "Days To Solution" and represents a bug reported by a customer (either externally or a user of our internal dogfood servers). The term "Days To Solution" comes from the fact that we track how many days it take to resolve the customer's issue.
Server Integration and Admin
Source Code Control
Work Item Tracking