[openstack-dev] [neutron][stable] Understanding stable/branch process for Neutron subprojects

Neil Jerram Neil.Jerram at metaswitch.com
Fri Nov 6 13:28:52 UTC 2015


Prompted by the thread about maybe allowing subproject teams to do their
own stable maint, I have some questions about what I should be doing in
networking-calico; and I guess the answers may apply generally to
subprojects.

Let's start from the text at
http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html:

> Stable branches for libraries should be created at the same time when

"libraries"?  Should that say "subprojects"?

> corresponding neutron stable branches are cut off. This is to avoid
> situations when a postponed cut-off results in a stable branch that
> contains some patches that belong to the next release. This would
> require reverting patches, and this is something you should avoid.

(Textually, I think "created" would be clearer here than "cut off", if
that is the intended meaning.  "cut off" could also mean "deleted" or
"stop being used".)

I think I understand the point here.  However, networking-calico doesn't
yet have a stable/liberty branch, and in practice its master branch
currently targets Neutron stable/liberty code.  (For example, its
DevStack setup instructions say "git checkout stable/liberty".)

To get networking-calico into a correct state per the above guideline, I
think I'd need/want to

- create a stable/liberty branch (from the current master, as there is
nothing in master that actually depends on Neutron changes since
stable/liberty)

- continue developing useful enhancements on the stable/liberty branch -
because my primary target for now is the released Liberty - and then
merge those to master

- eventually, develop on the master branch also, to take advantage of
and keep current with changes in Neutron master.

But is that compatible with the permitted stable branch process?  It
sounds like the permitted process requires me to develop everything on
master first, then (ask to) cherry-pick specific changes to the stable
branch - which isn't actually natural for the current situation (or
targeting Liberty releases).

I suspect I'm missing a clue somewhere - thanks for any input!

Regards,
    Neil




More information about the OpenStack-dev mailing list