[openstack-dev] [release] process change for closing bugs when patches merge

Doug Hellmann doug at doughellmann.com
Tue Nov 24 14:06:35 UTC 2015


Excerpts from Armando M.'s message of 2015-11-23 17:37:47 -0800:
> On 23 November 2015 at 13:58, Doug Hellmann <doug at doughellmann.com> wrote:
> 
> > 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.
> >
> 
> When would this change be in effect?

I would like to get it in place by next week, but I need to coordinate
with the infra team to make sure my proposed changes are technically
correct. I'll announce the change when it does go into effect, and
before we do the bulk update of existing tickets that Thierry
mentioned.

Doug

> 
> >
> > 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
> >



More information about the OpenStack-dev mailing list