Re: bugs -> release milestone policy

[Andrew Sobala <andrew sobala net>]

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

-- 
Andrew

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GS/M d--(-) s: a17 C++(+++) UL+ P++ L+++ E--- W+>++ N(-) o? K? w--(---)
!O M V-
PS+ PE Y+ PGP+>++++ t@ 5-- X- R tv-@ b++++ DI+++ D>---- G- e- h! r--- y?
------END GEEK CODE BLOCK------