Open Stack

On 06/11/15 13:46, Ihar Hrachyshka wrote:
> 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.

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