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

[Jeff Waugh <jdub perkypants org>]

<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:

> 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. :-)

- Jeff

-- 
linux.conf.au 2004: Adelaide, Australia         http://lca2004.linux.org.au/
 
                              <boc> man i rule
                       <bram> boc: how do you rule?
                            <boc> with authority