Re: Bug reporting [Was: Promoting greater integration between testers!:)]

[Owen Taylor <otaylor redhat com>]

On Mon, 2003-06-30 at 15:23, Jeff Waugh wrote:
> <quote who="Owen Taylor">
> 
> > The point is not that we can't close bugs without confirming them, 
> > but that a great deal of incoming bugs for GTK+ *are* not immediate
> > closed. There are three approaches we could take:
> > 
> >  A) Just blanket confirm all GTK+ bugs periodically
> >  B) Try to decide on some objective criterion for confirming
> >     a GTK+ bug. (Picking some random recent bug, what would you
> >     say for http://bugzilla.gnome.org/show_bug.cgi?id=116364?)
> >  C) Just leave bugs UNCONFIRMED
> > 
> > A) and B) are extra work, C) is aesthetically unappealing.
> 
> B means having a triage team, which seems to work well (although we need
> more people tackling it) elsewhere. However, further on you say:

What I'm saying is that if you are qualified to decide whether
gtk_spin_button_set_digits() is really a misnomer, and whether
we should do something about it, you probably are a pretty 
experienced GTK+ programmer. A GTK+ hacker even. 

> > Well, the GTK+ "bugzilla problem" is that we are rapidly heading for 1000+
> > open bugs against GTK+, which is partly not a problem...  GTK+ is a big
> > project with lots of potential improvements, but also a problem because
> > real fixable issues get lost in the pile.
> > 
> > There's no real solution other than scaling up the GTK+ project so we can
> > fix bugs/apply patches more quickly.
> 
> So, GTK+'s problem is more about bugs-getting-closed than bugs-being-triaged
> (so they can be closed)? That's slightly different to the problem that user
> facing modules have, where there are so many bugs that need to be triaged
> (dupes, hard to understand, needing better priority definition, etc) before
> the hackers can even have a hope of acknowledging and addressing them sanely
> 
> I guess it comes down to whether you want to cultivate a triaging/testing
> team to confirm and manage GTK+ bugs, or leave everything to the hackers. :-)

I have a hard time imagining that a triage team of non-programmers could
save more time for GTK+'s portion of bugzilla than the time spent 
guiding them along. 

I spend maybe 20-30% of my time working on GTK+ bugzilla, but most of
that is substantive decide/comment/review stuff.

I'd love to have more programmers going through GTK+ bugzilla, but I
want them fixing bugs, not categorizing bugs for the existing hackers
to fix.

Regards,
						Owen