Re: bugs -> release milestone policy

[Luis Villa <louie ximian com>]

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.

I think what you said, Dave, and Andrew snipped (about what /not/ to
change) is pretty much correct- reasonably experienced bugsquaders
should probably be setting just about /everything/. :) 

> Bug squad members should be able to set priority quite accurately with a
> bit of experience. Luis posted some meta-guidelines last month IIRC.

Yah. It's not rocket science, though consistency is very important, and
that is going to be much harder to get.


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

Well, ideally, in the Near Future, everything that goes to me directly
(as opposed to an alias I'm on) will get my attention that same day. So
that's one possible solution. Other solutions (I'm open to suggestion on
this one) would be #bugs or this list, or a special alias open only to
experienced bug hunters. I think this list is probably the best place,
if the volume is low- I want everyone to see/read/absorb, I think.

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

We'd better come close soon ;)

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

So are, say, i18n, and a11y issues. We're not yet very good at balancing
these things, though. 

> 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

Something like that. :)

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

I'll discuss this in the other sub-thread.

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

If that's what you want as a developer, there are many, many options on
query.cgi :) One can easily ignore 'our' keywords and make your own
assessments. 

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

Yeah. Clearly I need to write all this out a bit more- like, would a
step-by-step 'how developers should read what Luis does' guide be useful
to us as well? The way it worked in 2.0 was that a /lot/ of how
keywords, etc., sat in my head, developers said 'what is important to
fix next' and I produced a list or url based on what was in my head, and
it was never made explicit. 

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

Hey, Dave, that wasn't an attempt to blame you or anything; please don't
read it that way. I'm as much to blame (if not much more) for the
delays.

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

Yack. Yeah. Other thread. :/

> Maybe GNOME2.1.x can start to mean "Maybe this should *really* be fixed
> by GNOME2.2.0"?

<nod> Other thread.

Luis