This question was raised by Tom Albers for a couple of times, but without a real decision. Let's give it another try.
At the time of this writing, we have 15210 open bugs and 13336 open wishes. The past week, 367 bugs were submitted and 294 bugs were closed, and this growth is to be seen every week. Unfortunately there's not enough manpower to cope with this. We need to find a solution or we'll drown in this bug swarm.
With KDE4 looming in about a month from now, it's a good moment to catch up. Many applications had a complete overhaul and the codebase is quite different compared to two years ago. But we are still left with thousands of old bug reports, based on a completely different codebase. And don't forget about the reports with no response from the authors.
Are we supposed to clean all those bugs one by one? I don't like that idea much, that will take us months of really boring work.
Now, what is the plan? The plan is to close all bugs (not wishes) just before or at the KDE 4 release. Of course not all bugs will be fixed in this new release, so they should be reopened. If you don't have the rights to do so, there are ways to get it done to poke one of the bug hunters (basically to be found in #kde-bugs on Freenode). This will result in a clean Bugzilla which is easier to maintain.
You could argue that this is rude towards all the reporters who have submitted clear bug reports which are still not resolved. I don't think this is a big problem if we communicate clearly what happened and what they should do in order to reopen it again if necessary. If you care about a certain bug, it's not a big deal to spend a minute to do this. It's better than to have five people deal with over 15000 bugs.
To be sure whether the community thinks this is a good idea I've set up a poll, open for 4 weeks from now. Again, this is about bugs and not wishes.
Please think about the plan. This is not about screwing our users, this is about helping the developers to have a clear view on what should be done to make there application rock even more. Developers want to create cool stuff and not waste there precious time dealing with outdated bugs. Don't we all agree with that?
P.S. Is this ever done before in some project? If yes, how are the experiences?
CADT
Other projects' experiences? How did this rant ever pass you by...?
http://www.jwz.org/doc/cadt.html
"If you feel your bug is still of relevance to GNOME 2, please reopen it and refile it against a more appropriate component."
New bugzilla
How about creating a new bugzilla, or somehow creating a clear segregation between pre-KDE4 bugs and new bugreports? That way, if some brave soul or organisation wants to really clean up KDE 3.x, they will still have the bug reports available.
Re: New bugzilla
I think it is indeed better to make a separation between kde3 and kde4 bugs. Don't throw away the old bugs. Kde3 will be around for a while, so many of the bug reports will still be very useful for a long time!
/offtopic: konqueror doesn't want to show the captcha (kubuntu gutsy kde 3.5.8)
Captcha?
Hmm, just checked with a pretty default Kubuntu 7.10 and it appears just fine.
I think it would be time to
I think it would be time to look at http://www.atlassian.com/software/jira/ for KDE4
-D
The problem with closing
The problem with closing bugs is, that with ordinary bugzilla accounts you don't have the right to reopen bugs others have filed, so if the person is MIA, but others still have the problem, the bug stays closed. And there are lots of bugs, still applying to KDE 4 code, e.g. for Konqueror/KHTML this will be the norm.
And: It's a royal PITA to wade through the half dozen forms to file a new bug. bugs.kde.org is a lot worse in this regard than vanilla Bugzilla. I know what I speak about, I filed dozens of bugs and I'm less and less willing to do so, for that reason.
Exactly!!!
When I read the article, this Jamie's article came to my mind.
Linux community seems to never learn anything, that's why Linux can't become anything more then just a noise in the background, which is kind of sad...
That doesn't solve the problem
You mentioned that there are many more bugs filled each week than fixed: that means that your proposed step would not fix the initial problem but only move around some numbers. Soon there will be another pile of bugs.
I would prefer to have a bug fixing system which is closely connected with time intervals:
- after each new major release ask in all still open bug reports if the problem is still valid; if not, close the bug, if there is no response after 4 weeks, close the bug automatically
- if the bug is set to NEEDINFO but the information are not provided, close the bug automatically after 4 weeks
This would filter out all bugs which are not valid anymore or not active anymore. It doesn't make sense to keep such bugs anyway, and automatically closing such bugs is just sane.
All other bugs which can be verified by users should be kept open, though, because they are valid.
Also, KDE 3.5.x will be further supported by the KDE team (or parts of it) afaik since it will be used for years from now on in corporate environment. It doesn't make sense to just close bugs of a still supported product. The only exception are programs or services which are hardly maintained at all: artsd comes to my mind here. It should be thought about closing all artsd related bugs for example.
But that's it already, everything else should be done automatically because that is the only way to solve the problem in the long term!
> I would prefer to have a
> I would prefer to have a bug fixing system which is closely connected with time intervals:
I agree with you, but better make it four months than four weeks.
> Also, KDE 3.5.x will be further supported by the KDE team
Nice to point that out - or at least the expectations of the user base...
I call bull!
I call bull as well! I replied to aseigo's blog a while back and also suggested a concerted bug cleaning effort and his reply was that was going to happen anyways... well it didn't. Closing the bugs now won't fix anything. It'll just let you guys sleep at night while a new set of 15k bugs gets filed because things are still not fixed.
Man'ing up to the bugs would be the best thing to do. I mean, just take a look at some of the _core_ applications which are now into the hundreds of bugs (not just wishes -- kate for example). All you're doing is announcing to the user base, the ones already dedicated enough to file bugs, that you're really not interested in fixing problems and you just want them to re-file all the bugs they find while they actually try to get work done... again.
Sure, get rid of the apps like arts which aren't around anymore... but do the right thing for the other ones.
Point is, the amount of bugs
Point is, the amount of bugs right now in the database is contraproductive - the task of keeping the amount to 0 is way to daunting to even think about. Many bugs are bogus, making the legitimate ones harder to find and lowering the responserate from the developers - which gives the signal to the userbase 'we don't care' much more than automatically closing bugs after a certain amount of time.
So, bram, I'm all for closing all bugs, and I'm all for automating that process based on a certain timeperiod. 2 months or 2 weeks doesn't matter for me...
How about Fedora for example?
This mail I received today:
Fedora Core 6 is no longer supported, could you please reproduce this with the
updated version of the currently supported distribution (Fedora 7, 8, or
Rawhide)? If this issue turns out to still be reproducible, please let us know
in this bug report. If after a month's time we have not heard back from you, we
will have to close this bug as CANTFIX.
Setting status to NEEDINFO, and awaiting information from the reporter.
[This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or
Gecko. If you see any other reason, why this bug shouldn't be closed, please,
comment on it here.]
-------
Seems pretty reasonable to me.
I think it is a good idea.
I think it is a good idea. Just the other day, I went through the kcontrol kcmmouse buglist and posted comments suggesting such and such should be closed, and such and such is a dupe. There are a lot of unmarked dupes in bugs.kde.
Perhaps some of the bugs could be kept? For instance, if you filter the results to include only those that have at least 250 votes, only 270 bugs are found. Or if you limit the bugs to those that are "critical", "grave" or "crash" and changed within the last 360 days, you only get 231 bugs returned. I don't know what are the best indicators of important bugs, but perhaps you could filter down the number of bugs to a managable size and close all the rest? (Or, as you said, simply close all KDE3 bugs.)
PHP, I believe, does
PHP, I believe, does autoclosing after a set period.
Closing a bug may seem to people "not in the know" as a sign that the bug has been solved. I'd suggest a new status like "archived" to show that the bug is old and will probably never be fixed if it is associated with unmaintained software.
A message like that could be put as a comment when it is archived.
Archived bugs would not be shown in basic searches.
Why not using versionned bug report ?
You could use versionned bug report.
For example, Debian use it. What you have is information about which version of a package is concerned by the bug report.
If you want, you can take all reports and say that bug is no more in version > 3.9x. Then, if somebody has still the bug, he can just state that a new version has the bug.
Closing seems harsch, especially because I believe kde 3.5 is still open for bug fix.
Bugzilla?
Working with bugzilla is a pain for users...
I think if KDE wants to clear all bugs, then it should move to a easier bug tracker, maybe mantis ?
Better options
I'm not sure if my trackback went through, so:
http://irukado.org/content/kde-closing-all-bugs
I see the point of this
I see the point of this idea, but this is not the final answer yet
in my eyes. A few thouhts:
* [Separating Kde3 and Kde4 bugs] sounds very reasonable to me,
as recommended by another poster before. Kde3 will be around
quite some time so people should be able to access related bugs
without problems.
* Not sure if I'm the first one to think of that but a [whole project
in bug-hunting mode] can be fun as well. Wouldn't that absolutely
rock to go for bug after bug until there all gone? I think it's
mainly a motivation thing that decides if that could work.
Also a few exceptions would need to be made e.g. for Kate Syntax
higlighter bugs like "Perl highlighting cannot do ".
* Someone recommended [Mantis]: I gave it a try once and almost
got hacked through Mantis! It is my impression that the overall
quality of Bugzilla is 10 times higher than that of Mantis.
* If you should decide to close all old bugs in the end please
send all people who created bugs mails fro their bugs asking
them to reopen if necessary. Was recommended before as well.
What I would do
create a new status, named "sleeping" or "dormant" en move bugs with no activity for a certain period to this status. Also create a new KDE4 bugzilla (or whatever) en use the same system there.
KDE bugtracker is crap
Honestly, the KDE bugtracker is crap. And the problems we are having now are simply a result of that. We should switch to something else asap.
Aww.
"Are we supposed to clean all those bugs one by one? I don't like that idea much, that will take us months of really boring work."
And this is why open-source software cannot compete with proprietary software on quality---people don't want to do anything which isn't "cool" without being paid, and bughunting is neither fun nor glamorous.
Close the whole bug tracker down. You clearly don't wish to make use of the information it provides.
Nice trolling
The KDE team does a fantastic job of closing the Coverity bugs. This demonstrates that when they are given a clear description of the bugs, they effectively deal with the 'uncool' work of bug fixing.
The 'open-source software cannot compete with proprietary software on quality' is demonstrably wrong. Look at the results of the original fuzz tests. When fuzz testing was introduced, Microsoft, Unix and GNU utilities were tested. From these tests, it was clear that the GNU code was of much higher quality than Microsoft and even better than any of the commercial Unix distributions that were tested.
Is "trolling" just a synonym for "disagreement" these days?
Done. And? A bug tracker records actual, live bugs which are causing actual, live people actual, live problems. Fuzz tests just generate numbers which are great for dickwaving contests, but ultimately useless for the purposes of make programmes useful.
re: Is "trolling" just a synonym for "disagreement" these days?
see the subject, yeah, I think so
it looks like somebody decided to destroy KDE from inside ... at first, a lot of people is turned down by calling RC something which is in alpha quality, then the rest willing to give feedback is told "we don't value your input anyway, if you are so pissed off with some flaw then just do your testing work again, your time is of no importance to us, WE just do not want to get bored, and evaluating bugs is so boring" ... and everyone daring to display any slightest disagreement is called troll instantly (hey man, in the past weeks I've translated three KDE apps, two of them for KDE4, and precisely described the problems within several bugreports ... so I am really trying to help, but I do not like people stabbing knife in my back and you cannot expect I'll be polite to them, I'm not Jesus to return bread when receiving stones)
btw, the numbers used to support the blog are quite interesting; right now, the numbers of bugs for the last week are 347 opened vs. 350 closed, and the weekly increase in the blog is about one fifth above the long term average ... but the recent numbers are useless anyway, because you do not release RC of the new major version each week
... and the Captcha does not work in Konqueror, great for KDE related blog!
The current number of bugs
The current number of bugs in the database already decreases the bug-killing activity at both sides (users and developers).
I fully agree that KDE4.0 is a good opportunity to start new rules for KDE bugs treatment.
My suggestion:
1. Close and store the old data base for research purposes, and start new ones
2. In the new bug bases, strictly distinguish bugs according to main version, so there will be KDE3 database and KDE4database.
3. I accept the time limit of bug's, however, I would say a longer time: a bug can live 3 month without confirmation
4. The most delicate question: how many/which bugs should transfer from the current database to the new ones, and which way ? IMHO, there is no perfect solution, we need a compromise. I can imagine some reasonable solution.
I have to underline, the goal of rule change is not a single reduction of bug number.
The goal is to prevent the same situation in the future,
From this perspective, the details of transition is no so important.