[openstack-dev] [release][ptl][all] self-service branch management

Doug Hellmann doug at doughellmann.com
Wed Dec 14 22:04:45 UTC 2016

Excerpts from Emilien Macchi's message of 2016-12-14 15:34:27 -0500:
> On Wed, Dec 14, 2016 at 8:45 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> > [Sending again due to mail delivery issues.]
> >
> > The release team is pleased to announce that the branch automation
> > work is now complete, and that teams can now manage feature and
> > stable branch creation through the openstack/releases repository.
> >
> > Creating a branch is very similar to creating a release: Edit the
> > appropriate file in the releases repo to add the branch information,
> > let the release team review it, and then when the patch is approved
> > the bots make your branch. New branches come with patches to update
> > .gitreview, reno, and constraint settings where needed.
> >
> > For the complete details about how to format a branch request, see
> > the README.rst file in the repo [1].
> >
> > Thanks, as always, to the Infra team for their help in implementing
> > this automation.
> That's awesome, and we were looking forward to it.
> Regarding schedule, it's not clear to me when we *have to* propose the branches.
> For example in TripleO, we've noticed that our work on upgrades
> usually happens more at the end of a cycle so we would like to wait
> for the last time before branching our repos.
> Example with Ocata, when would you suggest to start branching?

We will expect most teams following the cycle-with-milestones model
to branch at RC1, as part of the usual milestone-centric process.

Projects following-the cycle-with-intermediary or cycle-trailing
models should branch when the equivalent of their first release
candidate is ready. It's going to be up to the individual teams to
decide that, because you're better placed to know when it's too
early to branch. Keep in mind that the reason the milestone-based
projects use release candidates is to have a stable version of the
project ready to be tested before being marked as a final release.

Based on that criteria, when development (feature and bug fixing)
slows down toward the end of the cycle, start thinking about


More information about the OpenStack-dev mailing list