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