On 28/12/2010 21:11, Rich Freeman wrote:
On Mon, Dec 27, 2010 at 1:51 PM, Jeroen Roovers <[email protected]
<mailto:[email protected]>> wrote:
On Fri, 17 Dec 2010 23:31:28 +0100
Maciej Mrozowski <[email protected] <mailto:[email protected]>>
wrote:
> Well, before I became developer, I had a quite unproductive
> discussion on IRC with Jeroen on that matter (jer opting for status
> quo and telling me I have no idea what bug wrangling is :P)
I have no idea what you are talking about.
I'd like to turn this discussion into a more productive direction
(let's wrangle bugs, and not argue over who said what to who when).
First, I'd like to say thanks to those who put a great deal of care
into bug-wrangling, and I think all will agree that Jer does a LOT in
this regard. It is very clear to me that when bugs get assigned to me
that they've generally been well-triaged and I'm sure that a lot of
cruft gets pruned before I even get an email.
That said, part of me wants to think aloud about whether we're
over-investing in triaging bugs in the queue and this is leading to
the queue getting out of hand. The problem I see with our current
bug-wrangling procedures (as documented on the official site) is that
they seem a bit daunting to me. I see this problem at work all the
time - procedures that are very complex either need to be an assigned
job, or they need to be simplified. If they remain complex but
free-for-all then nobody wants to touch them, since nobody gets yelled
at individually if they don't step in, but if they step in and mess up
suddenly they have egg on their face.
Something that might help would be a "one touch" bug queue (think
Getting Things Done). Wrangler looks at bug, and bug ends up in one
of two categories IMMEDIATELY:
1. Bug has required info and can be assigned to a maintainer. Go
ahead and assign.
2. Bug is missing required info or seems vague. Immediately add a
comment stating what is needed, with link to website with bug
submission procedure that wasn't followed, and resolve invalid.
Comment should welcome submitter to re-open with the required info.
This gets stale bugs out of the queue without a lot of fuss. It also
means that everything in the queue needs attention and nobody spends
time reading a bug just to find out that it is stuck and needs no
attention by a wrangler.
Also - I think we need to make other forms of triage a best-effort
sort of activity. If a wrangler wants to try to triage a bug they
should be welcome to try. If a wrangler notices a dup, they are
welcome to handle accordingly. If a wrangler misses a dup or doesn't
do triage, that is fine too, as long as they either resolve invalid or
assign. That does mean a bit more bugspam for downstream devs, but it
is pretty easy for me to spot dups for the packages I'm most familiar
with, and it is much harder for a wrangler to spot them across the
entire tree.
The overall goal is to make wrangling simple, but still a value-add.
We can leave room for those who want to do more. If we end up with a
big pool of serious wranglers they can just post on -dev saying that
they've got things under control and then those less serious about it
can step out and allow for more triage. When the wranglers get
underwater everybody else can step in and quickly clean up.
I guess the question is whether the resulting shorter queue and lower
latency is worth the tradeoff in having package maintainers get a few
extra bugs that might have been avoided in triage. I'd be interested
in Jer's perspective on how many bugs get squashed during triage.
Thoughts?
Rich
If it was just a case of checking if the right info was there then it
could be done by a few reasonably-Gentoo-savvy volunteers who check the
list a couple of times a day. Otherwise you're pretty much adding in
just another step in the process which seems like the opposite of what
you are trying to accomplish.
G
