<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 24 May 2016 at 18:05, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Markus Zoeller's message of 2016-05-24 11:00:35 +0200:<br>
<span class="">> On 24.05.2016 09:34, Duncan Thomas wrote:<br>
> > Cinder bugs list was far more manageable once this had been done.<br>
> ><br>
> > It is worth sharing the tool for this? I realise it's fairly trivial to<br>
> > write one, but some standardisation on the comment format etc seems<br>
> > valuable, particularly for Q/A folks who work between different projects.<br>
><br>
> A first draft (without the actual expiring) is at [1]. I'm going to<br>
> finish it this week. If there is a place in an OpenStack repo, just give<br>
> me a pointer and I'll push a change.<br>
><br>
> > On 23 May 2016 at 14:02, Markus Zoeller <<a href="mailto:mzoeller@linux.vnet.ibm.com">mzoeller@linux.vnet.ibm.com</a>> wrote:<br>
> ><br>
> >> 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>
> References:<br>
> [1]<br>
> <a href="https://github.com/markuszoeller/openstack/blob/master/scripts/launchpad/expire_old_bug_reports.py" rel="noreferrer" target="_blank">https://github.com/markuszoeller/openstack/blob/master/scripts/launchpad/expire_old_bug_reports.py</a><br>
><br>
<br>
</span>Feel free to submit that to the openstack-infra/release-tools repo. We<br>
have some other tools in that repo for managing launchpad bugs.<br>
<span class="HOEnZb"><font color="#888888"><br>
Doug</font></span></blockquote><div><br></div><div>Rather that blanket expiring old bugs, it might seem better to expire bugs which are in non-triaged state which haven't had activity for >18 months.  This would seem like a less aggressive approach to closing issues which haven't managed to reach triaged state and are otherwise stale.</div><div><br></div><div>This information is available in the API and i'd be happy to suggest a review to change to this model if it is agreed.</div><div><br></div><div>Thanks</div><div><br></div><div>--</div><div>Kind Regards,</div><div>Dave Walker</div></div></div></div>