[Openstack] [RFC] Stable branch

Mark McLoughlin markmc at redhat.com
Thu Oct 13 07:39:17 UTC 2011


Hi James,

On Wed, 2011-10-12 at 13:58 -0400, James E. Blair wrote:
> Mark McLoughlin <markmc at redhat.com> writes:
> 
> > Hey,
> >
> > I've posted a proposal for how the stable branch could work here:
> >
> >   http://wiki.openstack.org/StableBranch
> >
> > and a proposed diablo branch for nova:
> >
> >   http://github.com/markmc/nova/tree/diablo
> >
> > The wiki page seems to be 404 for folks for some bizarre reason, but you
> > can get to it from:
> 
> Works for me.
> 
> > I've also appended it below so folks can reply to specific points
> > inline.
> 
> Thanks for getting this started!

Chuck pointed out on IRC that I forgot to mention the other projects.

I totally think we should do the same for all projects, I was just using
Nova as a testcase.

> > Each project will have a branch named after the previous release. For
> > example, the stable branch for the diablo release will be simply
> > called 'diablo'.
> 
> Sounds good.  I'll create branches in gerrit named 'diablo' branching
> from the commit with the 2011.3 tag.  I think we can update the release
> management process to incorporate this step for essex.

Cool stuff.

Does the current diablo branch for Nova pass all tests on jenkins?
Perhaps we should start by bypassing jenkins and pushing these commits
directly to the branch:

  $> $ git log --oneline origin/diablo..d6137fb
  d6137fb Fix outstanding pep8 errors for a clean trunk.
  b0e855e Removing old code that snuck back in
  6503923 Made jenkins email pruning more resilient.
  ba68a78 Don't use GitPython for authors check
  3a63bd5 Add tools/rfc.sh from master

> > The stable branch will only be maintained until the next release is out.
> 
> My preference is to only have branches in gerrit and on github where we
> are actively accepting changes.  Otherwise it may appear that we would
> accept proposed changes to diablo indefinitely.  So I'd like to suggest
> that when the maintainers stop maintaining the branch that we tag the
> last commit and then remove the branch.  We won't lose any information
> this way; the tag alone is enough to access the commit history of the
> branch.  This is the current process in place for milestone-proposed.

Not unreasonable, but I don't know of any other project that deletes its
stable branch so I'm not sure it's really a problem in practice.

> > Anyone can propose a cherry-pick to the maintainers. This helps ensure
> > that the maintainers don't miss anything. To catch the maintainers
> > attention, simply add
> >
> >  Cc: stable at openstack.org
> 
> Are you planning on grepping commit logs for that, or are you asking
> people to email that address?

Yeah, it's just a marker to grep for.

Having a stable at openstack.org alias might be no harm, though.

> > to the commit message. If the patch you're proposing will not
> > cherry-pick cleanly, you can help by resolving the conflicts yourself
> > and proposing the resulting patch.
> >
> > All changes to the stable branch will go through gerrit. The branch
> > maintainers and core teams of each project can +1 the changes.
> 
> Permissions in gerrit can be configured on a per-branch basis.
> Currently, we let anyone +/-1 a change, and only core devs can +/-2.  A
> strict analog would be to continue to allow general +/-1 feedback and
> only members of the maintainers team or core devs can +/-2.  How does
> that sound?

That sounds cool.

> I've created a group in Launchpad, openstack-stable-maint ("Openstack
> Stable Branch Maintainers"), that I'll give permission to approve
> changes to stable branches in Gerrit.  As we discussed an the summit,
> I've added Chuck Short, Dave Walker, and Mark McLoughlin as admins to
> that group; they can approve membership applications.

Awesome, thanks James.

Cheers,
Mark.





More information about the Openstack mailing list