Re: bugs -> release milestone policy

[Luis Villa <louie ximian com>]

On Mon, 2002-10-21 at 20:30, Dave Fallon wrote: 
> 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.

Yes. Thanks.

>  My thoughts on this so the discussion has a
>  place to start:

Thanks for starting it :)

> 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.

In general it is not the bug squads job to target things to milestones
at all. :) I've been meaning to write something up for this but haven't.
Here's what I did in the runup to 2.0:

*Is the bug in GNOME2? if yes: add the GNOME2.0 keyword.
*[triage normally, including priority]
*If high priority or greater, add either GNOME2.0.0 or GNOME2.0.x.
[i.e., we can't ship without this, or we can.]

Currently there aren't 'in GNOME2.1 but not 2.0' and 'in 2.0 but not
2.1' keywords. I'm not sure how best to do that- maybe just separate
keywords for each, and if it has both, then it has both? 

>  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. 

Definitely.

> 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.

I'm afraid I'm not clear on what you mean here. 

>  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.

That's incorrect, for a couple of reasons. The idea is that if there are
true must-fix bugs that aren't fixed, we'll ship the last version. If
it's not a true must-fix, then it's not a true must-fix. 

Secondly (and most importantly), it is our job to focus developers on
the most important bugs. So if we're giving them a huge list and saying
'fix what you can' then we've failed. We need to provide them with a
focused, targeted list that actually has meaning, not a giant
smorgasbord.

> 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.

I think you've got things reversed. Priority is the 'rough grained'
tool- milestones are the fine-grained one. i.e., for a given release,
you don't say 'fix all high priority bugs.' You say 'fix all bugs on
milestone X.' where milestone X is a subset of the high priority bugs.

This confusion, I think, stems from keywords being used for both
versions and milestones.

GNOME2 is a version. Everything in GNOME2 should have that keyword.

GNOME2.0.1 is a milestone. Only things that really, really should be
fixed by 2.0.1 [or whatever] should have that keyword.

That's terribly unclear, I'm afraid, and part of why we need to get the
upgrade done :/

> 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.

We are. If it's not critical, 2.0.x basically shouldn't be touched.

Hope that clarifies a bit- clearly, I need to make like an 'advanced
triage guide' that makes this more step-by-step :/
Luis