bugs -> release milestone policy

[Dave Fallon <davef tetsubo com>]

On Mon, Oct 21, 2002 at 06:16:57PM -0400, bugzilla-daemon widget gnome org wrote:
> +------- Additional Comments From louie ximian com  2002-10-21 18:16 -------
> +FWIW, John, given the main theoretically 'high' bugs still left, I
> +don't think we should be putting anything on the 2.0.x milestone that
> +isn't extremely important. Probably something that needs to be
> +discussed on bug-squad a touch.
 
s/main/many/, I presume. My thoughts on this so the discussion has a place to start:

I think the best way to use bugzilla + milestones, given our (for the most part) "fix what seems fun/interesting" mentality, is for the bug-squad folks to milestone bugs into the next two releases, the stable and unstable branches. Bugs that are actual fixes (crashers, translation problems, other errors) all get targeted to the stable branch. Anything that smells of an enhancement, or is too big of a fix to be in the stable branch, gets targeted to the unstable branch. There are various exceptions to this, as there are for all good rules, but for any questionable ones, email the bug-squad list so we can all discuss. These lists then get prioritized by severity, with the bugsquad folks taking first crack, followed by the release team for particularly important bugs, and ultimately by the maintainers (although for the maintainers, I'd assume they'd spend less time prioritizing bugs and more fixing the ones the care about, and ignoring the others).

This behavior is focused on the goal of providing users/maintainers with a list of what *could* be fixed for a given release, rather than what should. The downside is there's no should-fix list for everyone. That's a valid concern, and I have two responses - the should-fix can be generated after the fact by getting all the resolved-fixed bugs fixed between the releases. Second, the reality with our development cycle is  people fix what they can, and ignore the rest. There are a variety of "must-fix" type bugs punted every release, simply because we don't have unlimited time. This becomes especially more true as we move to a schedule-based development cycle (2.2 in 6 months? whatever it is), rather than a feature based cycle.

The other downside is the bug list can become overwhelming as under this plan, nautilus (for example) might have hundreds of 2.0.x bugs to fix. Here, this should be dealt with by prioritizing the bugs decently.

Note this is semi-contradictory to louie's original discussion point. And it's "semi-" only because I don't know if we're at the point where the 2.0.x series is essentially done, barring critical fixes. If we're there, then everything becomes a 2.1.x bug, basically. Anything "way-out-there" should be de-prioritized rather than punted to 2.3.x until we get to feature freeze.

So, food for thought. Comments?

dave