Re: bugs -> release milestone policy

[Luis Villa <louie ximian com>]

Detailed responses to both emails shortly, but how does the keyword
change sound:

current keyword->new keyword
GNOME2.0->VER:GNOME2.0
GNOME2.0.[1|2|3]->MILE:GNOME2.0.[1|2|3]

GNOME2.1.x->VER:GNOME2.1
GNOME2.2.0->MILE:GNOME2.2.0

etc. sound? Would that make things more clear? [Early morning,
just-got-out-of-shower brainstorm.]

Luis

P.S. I've been looking through bug_squad noted bugs; they're pretty
consistent so far (though too small in number) so I think 'triaged' is
going to go away today in favor of bug_squad. Sound reasonable to
everyone?

On Fri, 2002-10-25 at 18:09, Andrew Sobala wrote:
> On Fri, 2002-10-25 at 21:44, Dave Fallon wrote:
> 
> <snip>
> 
> > 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.
> 
> Bug squad members should be able to set priority quite accurately with a
> bit of experience. Luis posted some meta-guidelines last month IIRC.
> 
> > * keywords, filling in the appropriate ones
> > 
> 
> duplicates!
> ...
> 
> > 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?
> > 
> 
> In a happy utopian star-trek bug squashing future, the people on the
> qa-maint alias for a module should have a good overview of a module
> (although I don't know how many QA maintainers there are yet). In this
> world, you should add a comment to a bug, the QA maint should see it and
> be in a position to make that decision.
> 
> We will never be in a happy utopian blah blah blah.
> 
> Most of the time adding a comment to a bug works anyway. gnome-bugsquad
> should be able to answer most other questions because there are
> experienced bug squashers on it. (Sometimes a bug needs an expert
> developer opinion. But it's difficult to start to add people to the Cc
> and say "What do you think?" because they may not be the best person to
> ask, and also a standard list of contacts can't be used by the bug squad
> because the people on it could get flooded by requests for advice. Which
> in some respects is not what they are paid to do, and in others are not
> what they have time to do.)
> 
> > > >  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.).
> > 
> 
> A crasher with >= about 5 duplicates is serious.
> Things not working are serious.
> 
> AFAIK, the GNOME method is:
> 
> 1. 2 months heavy hacking
> 2. 2 months stabilising
> 3. Release!
> 4. 2 months tiny fixes turning into 1) above
> 
> We're at 1. We reach 2 when we hit the UI freeze. When we're at 2, bug
> triaging gets more important because we need get all the crashers and
> missing functionality bugs fixed by 3. Probably a good idea to use the
> GNOME2.1.x keyword for 2.1 crashers and missing functionality at that
> point unless we hit a different keyword scheme in the meantime.
> 
> > > 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.
> > > 
> 
> This is quite important. At the moment, GNOME2.1.x (the keyword) is
> defined in bugzilla as "Should be looked at for 2.1.x, but do not add
> this keyword if this can be fixed in 2.0.x." This sucks, because bugs
> that should be fixed for 2.2.x but are not string changes don't have a
> keyword. At all.
> 
> Maybe GNOME2.1.x can start to mean "Maybe this should *really* be fixed
> by GNOME2.2.0"?