This post originated from an RSS feed registered with .NET Buzz by Eric Gunnerson. Original Post: How a bug becomes a fix... Feed Title: Eric Gunnerson's C# Compendium Feed URL: /msdnerror.htm?aspxerrorpath=/ericgu/Rss.aspx Feed Description: Eric comments on C#, programming and dotnet in general, and the aerodynamic characteristics of the red-nosed flying squirrel of the Lesser Antilles Latest .NET Buzz Posts Latest .NET Buzz Posts by Eric Gunnerson Latest Posts From Eric Gunnerson's C# Compendium

Anonymous Corporate Coder wrote a comment on my ZBB post, asking what set of bugs ZBB relates to.

I started to update that post, but it quickly expanded, so I've decided to write a separate post.

We're organized around a milestone approach. Some milestones are date-driven, some are quality-driven, and some start as quality driven and change to date driven.

As we code through a milestone, all bugs belong to that milestone, and as we start to push towards ZBB, we will be tracking all those bugs. At some point along the march to ZBB, we will start moving some bugs to a later milestone if there is one, or postpone them for this product.

Whether a bug gets moved or not depends upon a lot of factors. If we're quality driven, we will punt fewer bugs beyond the milestone. If it's the last milestone of the product (RTM), we punt fewer bugs. We have an elaborate way of describing whether bugs are fixed or not (Gus, if you're reading this, how about a post on bug bars?).

That will get us to a set of bugs we believe should be fixed in a specific milestone, and we drive to get that fixed.

On the C# compiler team, we try not to punt bugs, especially if its the last milestone.