Open Stack

Neil Jerram <Neil.Jerram at 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.

>
>> 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”.)

Same.

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

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

Ihar