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