Re: the bug team and gnome2.2

[John Fleck <jfleck inkstain net>]

On Tue, 2002-08-27 at 17:03, Vincent Untz wrote:
> Le 27 Aug 2002 17:10:32 -0400, Luis Villa a ecrit :
> 
> [...]
> 
> > *just as each package has a maintainer, each package should have a QA
> > person, or a QA team, much like nautilus (at least theoretically) has
> > ATM. Yaneti is the Galeon Guy, Kjartan is the GNOME1.4 core guy... we
> > need more guys (and gals!) who can identify with and claim their own
> > QA apps and build a relationship with the code maintainers.
> 
> I totally agree. If a package is in bugzilla, but nobody regularly looks
> at its bugs, it's quite useless to use bugzilla. Maintainers of a
> package which is in bugzilla should be asked if they really use it. If
> they do so, they can tell us if there's a QA guy for the package. And if
> they don't really use bugzilla, well, there's no need to accept new bugs
> for that package.
> 
> > *triaged keyword needs to stop meaning 'luis looked at and triaged it'
> > and start meaning 'members of the QA team looked at it and triaged
> > it.' How do we do that sanely, so that we aren't duplicating each
> > other's work all the time? Also, we have to do this while maintaining
> > consistency- how is that going to work?
> 
> That's a difficult one. Dunno for the moment. Need to think about it.
> 

Yeah, this is a tough one for me too. But I think having a QA maintainer
for each package would help this a lot - split things up so it's clear
who's responsible for what triage, rather than Luis being responsible
for everything.

> > *obviously, we need more bodies- bugdays need to be more communal, and
> > maybe we need to think about having a few of them later in the
> > evenings(for americans) or even on weekends. And of course any other
> > ideas about how to bring people in are good.
> 
> It may be a bit weird, but what about 'bugdays theme'? Making bugdays
> centered around 3 or 4 packages (or one 'big' package (*cough* nautilus
> *cough*)) would allow people to work together and it may be more
> efficient. For example, a maintainer could ask the bug team to help him
> clean out his package's bugs before a new release: he has the knowledge
> of the program but he may not be used to searching and closing bugs in
> bugzilla. I'm sure he would welcome some help.
> 

I like this themed bug day idea.

> One thing that looks really important for me is keeping bugzilla clean.
> For example, we could automatically close bugs marked as NEEDINFO for
> more than, say, two months if they don't have new info. Searching
> automatically for duplicates when a bug is filed (with
> simple-dup-finder.cgi) would be great too. And maybe we could restrict
> the filing of new bugs: make bugzilla don't accept bugs for unmaintained
> packages or for old versions of packages.
> 

I'm a little nervous about automatically closing bugs. Some of those
NEEDINFO's might be of use still, and they're pretty much out of the way
and not bothering anyone. And it's not too time-consuming to close 'em
manually. But I've found old ones that I have left open simply because I
thought they might still have relevance.

Cheers,
John
-- 
John Fleck
jfleck inkstain net (h) jfleck abqjournal com (w)
http://www.inkstain.net http://www.abqjournal.com

"Sometimes, a diner is all about the mac and cheese." 
  - Zippy the Pinhead