I did a search on bugs that were still open up to 31st of December 2006, and there were almost 4000 of such bugs. I had a look at a few of them, and they all seemed solved in some way or another, hence could be closed. I don't know if bug stats are kept somewhere, but in case they are closing old bugs is quite important. I can understand that some people might think this is irrelevant, but I personally think it is worth a small amount of time. Reproducible: Always
that's welp's fault
would you mind use this bug as a tracker, adding here the 4000 incriminated bugs.
(In reply to comment #1) > that's welp's fault I don't understand this comment. Can you please explain?
(In reply to comment #2) > would you mind use this bug as a tracker, adding here the 4000 incriminated > bugs. > I currently don't have a lot of time, this might change at the end of june, and july/august. I can add bugs in pieces though. Should I also check the contents of the bug, or should I assume that any bug that is older than 6 months is too old? Here is a sample, let me know if this is what you expect: Bug 36390 Bug 36732 Bug 37484 Bug 42103 Bug 50311 Bug 56654 Bug 56655 Bug 56656 Bug 56732 Bug 56891 Bug 56908 Bug 57455 Bug 58449 Bug 59013 Bug 60569 Bug 60665 Bug 60666 Bug 60669 Bug 60943 Bug 62880
(In reply to comment #3) > (In reply to comment #1) > > that's welp's fault > > I don't understand this comment. Can you please explain? > (He's basically blaming me for it all... :P)
(In reply to comment #0) > I can understand that some people might think this is irrelevant, but I > personally think it is worth a small amount of time. Well devs do close/resolve bugs. Bugreports should not be open after the issue is resolved. But it happens that someone fixes a bug and doesn't realize that there is a bugreport and so does not closed it. (In reply to comment #4) > (In reply to comment #2) > > would you mind use this bug as a tracker, adding here the 4000 incriminated > > bugs. > Here is a sample, let me know if this is what you expect: Maybe it helps us to understand your problem. I chose some random numbers and don't understand why these bugs should be closed. > Bug 36390 > Bug 36732 > Bug 37484 ^^^^^^^^^ not fixed > Bug 42103 > Bug 50311 > Bug 56654 > Bug 56655 ^^^^^^^^^ why do you think this one should be closed? > Bug 56656 > Bug 56732 > Bug 56891 > Bug 56908 > Bug 57455 > Bug 58449 > Bug 59013 > Bug 60569 ^^^^^^^^^ why? is it in prefix overlay? > Bug 60665 > Bug 60666 > Bug 60669 ^^^^^^^^^ why? > Bug 60943 > Bug 62880 >
(In reply to comment #6) > (In reply to comment #0) > > I can understand that some people might think this is irrelevant, but I > > personally think it is worth a small amount of time. > > Well devs do close/resolve bugs. Bugreports should not be open after the issue > is resolved. But it happens that someone fixes a bug and doesn't realize that > there is a bugreport and so does not closed it. > > (In reply to comment #4) > > (In reply to comment #2) > > > would you mind use this bug as a tracker, adding here the 4000 incriminated > > > bugs. > > > Here is a sample, let me know if this is what you expect: > > Maybe it helps us to understand your problem. I chose some random numbers and > don't understand why these bugs should be closed. The main reason with these bugs, is that they were last modified before the end of 2004. That's two and a half year ago. My reasoning was: if no-one cared about the bug for this long, they won't care about it in the future. I guess no maintainer will go through old bugs if no-one actually points out a problem. Don't you agree? > > > Bug 36390 > > Bug 36732 > > Bug 37484 > ^^^^^^^^^ not fixed > > > Bug 42103 > > Bug 50311 > > Bug 56654 > > Bug 56655 > ^^^^^^^^^ why do you think this one should be closed? The latest version of ferret, according to http://ferret.wrc.noaa.gov/Ferret/Downloads/ferret_downloads.html, is 6.02. This ebuild request is certainly outdated. > > > Bug 56656 > > Bug 56732 > > Bug 56891 > > Bug 56908 > > Bug 57455 > > Bug 58449 > > Bug 59013 > > Bug 60569 > ^^^^^^^^^ why? is it in prefix overlay? This is about gaim 0.8, also a very old version. I don't see any net-im in the prefix overlay. > > > Bug 60665 > > Bug 60666 > > Bug 60669 > ^^^^^^^^^ why? This is about gCrystal 0.6.1. The current release is 0.6.7. Furthermore, the person who posted the bug did not reply on the question that was asked. > > > Bug 60943 > > Bug 62880 > > >
I've gone over all stale bugs that were last changed before 2005-07-04 and added comments / pinged maintainers / checked upstream urls where applicable... someone can go on now as I'm heading off to bed ;)
So, you want this to make this a tracker for 4K+ bugs? Gimme a break, seriously. > it is worth a small amount of time. Small amount of time... lol... made my day. Someone close this, it's misassigned anyway and it's just crazy. If you care to get some bugs closed, then comment on them - don't make a monster tracker bug for bugs, it really doesn't work like that. Someone needs to check the status, that's not a small amount of time, that's couple of weeks worth of work at best for 4K bugs. Thanks.
(In reply to comment #9) > So, you want this to make this a tracker for 4K+ bugs? Gimme a break, > seriously. It was not my idea to make a tracker of this bug. For me, any way is fine. It's not up to me to make such decisions. > > > it is worth a small amount of time. > > Small amount of time... lol... made my day. Someone close this, it's > misassigned anyway and it's just crazy. If you care to get some bugs closed, > then comment on them - don't make a monster tracker bug for bugs, it really > doesn't work like that. Someone needs to check the status, that's not a small > amount of time, that's couple of weeks worth of work at best for 4K bugs. 'small amount of time' was indeed an understatement, and I realize it takes more than that. However, I still think it is worth it. Currently there's a trail left from the past. Furthermore, it doesn't take 10 minutes to check out a bug. In my opinion, bugs that are older than a year (or maybe even less) can be considered irrelevant and closed anyway. When someone cares about it, they will reopen it. This would certainly be the case for an ebuild request. For actual bugs, the situation is different, but if a large amount of time has passed, chances are high that a new version of the application in question already solved the problem. The bugs don't need to disappear within the next week. I don't know how many people have the permissions to change bug status, but suppose a person closes 10 of these bugs every night, by himself it would take 400 days. If 10 people take care of it, it is solved in 40 days. That's just over a month. And what did you mean with "misassigned" ? Thomas
What about this bug? The latest Gentoo Weekly News (7 May 2007) states that there were 10000 open bugs at that time. If about 4000 of them are old, this is I think a huge amount. What's wrong with the idea that very old bugs should be closed anyhow, as they are either already fixed, or nobody cares about them. Bugzilla allows several resolutions for these kind of bugs, like WONTFIX, LATER, NEEDINFO, etc. Any bug can always be reopened. In the case of old bugs, I think that is the best option. Other opinions?
(In reply to comment #11) > What's wrong with the idea that very old bugs should be closed anyhow, as they > are either already fixed, or nobody cares about them. Bugzilla allows several > resolutions for these kind of bugs, like WONTFIX, LATER, NEEDINFO, etc. Any bug > can always be reopened. In the case of old bugs, I think that is the best > option. > > Other opinions? Yes. If a bug is fixed the report should be closed (independent of age). If a bug is not fixed for whatever reason it should not be closed. Why? Because it makes it harder to find the report again. If someone sees the bug again and searches for an open bugreport and can't find one, a new bugreport will be opened. Introducing a new RESOLUTION like CLOSEDBECAUSEOLD won't help, will it? If a bugreport is rotting: We have bugday. Get the bugday people to add old bugreports to the bugday page and ask the volunteers to review the bugreports and get them closed (if appropriate) by someone in #gentoo-bugs. There should be a reason to close it - not just time.
(In reply to comment #12) > (In reply to comment #11) > > What's wrong with the idea that very old bugs should be closed anyhow, as they > > are either already fixed, or nobody cares about them. Bugzilla allows several > > resolutions for these kind of bugs, like WONTFIX, LATER, NEEDINFO, etc. Any bug > > can always be reopened. In the case of old bugs, I think that is the best > > option. > > > > Other opinions? > > Yes. > If a bug is fixed the report should be closed (independent of age). > If a bug is not fixed for whatever reason it should not be closed. Why? > Because it makes it harder to find the report again. If someone sees the bug > again and searches for an open bugreport and can't find one, a new bugreport > will be opened. Introducing a new RESOLUTION like CLOSEDBECAUSEOLD won't help, > will it? > > If a bugreport is rotting: We have bugday. Get the bugday people to add old > bugreports to the bugday page and ask the volunteers to review the bugreports > and get them closed (if appropriate) by someone in #gentoo-bugs. > > There should be a reason to close it - not just time. > Ok, bugday is a great idea. I only read about it yesterday, there already is a section "Old bugs" on the web page http://bugday.gentoo.org/. I agree with the fact that not any bug should be closed, however, many of the old bugs are either solved, are about ebuilds, or have requested information from the bug reporter, which did not reply. In the last case, I think CLOSED/NEEDINFO is a valid resolution.
Closing this CANTFIX because I really fail to see what are you requesting here. Please comment on individual bugs if they are resolved but haven't been closed by mistake. If they haven't been resolved, they need to stay open until they are fixed or until the ebuild is removed.