Re: bugs -> release milestone policy

[Dave Fallon <davef tetsubo com>]

On Wed, Oct 23, 2002 at 11:16:05AM -0400, Luis Villa wrote:
> On Mon, 2002-10-21 at 20:30, Dave Fallon wrote: 
> >  My thoughts on this so the discussion has a
> >  place to start:
> 
> Thanks for starting it :)

:) No problem, although it looks like I started in the wrong place... Which only emphasizes the benefit of getting this all hashed out.
 
> > 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? 

Probably the easiest way of dealing with it. So, rather than what we shouldn't target, what things should the bugsquad be changing, and to what?

* NEEDINFO or not, if the bug is useless at face value (crasher without stack trace, no version info).
* Version, to correct the version info as necessary.
* OS, although we never bother with this for 90% of the bugs.
* Product/Component, if it's obviously wrong.
* Priority? Only if it's obvious? (crasher/feature request) Same for Severity.
* keywords, filling in the appropriate ones

Okay, well, I guess we're back to "what not to do", since the only one I haven't listed is target milestone. So, that one doesn't get changed, except by...?

And of course, the other issue is there's lost of "changable, if it's "obvious"" notes above. Who do we get to deal with the non-obvious bugs, and how? The sr. bug squad folks, being louie, jfleck, kmaraas, others? What's the process to get an expert opinion, add a cc, or just comment and hope you see it? Or email bugsquad?

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

While it's not necessarily important for the bug-squad to be involved with the decision on what is a must fix, and what isn't, it's quite important to understand the process to come to that decision, as obviously all our attentions should be focused on the must-fix bugs first (getting info, trying to duplicate, etc.).

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

Hmm... That makes sense, although I'd probably prefer as a developer to see the whole thing, so I can target all the bugs in a group (this week, I'm working on the sidebar, so I'll try and fix all the sidebar bugs in one shot). This seems more useful than bouncing back and forth between different sections of the code, trying to get the must-fix list finished. However, note I'm not a developer. :)
 
> > 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.

Not reversed, so much as put higher importance on the priority classification than we're going to. Entirely reasonable, and good to know.

> 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 :/

sigh. yeah. Hopefully, hopefully. :) I can read email/whatnot at work while doing other stuff, but my boss would be annoyed if I started coding on other projects.

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

Well, a few more rounds of comments, and you'll have most of it... :)