Closing all bugs?
thomas.friedrichsmeier at ruhr-uni-bochum.de
Mon Dec 10 23:28:06 GMT 2007
On Monday 10 December 2007, Bram Schoenmakers wrote:
> As you may have read on my blog post  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,
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
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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel