Closing all bugs?
Thomas Friedrichsmeier
thomas.friedrichsmeier at ruhr-uni-bochum.de
Tue Dec 11 11:59:54 GMT 2007
Well, I already wrote a reply, but here's another, perhaps more organized
collection of the top four reasons, why I think closing all bugs is a bad
idea:
1) Doing so shortly after KDE 4 is released is the *worst* possible time to
expect reporters to re-validate their reports.
Seriously, many people will be stuck with KDE 3 for months to come, and simply
*cannot* check whether their reports still apply to KDE 4. By the time they
do have KDE 4, they will have forgotten all about this, until the day they
run into the same bug again, and feel rightfully upset.
2) Asking to "just reopen" if still applicable is *not* an easy thing to ask
for a mere mortal users.
IIRC, reporters do not even have permission to re-open their own bugs.
Definitely, bystanders (voters, CCers) do not have permission to re-open. And
if you look at a number of bugs that actually have been re-opened in the
past, you will note that a simple single "please re-open" almost never was
enough.
Whichever the envisioned solution, I predict a flood of new bug reports of the
form "I already detailed this issue in a bug report that you closed for no
good reason, and that I am not referencing in any usable way, but expecting
you to find and read it". And how useful will that be?
3) Bugs which have been fixed in KDE 4 are *not* the problem. Not in quantity,
and not in quality.
In many cases, somebody active in a component can easily tell at a glance,
whether a bug is likely to have been fixed during porting. And that's a
sizeable number of easy closes, but also not an overwhelming number.
What you are really after is:
a) Reports have never been clear / specific enough to ever be dealt with
properly.
- Have no mercy on those.
b) Reports that have zillions of confusing comments about hundreds of separate
issues all lumped into one large pile.
- IMO, do close them, with a request to re-report the bits that are still
relevant.
c) Minor and corner-case bugs.
- Well, you will get rid of a large number of those, if you just close them,
simply because they are not terribly important even to the reporter or hard
to trigger. But do you *really* want to throw those away? And note that they
will be back, eventually, including their dupes.
There are good reasons to handle such bugs more aggressively, but there's no
good reason to take KDE 4 as a technical excuse to close them. See point 1
above.
4) This does not address the issue you're after.
A growing bug database is unpleasant and problematic. But it's a mere
side-effect of a simple fact: More bugs are reported than closed, regularly.
Yes, some of those are undetected dupes, but the core problem is: **Some
issues will never be dealt with in any particular time frame**.
That's a frightening fact, but a consequence of growing complexity more than
anything else. For every feature you add, there will always be (excluding
dupes and invalids) 4 associated new, non-trivial bugs, 3 good wishes for
features build on top of that, 2 wishes to add a related feature to another
component, 1 valid reason to remove the feature again, entirely.
Closing all bugs would hide the visible results of that mechanism for a while.
It will not do anything to change it, however.
-----
So much for why I think the suggestion is not a good idea. I also have a
number of suggestions what else to do, but - only one issue per report,
please.
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/4dc8d8ec/attachment.sig>
More information about the kde-core-devel
mailing list