Shall we close all our bugs?
I proposed it september 2005, but we never implemented it: I think it would be good to close all bugs which are reported as soon as there is a new major release.
We now face a bugzilla which is poluted with an enormous amount of bugs. We have a couple of bughunters which try to keep it neat and tidy and without duplicates, but some reports are really silly. Btw: give the bughunters a cookie when you meet them, I don’t know how they keep it up.
So why close all those bugs? The silly ones need no explanation. Sometimes bugs are not understandable or not reproducable. With the arrival of KDE4 you can ask yourself what the rate would be of successfully reproducing bugs which are reported in KDE3 or even older versions of KDE.
Should we at least try to reproduce? No, of course not. Say there are 10 developers and 100 users. It would be logical that the users try to report clear bugreports, make sure it is confirmed by another user and reproducable. The 10 developers can pick up the confirmed bugs and solve them. Saving so much precious time. The group of users is always bigger then the group of developers. The biggest part of the bug (the clear reporting) should be done by them.
Isn’t it unfair to the user who reported them? Again no. We deliver software to them, we don’t ask money or anything else in return.
We just kindly ask to re-open any closed bugs which still exists after a major release. Do you think that is too much to ask?
Summary: I would vote for closing all bugs after we release RC1, users can reopen their bugs when they see that bug still exists in KDE4. This way developers have a clear view of valid bugs.
I agree that old bugs distract developers. I helped k3b a little with bugs and a lot of them just did not apply any longer. If all old bugs are closed it would be nicer to the reporters, if we could introduce a resolution for that (e.g. RESOLVED – SUPERSEEDED) instead of INVALID to make clear that the bug might well still apply and this is only done for maintenance.
@mirca: some projects use a NEEDSINFO status to track bugs that need userinfo. If bko is updated, that might make sense.
+1
though we might get weird press about it a la ‘kde now bugfree by declaring all bugs invalid’
but we could have the fun releasing kde 4.0 bugfree with a wink.
I am curious how did you come up with the idea…I hope that you’re not the kind of people that when in distress they shat on the people beneath them instead of finding a solution to the actual problem.
How would you feel if your commits would be erased on every new release and you would have to commit again?
Just because you’re providing a free product doesn’t mean that people that might eventually use it like to be jerked around. They don’t. They move on, and eventually you’ll be left with a minimal user base. Do you want that? My guess is not. You could still have your opensource project but what good will it do to you? What you get from contributing to OSS besides scratching a personal itch (isn’t that how everyone starts?) is gratitude, praise and exposure. Gratitude and praise is what you should expect from your userbase, not servitude!
After all is not your userbase’s fault that you have bugs in your software. If you have too few bughunters why don’t you ask for help?
I’m sure some people would volunteer, but you have to give something in return. So instead of writing “We have a couple of bughunters…” why don’t you mention their name so they get the same things you get: gratitude, praise and exposure? Do you think bughunters are less important than the developers and they don’t deserve it? Well, if you came up with this “interesting” idea my guess is that you’re in a pretty serious need for bughunters and that makes bughunters more important than YOU!
You also say “Btw: give the bughunters a cookie when you meet them” but how am I supposed to know who are they? Search the net? Post an ad in the local newspaper? It would have been much easier if you mentioned their names…do you even know who are they?
I’d say this is much bigger than some bugs in an issue tracker. It’s about how you look at other people. You can earn respect but you cannot demand it. Keep that in mind.
I strongly agree with that!! Even starting with a clean bugzilla (newer version) should give a very positive feeling to devs and users!!
Go go!
agree, but if you switch to clean bugzilla, old reports should still be actually closed so that their authors get notification about that…
I’d suggest to introduce an automatic “timeout” for any bug that is not closed within a year.
A timeout would also close the old bug… but with the provision, that anybody could re-open it, provided new/additional/updated evidence is supplied with the re-opening (“I tested with version 3.5.8 and the exact same bug description still applies”) would count as such evidence.
We have *lots* of bugs which have not even seen an additional comment after a year, and are still ‘open’… possibly because the developer didn’t have time to go through it. If that is the case, and after a year there is still someone who re-opens it and provides additional evidence, then it may be worth while for the developer to follow up on it.
Re-opened, more-than-1-year-old bugs should probably get a special tag to be able to find them quickly through a bugzilla query….
what about kde3 support? We aren’t giving up on all the kde3 users! won’t there be kde3 bugfix releases? Perhaps we should just open a new bugzilla that is kde4 centric, and leave the old kde3 one seperate? Both could be linked to from the main bugs.kde page!
Vlad Blanton
Yes, and I also see developers commenting on it and I even see patches, so this tells ma a) they are actually working on it and b) it’s probably difficult to fix.
Even so, frequently reported might just mean it’s easy to encounter, it does not mean that lots of people actually think it is important to fix.
And honestly I think you have a pretty low opinion of OSS developers.
Just take a look at an immense project like KDE. Imagine the enormous amount of work people are putting into it and look at the quality of the end result. It’s pretty amazing I think.
So of course it has bugs, nobody will deny that, but what we’re talking about here is making the entire bug-reporting process more manegable. Currently the bughunters are not able to go through all the bugs, see if they still apply and fix them.
Trying to find more people to help is fine, but it’s difficult, bughunters are scarce (maybe too many users just like to complain instead of help out). But even if you could find them it is an inefficient way of solving the problem, those people would be spending a lot of time just figuring out if a problem still exists while their expertise is needed fixing the problem.
So now we could try to use another resource of which we _do_ have a lot: the users! There are many of them and they know enough to figure out if a bug still exists in a new version or not.
It just seems very logical. If it will work in the end I don’t know, but it sure seems worth a try.
We abandoned any support for old versions long ago. When was the last time we released bug fixes for KDE1 or KDE2, let alone 3.4? The 3.5 branch is the only one we’ve actively been bug-fixing for a long time now, and there’s only likely to be 1 or 2 more releases for those if there are serious bugs of the “eats your children” variety. So why leave KDE3 only bugs open if we know we will never fix them? We’re only deceiving our users. Let’s close them with a SUPERCEEDED tag.
Ever considered that maybe why you don’t report bugs anymore is that there is too much noise on bko for the devs to spot the real serious bugs and action them? Reality is most devs don’t have time to sift the vast numbers of bugs, we rely on the reporters to provide sufficient detail for us to know which ones really require action. There’s currently 14160 bugs and 12903 wishes open, there’s perhaps 300 active committers, so that’s about 45 bugs and 40 wishes each to wrangle, assuming an even distribution of bugs and knowledge to address them (which we know there isn’t). Sifting through the reports on the code I recently took over, most were stale a long time ago or were never going to be fixed due to underlying QT issues, but because there was no active maintainer for the code they’ve just sat there. And that’s those those I can find, searching bko is a pain…
The core of Tom’s suggestion is to go back to those reporters to get them to help with checking if their bugs really are still valid. I would suggest that most reporters will actually support this as it shows were actually getting down to dealing with the whole mess instead of just ignoring it as it grows bigger by the day. The valid stuff will float to the top, the dross will be let to slip away. While it might seem preferable to e-mail everyone first to ask before closing, it just becomes too difficult to track that way, this seems the only practical way of arranging it.
OK, sure, maybe don’t close anything reported after say 3.3, but old stuff is more likely to have been fixed, or the reporter unreachable, or the app removed entirely, so someone just needs to do some work on sketching out the parameters (But that’s difficult, ever tried searching by version numbers on bko? Ugly, I tell you.). We just need to be sure that is politely and positively communicated.
The only other alternative is to declare a series of bug triage days and pray you can herd all those cats into looking at their fair quota.
John Layt.
Not casting doubt on you, but your argument would carry more weight if you were to declare your identity and your software.
Where is the problem? There is absolutely no benefit in closing bugs. Bugs are usually filed release specific. You also cannot expect that a user finds users who confirm the same bugs. It is really important to think of bugs as a useful contribution by the community.
You can easily filter all the bugzilla bug reports (by date, release, component etc.)
You have to see bug reporting and bug consolidation as a task independent from programming, an own intelligence community that provides valuable feedback services for you.
You can just close the bugs which don’t have additional number of subscribers to it.
No subscribers to a bug report means it was only reported by a dormant reporter who never cared to follow up.
But there are bugs (in kdepim) which are like very old and have a lot of duplicates, a lot of subscribers and a lot of votes. I was really hoping that KDE4 was the time to work on them.
I’d say its very good that you are not responsible for the actual decision to do this.
Naturally, you can close all your own bugs, and piss of your own users. Just stay the hell away from all the bugs for the rest of KDE. I’d like users of ‘my’ software to be treated with some more respect, thank you.
I’ve been working on ksysguard off and on for a little while now. Previously very little work was being done on it. I know one thing that helped me get started was the list of old bugs. It was fun to go through the list, close the ones that didn’t apply, and find inspiration from the ones that did. Not to mention how good it felt to close bugs that had been open for several years.
Many of the older bugs didn’t have a valid contact email and would’ve been lost if we had done a blanket needsinfo => no reply => closed for all the open bugs. The thing that works best for me is just to go through the list, close them when they’re obviously invalid, ask for info on the nonobvious ones, and only if I don’t get the feedback that I need do I close a bug.
greg
I wondered if anything similar has already been done in a big project.
I think it is worth the try… if it doesn’t work out it should be possible to reopen the “expired” bugs (or not?)
Sounds like a really good idea considering how much has happened during KDE3->KDE4, just make sure that reporters get an e-mail including a concise explanation of why it was done.
Regards,
Aron
So we should work on improving bug processing and fixing procedures.
I agree bugs for 3.3 or 3.4 or even 3.5.x (x < 8) should not be fixed (but they should be verified if they are present in latest version).
But you cannot leave users of 3.5.8 with the option: abandon KDE or use KDE 4.
This is too similar to methods used by Microsoft & co – fix by upgrade (and pay by the way).
And if the tools are not sufficient for the goals (like the version searching), we should fix the tools, not scrap human work.
I see the following things to be done:
1. Improve removing stale bugs by introducing NEEDSINFO state and automatic closing of bugs which are longer than, let’s say, 1 month in this state.
2. Add easier filtering by version to KDE Bugzilla.
3. Create dedicated BugSquad which will work on bugs, taking this burden off the developers, similar to what is done in Ubuntu Bug Squad.
4. Organize regular bug verification/fixing sprints (again similar to Ubuntu Bug sprints).
5. Create team which will be working on improving and fixing stable (3.5) branch of KDE. I think there are quite a few companies using KDE for enterprise desktops, so they would be interested in supporting this version of KDE for their own purposes. This could bring some external developers to KDE by the way.
Tom,
Thank you for your reply to my comment. I don’t disagree with your statement that it’s easy for a user to re-open a bug. What I’m saying is that it gives them a feeling of futility.
They’ll open the bug once, twice, thrice…they’ll eventually get bored and not reopen it again. You’ll be left with a program that’ll be perfect on papers (no bugs open) but something else in practice. Maybe that’s a bit drastic but you get where i’m coming from…
My hope is that every now and then when someone submits a bug, they also submit a patch to fix it.
You did not offend me. I don’t know about the bughunters.
You have a blog “Top KDE Commiters”, why not start “Top KDE bughunters” or something…
If the backtraces become untraceable, it’s not that hard to ask for the person who reported it to do regression and provide a new traceback is it? After all, it’s not enough for him to just reopen the bug, he’ll need to provide a new traceback anyway…
I don’t know if it is necessary to close all bugs, but it would be nice to have a timeout on bugs. If there is no activity for a year, send out an email to the reporter that the bug will be closed if it no-one bothers to update its status. If the reporter posts a comment, it will get another year of life. If there is no response, it is closed. This won’t be detrimental to the important bugs, since they will be either fixed in a year, or will at least have some activity (comments/duplicates). Only the obscure bugs that either were already fixed, only affected one user, or never existed in the first place will be purged from the system to keep it manageable.
It’s funny to think of bugs.kde.org as a cache:) Frequently accessed items get to stay in, the rest are expired. Not a bad idea at all.
Although that would surely help it might not be enough. I think what Tom was trying to enforce is that people actively go out and try the latest version.
Because there might still be comments coming in on bugs related to a 3.5 version even after 4.0 is released. But I image that after a while 3.5 bugs just won’t be handled anymore. Closing them to force people to reopen them for the 4.0 version would work very well to filter the still existing bugs.
So maybe for minor versions you could go for a less strict system that won’t close bugs that have recent activity but for the 3.x to 4.x transition that might not be enough.
you know what? scratch my previous post. I think your own post here says it all…
Easy dude, no need to get hostile! Did you even read his summary? I’ll repeat it for you:
“I would vote for closing all bugs after we release RC1, users can reopen their bugs when they see that bug still exists in KDE4. This way developers have a clear view of valid bugs.”
He talks about closing bugs, nothing more. The original poster will receive an email telling him the bug was closed. If a comment was left telling him to check if KDE 4 still has the same problem, if so the only thing he has to do is reopen it! That’s almost no work for the person involved but a lot of gain for the KDE project as a whole.
In fact I would suggest to do this on a regular basis: each year or maybe even each half year you ask for an update. Maybe it would even be possible to have a list of “old bugs about to be closed” so others that are interested can help out. But in the end, if there is no reaction, the bug gets closed because obviously it either was fixed or nobody can be bothered to comment. The developers are better of focusing on the things that people do care about.
In the end it’s all community work, that includes the users! It doesn’t matter if you can’t program or if you don’t have the skills to make pretty icons or write good documentation. Most of the time nothing is expected of you and you can just be a happy user. But you can’t just expect to fill out a bug report and forget about it. In good community spirit you should just accept your part of the work which in this case is helping out by checking if your bugs still exist for KDE 4. If you can’t be bothered even doing that little, well…
I agree completely, this also means that real bug reports are dealt with as the chaff will no longer be obscuring them. You may lose the odd good report that may be still present after the major release but that is so little compared to what can be gained and if the problem still exists then surely it will be dealt with again.
> The developers are better of focusing on the things that people do care about.
If I look at “Most frequently reported bugs” bug no. 8 is still open and guess when was it open: 2003-11-18. And there are comments from 2003 to 2007. Would this bug being in the top 10 most frequently reported bugs qualify as something people do care about?
Let’s be honest here: OSS developers work on what they want and have an interest in, not in what the people want. And when a developer tells a user “if you don’t like my program go use something else” he doesn’t really want that; he wants his program to rule the world as soon as possible and everyone to agree with him and say “wow what a wonderful program, it doesn’t have a single flaw”. So what the developer really means when says “go use something else” is “i have no interest to do what you want”. Don’t you agree?
A few remarks:
- i encourage everyone to report bugs to the bugtracker. I read the ones i’m responsible for and will allways try to fix them, and i’ve always done that.
- i do not know who are the current bughunters. I only know Bram, so I did not want to make a list, because I might forget one or more.
- bughunters and bugreporters are more important than me.
- i just want a bugtracker which contains valid bugs as much as possible and which is a pleasure to work with.
- i’m sorry if I offended you or the bugreporters in general, I’m just looking for a way to keep the bugzilla work and work better in the future.
- every major release changes so much that for example backtraces become untracable soon.
- i stand by my statement: it is easy for a user to re-open a bug.
Dave,
Please take a look at this bug. It’s in the top 10 most frequently reported bugs and it’s open since 2003. What is obscuring it?
i’m happy to see you understood the message in that blog.
I think we should leave any bugs that were reported about KDE4 open (obviously), as well as some bugs in KDE 3.5.7 (only those ones that are confirmed and have a fix in the works).
Some evidence to back what you’re saying up is this one.
There are many more.
In fact, there are over twenty thousand bugs that really needn’t be open any more.
I can understand why this would be good, but I see several things to consider:
1. Timing: since kde 4.0 release (or even rc1 as you proposed) will not be generally available for users (at least until all major distros switch to kde 4.0 as default), therefore closing bugs at that time might be a bit too early. I would see a need to do it in several phases, similar to traditional bug handling (needsinfo, no comment, close), so that we notify users first and close them for example in 6 months from kde 4.0 release (where it would be considered generally available). We could introduce new bugs database for 4.0 (to have clean state for kde 4 developers), while keeping old database for the transition period.
2. What will users/media say about this? We need to have good story why we are doing this and we should have some idea how to avoid same situation in future.
3. How to improve in future: I would agree with some previous comments, raising awareness of the need for bug hunters and respecting/praising their work is key in order to ensure enough contributers for this hard work. Implementing “timeout” for needsinfo bugs also makes a lot of sense.
3. Some bugs are wishes/enhancement requests and I am not sure we want to close them (e.g. they may contain valid info for developers when deciding on new features). If transition phase would be used, this is not that big of the problem though.
4. Some flagship KDE applications (extragear…) may not have kde 4.0 port yet, therefore closing bugs for them is probably a matter or their maintainer, right?
-100
I think this terrible idea is the symptom of the general “screw you, users” attitude I am seeing lately in KDE. Serious bugs (marked grave due to data loss) are not solved for _years_, some are said to be solved by “upgrade to KDE 4″, which is not viable solution to many users. And there are lots of less important, ignored, bugs in KDE3 which badly affect user experience (like KDED using 100% of CPU, where even workaround exceeds capabilities of inexperienced user).
Bug reports are not there to look nice in statistics, they are there to show real problems in the code. They contain important information and people put much effort into creating them.
By closing bugs for KDE 3, you just say you don’t care about KDE 3 users. And KDE 4 is not a viable alternative for KDE 3 and will not be for long time. So telling users to “upgrade to KDE 4″ is like telling them “go somewhere else, as we do not care”. And they will go, to XFCE, Gnome or Windows.
If you want to distinguish bugs in KDE 4 from those from KDE 3, you have version field in Bugzilla to filter on. Closing the bug will not make it disappear in KDE 3, it might just make you feel happier for a while.
If you start closing bugs after each major release, it will even get worse. Users will stop reporting them. I have already stopped reporting bugs, because this does not make sense. I lose time, bug is not fixed, unless I do it myself. And I do not want to recompile each new version of KDE, just to see if the bug is still there.
If you start making people work in bug reporting useless, they will go away. You will get less bug reports, but not less bugs. And subsequenty, less users. It is not a way to go.
Krzysztof Lichota
PS. Please note that I am not against the idea of closing stale bugs. This should be done by closing bugs which are in “Needs info” state for long time without response from reporter. But KDE Bugzilla does not even have “Needs info” state…
Mircea, maybe nothing’s obscuring your favourite bug, maybe it’s just incredibly difficult to track down and fix because it’s semi-random and hard to reliably reproduce. But if it’s so often reported, cleaning out the bugtracker for 4.0 won’t matter. It would need to be re-reported for 4.0 anyway, because the trace would be different, and it’s pretty clear from historical evidence that someone *will* re-submit it.
I think it would be sensible to open a new bugtracker database for at least each major version (kde2, kde3, kde4 etc.) if not each minor (kde3.1, kde3.2 etc.) version. After kde4 comes out there will probably be a few more bugfix revisions to kde3 for those users who like old and stable software, so the kde3 bugtracker would remain open. If the people who reported a bug noticed that it was still there in kde4 they could update their bug report and copy it into the kde4 bugtracker (hopefully with some kind of automatic button); otherwise the bugs that had been overtaken by events would die away naturally and not clog up the database. Perhaps (to reduce the required effort a little and hopefully mollify Mircea) bugs that have been re-reported within the last year (or 2 or whatever) could be copied across to the new database and bugs that have not been noticed for longer than that time could be binned.
I’ve submitted a couple of bugs over the years and I don’t think it’s unreasonable to require me to re-submit them if they persist in a new major release – after all, kde4 is a very much changed piece of software to kde3.
This would be the sensible solution. Of course, at some point KDE3 will be irrelevant, but KDE3 will be relevant for quite some time yet.