I support Clint's comment, and as an example, only today I was able to search a bug and to see it was reported 2 years ago and wasn't solved since. I've commented on the bug saying it happened to me in an up-to-date nova. I'm talking about a bug which is on your list - https://bugs.launchpad.net/nova/+bug/1298075
I guess I wouldn't been able to do so if the bug was closed. On Mon, May 30, 2016 at 9:37 PM, Clint Byrum <cl...@fewbar.com> wrote: > (Top posting as a general reply to the thread) > > Bugs are precious data. As much as it feels like the bug list is full of > cruft that won't ever get touched, one thing that we might be missing in > doing this is that the user who encounters the bug and takes the time > to actually find the bug tracker and report a bug, may be best served > by finding that somebody else has experienced something similar. If you > close this bug, that user is now going to be presented with the "I may > be the first person to report this" flow instead of "yeah I've seen that > error too!". The former can be a daunting task, but the latter provides > extra incentive to press forward, since clearly there are others who > need this, and more data is helpful to triagers and fixers. > > I 100% support those who are managing bugs doing whatever they need > to do to make sure users' issues are being addressed as well as can be > done with the resources available. However, I would also urge everyone > to remember that the bug tracker is not only a way for developers to > manage the bugs, it is also a way for the community of dedicated users > to interact with the project as a whole. > > Excerpts from Markus Zoeller's message of 2016-05-23 13:02:29 +0200: > > TL;DR: Automatic closing of 185 bug reports which are older than 18 > > months in the week R-13. Skipping specific bug reports is possible. A > > bug report comment explains the reasons. > > > > > > I'd like to get rid of more clutter in our bug list to make it more > > comprehensible by a human being. For this, I'm targeting our ~185 bug > > reports which were reported 18 months ago and still aren't in progress. > > That's around 37% of open bug reports which aren't in progress. This > > post is about *how* and *when* I do it. If you have very strong reasons > > to *not* do it, let me hear them. > > > > When > > ---- > > I plan to do it in the week after the non-priority feature freeze. > > That's week R-13, at the beginning of July. Until this date you can > > comment on bug reports so they get spared from this cleanup (see below). > > Beginning from R-13 until R-5 (Newton-3 milestone), we should have > > enough time to gain some overview of the rest. > > > > I also think it makes sense to make this a repeated effort, maybe after > > each milestone/release or monthly or daily. > > > > How > > --- > > The bug reports which will be affected are: > > * in status: [new, confirmed, triaged] > > * AND without assignee > > * AND created at: > 18 months > > A preview of them can be found at [1]. > > > > You can spare bug reports if you leave a comment there which says > > one of these (case-sensitive flags): > > * CONFIRMED FOR: NEWTON > > * CONFIRMED FOR: MITAKA > > * CONFIRMED FOR: LIBERTY > > > > The expired bug report will have: > > * status: won't fix > > * assignee: none > > * importance: undecided > > * a new comment which explains *why* this was done > > > > The comment the expired bug reports will get: > > This is an automated cleanup. This bug report got closed because > > it is older than 18 months and there is no open code change to > > fix this. After this time it is unlikely that the circumstances > > which lead to the observed issue can be reproduced. > > If you can reproduce it, please: > > * reopen the bug report > > * AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>" > > Only still supported release names are valid. > > valid example: CONFIRMED FOR: LIBERTY > > invalid example: CONFIRMED FOR: KILO > > * AND add the steps to reproduce the issue (if applicable) > > > > > > Let me know if you think this comment gives enough information how to > > handle this situation. > > > > > > References: > > [1] http://45.55.105.55:8082/bugs-dashboard.html#tabExpired > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev