Re: Bug reporting [Was: Promoting greater integration between testers!:)]
- From: Owen Taylor <otaylor redhat com>
- To: Jeff Waugh <jdub perkypants org>
- Cc: Luis Villa <louie ximian com>, fherrera onirica com, desktop-devel-list gnome org
- Subject: Re: Bug reporting [Was: Promoting greater integration between testers!:)]
- Date: 30 Jun 2003 14:41:44 -0400
On Mon, 2003-06-30 at 12:12, Jeff Waugh wrote:
> <quote who="Luis Villa">
> > A wiser head than I points out that this is a really sad statement for me
> > to make. I agree. I hate to have to admit this, but currently bugsquad and
> > I just can't keep up on many key modules (like, say, nautilus.) If I could
> > spend all day (and all night) on bugsquad and b.g.o., I wouldn't be saying
> > this. But I can't so I must :/
> > I should also note that projects that feel a shortage of bug reports
> > should feel very comfortable doing this (Abi already does something like
> > this, for example.) I'm just saying it can't be the default in libgnomeui
> > for stable releases- apps must do it on a per-app level. Currently the
> > core apps (which is what I have to think about) can't be defaulting to
> > this, at least not in stable releases.
> I think that shifting to the Mozilla 'UNCONFIRMED' -> 'NEW' triage strategy
> (as suggested by James Henstridge a number of times) would help in this
> regard. It would make an 'introduction to triaging' so much easier, and
> hackers would not have to see all of the crazy mess that goes on underneath
> until the bug was flagged as 'NEW', signalling that they should care about
> it. This could help.
It should be noted that bug-buddy bugs come in unconfirmed
Fromthe GTK+ bug perspective I hate the idea of one more
step to deal with incoming bug reports ... GTK's bugzilla
problem can't be dealt with triaging; since if a bug is
closed immediately, it's quite frequently a RESOLVED/WONTFIX
... a rejected RFE and thus some sort policy decision.
Though that's probably just being selfish.
] [Thread Prev