Closing all bugs?
wstephenson at kde.org
Tue Dec 11 09:05:18 GMT 2007
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
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
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
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
More information about the kde-core-devel