Closing all bugs?

[Jos Poortvliet]

On Dec 11, 2007 10:05 AM, Will Stephenson <wstephenson at kde.org> wrote:
> 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

Generally I don't disagree with your suggestion, I just want to add something.

I think we can ask something from those who did send in the bugreports
in the first place as well. Of course, this is afaik what Bram wants.
It is not about closing bugs automatically, but asking from a slightly
more active attitude from those who report bugs and file wishes. They
should check the validity of their bugs every once in a while, and
sending them an email to remind them seems useful to me (even if you
don't auto-close or auto-whatever the bugs).

So sending an email to bugreporters a month after KDE 4 is out, and
putting the bug on 'need info' or whatever if they don't respond in 8
weeks sounds like a good move. It would lower the amount of work for
developers, allowing them to do what they're actually supposed to do
instead of separating good from bogus bugreports.