Re: How to handle bugzilla



Mark McLoughlin wrote:

	Hmm, I actually prefer to see lower priority bugs too. What I really
would prefer not to see, though, are the many, many mails for bugs that
get closed out as DUPLICATE, NEEDINFO, INVALID etc. by the bugsquad[1].
I wonder if anyone could come up with filtering magic to move the entire
thread of a resolved out bug to another folder ...
The way they handle this on bugzilla.mozilla.org is to make all bugs start in the UNCONFIRMED state, rather than NEW (which is the state all Gnome bugzilla bugs start in, unless they come from bug-buddy). The equivalent of the bug squad's "triaged" keyword is moving a bug from UNCONFIRMED to NEW. This also removes the need for the NEEDINFO state, since bugs that we move from NEW -> NEEDINFO would simply remain in the UNCONFIRMED state until more information is provided.

The mail options in newer versions of bugzilla make it possible for a user to specify that they don't want to get mail for bugs assigned to them that are in the UNCONFIRMED state, which seems to be what is wanted for things like Nautilus.

I think the reasoning for not using the UNCONFIRMED state was that we originally didn't have as active a bug triage team. Since we now have a decent triage team, it might be worth looking at configuring bugzilla so that all bugs start in the UNCONFIRMED state. Even though our bugzilla doesn't have all the email prefs, it would let people configure their mail client to drop all bug mail for unconfirmed bugs, which gets round the need to mess with priorities

James.

--
Email: james daa com au
WWW:   http://www.daa.com.au/~james/






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]