Version: (using Devel) Compiler: n/a OS: Linux Installed from: Compiled sources While I may be playing a misguided "captain obvious" here, but it may help a lot to automatically retire bug reports which were not accessed in a considerable period of time. Currently, bugzilla searches are quite polluted with "open/unconfirmed" bugs opened for old and long superseded versions of KDE. If somebody is still interested in the old bugs being closed, they will have a chance to reopen them upon getting a usual bug status change notification.
bugzilla.mozilla.org did the same thing a few years ago. They robo-resolved inactive unconfirmed (unconfirmed because unconfirmable) bug reports. Automated UNCONFIRMED resolution http://blog.gerv.net/2004/09/automated_uncon/ They also used robo-canned texts (similar to what is planned in bug 186800) to warn bug reporters about this. Gérard
Microsoft and its connect IE beta feedback system also closed inactive (when bug reporter was not replying to questions asked) and non-actionable bug reports during the IE8 beta feedback period of time (between september 2006 and march 2008). A bug report which is unconfirmed for a long time, which unconfirmable and not actionable should be closed. Gérard
(In reply to comment #1) > bugzilla.mozilla.org did the same thing a few years ago. The interesting question to learn from is why Mozilla stopped using it, as I have not seen any auto-closed tickets in bugzilla.mozilla.org for the one year that I've been following it more closely, and as there is no such keyword existing to mark reports as auto-closed. Querying for the string "This bug has been automatically resolved after a period of inactivity" lists 162 closed reports (all previously RESOLVED EXPIRED, turned into RESOLVED DUPLICATE). That's really not much for that database.
> The interesting question to learn from is why Mozilla stopped using it, as I > have not seen any auto-closed tickets in bugzilla.mozilla.org for the one > year that I've been following it more closely, and as there is no such > keyword existing to mark reports as auto-closed. They introduced the INCOMPLETE value for status field. " INCOMPLETE The problem is vaguely described with no steps to reproduce, or is a support request. The reporter should be directed to the product's support page for help diagnosing the issue. If there are only a few comments in the bug, it may be reopened only if the original reporter provides more info, or confirms someone else's steps to reproduce. If the bug is long, when enough info is provided a new bug should be filed and the original bug marked as a duplicate of it. " https://bugzilla.mozilla.org/page.cgi?id=fields.html#status > Querying for the string "This bug has been automatically resolved after a > period of inactivity" lists 162 closed reports (all previously RESOLVED > EXPIRED, turned into RESOLVED DUPLICATE). I remember that there were many many more than 162 bug reports which received a pre-edited warning asking the bug reporter to re-confirm that the bug was still occuring. Thousands of bug reports. bugzilla.mozilla.org started with a small batch of inactive unconfirmed bug reports, with the ones that had not been active for many years; then with other batches. I was strongly for robo-resolving inactive (for a long time) unconfirmed bug reports. The biggest problem with open, accessible bug tracking systems is when the user reports an issue (admittedly to the best of his/her abilities) and then runs away and does not reply to any questions, queries directed to him/her about his bug report. Gérard
Automatic Resolution of UNCONFIRMED Bugs Posted on March 28, 2005 http://blog.gerv.net/2005/03/automatic_resol/ Varied Reactions Posted on September 30, 2005 http://blog.gerv.net/2005/09/varied_reaction/ I was the one who wrote to Gervase Markham this: " Allow me to repeat and to underline that I support very much this initiative/measure/feature of robo-resolving 12,342 inactive unconfirmed bugs. This feature includes a 2 week grace period: that is a sane, sound and absolutely fair period of time. I am 100% convinced that such measure will do overwhelmingly more good (much more good) than do bad. The balance of benefits versus inconvenients and implied trade-off in this feature will bring a lot of fresh air into a deeply rotten mass of bugreports which no longer made any sense. Again, you have my unconditional one thousand percent (1000%) support in this initiative. " Gérard
Also: Auto-UNCO Info Posted on September 28, 2005 http://blog.gerv.net/2005/09/ " We don’t have enough manpower to triage all the bugs in Bugzilla. This is abundantly clear from the charts ( https://bugzilla.mozilla.org/reports.cgi?product=-All-&datasets=NEW%3A&datasets=UNCONFIRMED ) . " Also: https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&long_desc_type=substring&long_desc=auto-resolve01&bug_status=UNCONFIRMED&resolution=---&chfieldto=Now&query_based_on=auto+commented&field0-0-0=delta_ts&type0-0-0=greaterthan&value0-0-0=2005-09-28 lists *_19,171_* bug reports which have been auto-commented in the process. Gérard
Fedora gives a notification for some bugs automatically when end-of-life of the release is approaching. But I'd agree that some kind of clean-up with a grace time could do good in general (looking atm bugs.kde.org bugs, which may not even be valid after a couple of upgrades..).
I expect this wouldn't change anything. I suppose 99% of tickets are crawled at least every 3 years by at least Google Search. So bots would need to be excluded, which would be a complicated task for the little (if any) benefits this would provide.
Google doesn't crawl bugs.kde.org.
(In reply to Christoph Feck from comment #9) > Google doesn't crawl bugs.kde.org. Why?