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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev