Open Stack

So it's only for this time around (Mitaka-1) that I'll have to tag bugs as
fix-released, because the release automation will just leave a comment?

Going forward, the bugs will be automatically marked as fix-released, so
the automation won't change their states when we release?

Thanks,

Steve Martinelli
OpenStack Keystone Project Team Lead



From:	Doug Hellmann <doug at doughellmann.com>
To:	openstack-dev <openstack-dev at lists.openstack.org>
Date:	2015/11/23 05:00 PM
Subject:	[openstack-dev] [release] process change for closing bugs when
            patches merge



As part of completing the release automation work and deprecating our
use of Launchpad for release content tracking, we also want make some
changes to the way patches associated with bugs are handled.

Right now, when a patch with Closes-Bug in the commit message merges,
the bug status is updated to "Fix Committed" to indicate that the change
is in git, but not a formal release, and we rely on the release tools to
update the bug status to "Fix Released" when the release is  made. This
is one of the most error prone areas of the release process, due to
Launchpad service timeouts and other similar issues. The fact that we
cannot reliably automate this step is the main reason we want to stop
using Launchpad's release content tracking capabilities in the first
place.

To make the release automation reliable, we are going to change the
release scripts to comment on bugs, but not update their status, when a
release is cut. Unfortunately, that leaves the bugs with "Fix Committed"
status, which is still considered "open" and so those bugs clutter up
the list of bugs for folks who are looking for ways to help. So, we
would like to change the default behavior of our CI and review system so
that when a patch with Closes-Bug in the commit message merges the bug
status is updated to "Fix Released" instead of "Fix Committed".

We already have quite a few projects set up this way, using the
direct-release option to jeepyb (configured in the gerrit settings in
the project-config repository). I'm proposing that we change jeepyb's
behavior, rather than applying that flag to all of our projects. We will
also add a 'delay-release' flag to jeepyb for projects that want to
revert to the old behavior.

Please let me know if this change would represent a significant
regression to your project's workflow.

Doug

The infra spec related to this work is:
https://review.openstack.org/#/c/245907/
The jeepyb change is: https://review.openstack.org/248922
The project-config change to remove the direct-release option from
projects: https://review.openstack.org/#/c/248923


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151123/e48c3037/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151123/e48c3037/attachment.gif>