On 06/11/15 13:46, Ihar Hrachyshka wrote: > Neil Jerram <neil.jer...@metaswitch.com> wrote: > >> 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”? > Yes. Please send a patch to fix wording.
https://review.openstack.org/#/c/242506/ > 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".) > > Well that’s unfortunate. You should allow devstack to check out the needed > branch for neutron instead of overwriting its choice. I'm afraid I don't understand, could you explain further? Here's what the setup instructions [1] currently say: # Clone the DevStack repository. git clone https://git.openstack.org/openstack-dev/devstack # Use the stable/liberty branch. cd devstack git checkout stable/liberty What should they say instead? [1] https://git.openstack.org/cgit/openstack/networking-calico/tree/devstack/bootstrap.sh > >> 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 >> > Once spinned out, stable branches should receive bug fixes only. No new > features, db migrations, configuration changes are allowed in stable > branches. > >> - eventually, develop on the master branch also, to take advantage of >> and keep current with changes in Neutron master. >> > All new features must go to master only. Your master should always be > tested and work with neutron master (meaning, your master should target > Mitaka, not Liberty). > >> 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). >> > Yes, that’s what current stable branch process implies. All stadium > projects must follow the same stable branch process. > > Now, you may also not see any value in supporting Liberty, then you can > avoid creating a branch for it; but it seems it’s not the case here. > > All that said, we already have stadium projects that violate the usual > process for master (f.e. GBP project targets its master development to kilo > - sic!) I believe that’s something to clear up as part of discussion of > what it really means to be a stadium project. I believe following general > workflow that is common to the project as a whole is one of the > requirements that we should impose. Thanks for these clear answers. I'll work towards getting all this correct. 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
