Closing all bugs?

[Thomas Friedrichsmeier]

Hi,

On Monday 10 December 2007, Bram Schoenmakers wrote:
> As you may have read on my blog post [1] I suggest (after Tom's attempts)
> to close all bugs, not wishes, in KDE Bugzilla with KDE4 approaching. This
> is because of all the old cruft (KDE3 based bug reports), which is unlikely
> to be cleaned up if we don't do it now.

the signal-to-noise ratio on bugs.kde.org is high, and dealing with all those 
bugs is a real pain, but let's consider how useful this proposal actually is.

Having just spent a lot of time in the kate bug tracker, I learned that
a) This is pretty boring, but all in all not terribly hard work.
Of the bugs I looked at in detail,
b) An estimated 15% were dupes.
c) An estimated 15% are fixed in KDE 4.
d) An estimated 15% were valid, not fixed in KDE 4, but really easy to fix, 
once bothered.
e) An estimated 40% are valid, non-trivial, and still present in KDE 4. Ok, 
half of that number is from bugs in the syntax highlighting definitions, so 
in other apps this number will be lower.
f) An estimated 5% actually belong to a different component, but were never 
re-assigned.
g) An estimated 10% are incomprehensible to me.

Ok, all of those are "felt" numbers, not real ones, but before making up your 
mind, actually take the time to go through 10-20 random bugs in your 
component in detail to get an impression of what you actually got there. My 
impression is, throwing away all those bugs would not only be somewhat rude 
(even with clear communication), but also a terrible waste.

Some suggestions:
1) Let's not rush things. We can still close KDE 3 bugs a year from now, if 
that's the consensus. There's no real reason to ask reporters to switch to 
KDE 4 and confirm bugs within a few weeks of the official release. Let's 
accept the fact that many reporters will be stuck with KDE 3 for months to 
come for various reasons, so let's not ask something impossible from them.

2) A semi-automatic solution to ping reporters about old bugs sounds like a 
good idea. However, actually closing a bug should always remain a manual 
activity. Just that a reporter cannot be reached any more (or not be 
bothered), does not make the bug invalid. Rather: 
2a) Appeal to reporters to close bugs, if applicable
2b) Give an automatic feedback to developers, if reporter did respond to ping 
within X weeks, so they can investigate, manually.

And while we're at it, something for the future:
2c) Ping maintainers if a bug is unconfirmed and has not seen any activity 
during the last 4 weeks, every four weeks. Maintainers not having time to 
look at bug-reports while the reporter is still reachable, then forgetting 
about it, then coming back to age-old bugs with uncertain status and no 
active contact is part of the reason why b.k.o feels so crufty.

3) Ask for help, and be more liberal in actually accepting help, i.e. make it 
easier to gain b.k.o permissions. Ok, I don't know how strict the control 
actually is, but I know I've considered applying for permissions several 
times in the past years, before finally doing so 10 days ago, simply because 
it sounded like help was not overly welcome from not-yet-known sources.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071211/28bc2220/attachment.sig>