Re: the bug team and gnome2.2
- From: Luis Villa <louie ximian com>
- To: bugsquad <gnome-bugsquad gnome org>
- Subject: Re: the bug team and gnome2.2
- Date: 27 Aug 2002 19:15:28 -0400
On Tue, 2002-08-27 at 19: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.
I didn't so much mean 'they need to provide a QA person.' I meant more
'we need to find QA people and go to maintainers and say 'BTW, this
person would like to help you with QA.'' As it stands, virtually every
core module has a QA person- when it all comes down to it, me. I'd like
you, Vincent, or others, to say 'I'll take app X' and then focus on app
X, cleaning it up completely and dealing with all the new bugs that come
in. That is not the maintainer's problem- it should be our problem. [Of
course, if maintainers don't do anything once it is cleaned up... that's
a different problem.]
> > *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.
Agreed that it is difficult. Some random thoughts:
*use 'triaged' plus a triaged_by_xxxx keyword, where xxx are the
'permitted' people? Or make triaged_by_xx a special field or a
whiteboard string?
*maybe have a stats page sort of like the i18n people do?
Obviously, more thought is needed here :)
> > *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.
That's probably a good idea. Note, though, that in the future, everyone
is going to be releasing in a more lock-step schedule, so making it
release-centric probably isn't going to work so well. But still- I like
the idea of bug-days for small groups of apps, and using them to do
'from the top' cleanups.
> 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.
Yeah, we need to make that easier- possibly even script it. I've been
meaning to for ages, and just haven't. Certainly, SQL volunteers like
Wayne are welcome to step up. [We also need to finish the transition to
2.16... but that is probably a different thread.]
> Searching automatically for duplicates when a bug is filed (with
> simple-dup-finder.cgi) would be great too.
Yup, though again that script needs love.
> 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.
Yup. We need to figure out a clean, coherent way to do this, though.
Bugzilla certainly doesn't support it by itself.
> I just hope what I said was not too incoherent: I'm half asleep :)
Nah. Sounds great. Thanks for the feedback- you've been a great help
lately.
Anyone else? :)
Luis
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]