<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 24, 2016 at 1:34 AM, Duncan Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Cinder bugs list was far more manageable once this had been done.<br><br></div>It is worth sharing the tool for this? I realise it's fairly trivial to write one, but some standardisation on the comment format etc seems valuable, particularly for Q/A folks who work between different projects.<br></div></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">consistency sure seems like a nice thing to me.</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 May 2016 at 14:02, Markus Zoeller <span dir="ltr"><<a href="mailto:mzoeller@linux.vnet.ibm.com" target="_blank">mzoeller@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<span><font color="#888888"><br>
--<br>
Regards, Markus Zoeller (markus_z)<br>
<br>
<br>
__________________________________________________________________________<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><span class="HOEnZb"><font color="#888888"><br>
</font></span></font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div><div dir="ltr"><div>-- <br>Duncan Thomas</div></div></div>
</font></span></div>
<br>__________________________________________________________________________<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>
<br></blockquote></div><br></div></div>