<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 23 November 2015 at 13:58, 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">As part of completing the release automation work and deprecating our<br>
use of Launchpad for release content tracking, we also want make some<br>
changes to the way patches associated with bugs are handled.<br>
<br>
Right now, when a patch with Closes-Bug in the commit message merges,<br>
the bug status is updated to "Fix Committed" to indicate that the change<br>
is in git, but not a formal release, and we rely on the release tools to<br>
update the bug status to "Fix Released" when the release is  made. This<br>
is one of the most error prone areas of the release process, due to<br>
Launchpad service timeouts and other similar issues. The fact that we<br>
cannot reliably automate this step is the main reason we want to stop<br>
using Launchpad's release content tracking capabilities in the first<br>
place.<br>
<br>
To make the release automation reliable, we are going to change the<br>
release scripts to comment on bugs, but not update their status, when a<br>
release is cut. Unfortunately, that leaves the bugs with "Fix Committed"<br>
status, which is still considered "open" and so those bugs clutter up<br>
the list of bugs for folks who are looking for ways to help. So, we<br>
would like to change the default behavior of our CI and review system so<br>
that when a patch with Closes-Bug in the commit message merges the bug<br>
status is updated to "Fix Released" instead of "Fix Committed".<br>
<br>
We already have quite a few projects set up this way, using the<br>
direct-release option to jeepyb (configured in the gerrit settings in<br>
the project-config repository). I'm proposing that we change jeepyb's<br>
behavior, rather than applying that flag to all of our projects. We will<br>
also add a 'delay-release' flag to jeepyb for projects that want to<br>
revert to the old behavior.<br>
<br>
Please let me know if this change would represent a significant<br>
regression to your project's workflow.<br></blockquote><div><br></div><div>When would this change be in effect?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Doug<br>
<br>
The infra spec related to this work is: <a href="https://review.openstack.org/#/c/245907/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/245907/</a><br>
The jeepyb change is: <a href="https://review.openstack.org/248922" rel="noreferrer" target="_blank">https://review.openstack.org/248922</a><br>
The project-config change to remove the direct-release option from<br>
projects: <a href="https://review.openstack.org/#/c/248923" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/248923</a><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><br>
</blockquote></div><br></div></div>