Closing all bugs?

[Will Stephenson]

On Tuesday 11 December 2007 09:15:50 Andreas Hartmetz wrote:
> You are touching on a very important topic here: I bet most people don't
> know off the top of their head whether or not some component is maintained.
> It would be cool to have a quick overview over the maintenance status of
> modules. That may be wishful thinking because it's more of a social problem
> than anything else and you can't change people.
> A solution would be much appreciated, good luck :)

Here's a suggestion to get the bugs back under control

1) Define a scope we want to tame: "KDE 4.0 libraries, programs and 
components"
2) Work out how many bugs we have in each component in that scope
3) Identify an active maintainer for everything in that scope.  Of course, 
some things will unfortunately turn out to be practically unmaintained.  
These will have seen some work for KDE 4 by the group of developers who are 
happy to crawl all over the codebase.  Assign these things to 
kde-tiger-team at .
4) Round up a posse of other developers able and willing to triage.  I guess 
there are at least 50-100 people who have been significantly active in KDE 4, 
who would be qualified to quickly assess and dispatch bugs from pretty much 
anywhere.
5) Allocate these resources according to bug count/component.  tiger-team 
probably has the largest count...
6) Designate 2 weeks in January/start of Feb where we all go through the bugs 
in 'our' component and make sure every component has easily identifiable KDE 
4 version, move bugs to the right component/version as needed, and close bugs 
fairly aggressively.
7) Publish daily reports on where the bug numbers are going during this time.

Yes, this is a massive undertaking but
* we have more resources than we think
* many hands make light work - even at 15k bugs and 50 people that's only 300 
each.  I managed to go through 150 kopete bugs in 1 afternoon a couple of 
weeks ago.  This makes me optimistic that we can pull this off for the rest 
of the codebase.
* a cleanly defined area of responsibility increases bug set familiarity and 
therefore closing efficiency
* a 2 week period is long/flexible enough for to commit to, but short enough 
to keep everyone's minds on the job

Will

-- 
Will Stephenson
IRC: Bille