Open Stack

Thanks to Thomas for continuing this discussion about networking-*
projects, and to Thierry for his responses below, and Ihar for his
earlier guidance.  I have a couple further points that I hope may
contribute...

On 19/11/15 09:46, Thierry Carrez wrote:
> Thomas Morin wrote:
>> The starting point for this post is a specific Neutron sub-project
>> (networking-bgpvpn) but I believe the issues raised are shared with
>> other neutron stadium project and possibly relevant beyond Neutron, to
>> projects tagged release-independent in general.
>>
>> In the context of the networking-bgpvpn project, we have a few unsolved
>> issues related to branches, more specifically about which branches we
>> can create to host active development to make our subprojet (a Neutron
>> service plugin) work with the last Openstack release and to backport it
>> with to earlier releases.
>>
>> Here are precisely the assumptions that we've made, largely based on the
>> fact that the project is tagged 'release-independent' (meaning
>> "completely bypass the 6-month cycle and release independently" [1]):
>> a) that we can make a release targeting Liberty much later than the
>> release date of Liberty
>> b) that we could make releases more frequent than the 6-month cycle ;
>> not only bugfix releases but also feature releases
>> c) that the idea of a release-independent project being backported to
>> work with past Openstack releases is acceptable (of course, without
>> requiring any change in release-managed projects, something largely
>> possible in many cases for projects such as a Neutron service plugin or
>> an ML2 driver)
> So we have three models. The release:independent model is for projects
> that don't follow the common development cycle, and therefore won't make
> a "liberty" release. The release:cycle-with-milestones model is the
> traditional "one release at the end of the cycle" model, and the
> release:cycle-with-intermediary model is an hybrid where you follow the
> development cycle (and make an end-of-cycle release) but can still make
> intermediary, featureful releases as necessary.
>
> The difference between the two groups is the concept of per-cycle
> branches (the stable/liberty branch which is used to maintain backports
> following the stable branch policy). Projects following the
> release:independent model should not have a stable/liberty branch, since
> they didn't formally do a liberty release. Those independent projects
> that have a stable/liberty branch are actually all
> release:cycle-with-intermediary projects that ignore their true nature.
>
> Looking at your specific case, it appears you could adopt the
> release:cycle-with-intermediary model, since you want to maintain a
> branch mapped to a given release. The main issue is your (a) point,
> especially the "much later" point. Liberty is in the past now, so making
> "liberty" releases now that we are deep in the Mitaka cycle is a bit
> weird. When are you likely to start shipping your liberty branch ?
>
> Maybe we need a new model to care for such downstream projects when they
> can't release in relative sync with the projects they track.

On the other hand this could just be a matter of discipline and
planning, and of networking-* projects still being quite new. 
networking-calico is currently release:independent, and was only created
a short time before the Liberty release, and was not completely ready at
the time of the Liberty release.  But I believe that that it would be
achievable if the project targeted moving into sync with the Mitaka
cycle, and hence then could be release:cycle-with-milestones or
release:cycle-with-intermediary.

>
>> Note that we aren't the only big tent project having this kind of
>> expectations (e.g. [3]).

I'd like to say a little more about branch thinking in
networking-calico, as I think it may be another useful data point.  The
last exchange on this, between Ihar and me, was as follows:

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

I've since realised that my initial statement above wasn't quite right. 
In fact, because networking-calico uses Neutron interfaces that are
pretty stable (ML2 mech driver, DHCP interface driver, etc.) we have
found it manageable until now to develop a single (master) branch of the
networking-calico code that works with all of the OpenStack releases
(Icehouse..Liberty) that we have tested with; and I'd like if possible
to continue doing that.

On reflection, therefore, I believe it's correct that networking-calico
development has been happening, and continues to happen, on its master
branch, and I hope that we won't ever need stable branches *for the
reason of working with different OpenStack releases* (e.g. if it become
too difficult to target many OpenStack releases from a single branch).

On the other hand, we may well (in future) want stable branches at times
when we are working on disruptive changes in the networking-calico code
itself.  But there should be no reason for those to be named like
'stable/liberty' etc.

>>
>> The rest of this email follows from these assumptions.
>>
>> To do (a) and (c) we need separate branches in which to do active work.
>> We have understood clearly that given the contract around 'stable/*'
>> branches, the branches in which to do this active work cannot be named
>> 'stable/*'.
>>
>> Where we are today:
>> - we do active development, planning a liberty release soon, on our
>> 'master' branch
>> - we have a 'backport/kilo' and a 'backport/juno' branches in which we
>> plan to make the necessary changes to adapt with Neutron kilo and juno;
>> these branches were created by Neutron core devs for us [5], based on
>> the common understanding that choosing 'stable/*' branch names for
>> branches with active development would be a huge no no
>> [...]
> So we had that discussion at the last design summit: how should we name
> those branches that track a given release cycle but do not necessarily
> follow the common stable branch policy. My initial idea was to reserve
> usage of the stable/* name to things following stable branch policy. But
> that creates a number of issues on the infra side, some of which you've
> already hit.
>
> So we discussed the idea of calling them all stable/*, and use a tag to
> designate which of those branches actually follow the standard stable
> branch policy (rather than relying on the branch name to determine that).

That sounds like a good idea to me.  I imagine that many Neutron stadium
release:independent projects would not have that tag.

>
>> [...]
>> ### Doing multiple releases inside one 6-month Openstack cycle issue
>>
>> Our initial plan was to fork a 'stable/liberty' branch from our master
>> at the same time as our first release.
>> But after this we don't know how to work on new features for a release
>> still targeting Liberty:
>> - adding features on stable/liberty is  a no no
>> - there is no established practice, as far as we know, to name such
>> branches, nor to track that they aim to work with Liberty
>>
>> We haven't a solution for that right now, and we definitely want guidance.
> Under the proposed model above, adding "features" to a stable/* branch
> would be ok. You just would not get the "follows-stable-branch-policy" tag.
>
> So I would say the next steps are:
>
> * have an internal discussion in the release team on how to model those
> projects that want to track a given release cycle but will lag. Should
> they be independent, cycle-with-intermediary, or a new thing ?
>
> * have an internal discussion in the to-be-created stable branch
> maintenance team about using a tag (instead of reserving the stable/*
> name) to signal which branches are following the common stable branch
> policy.
>
> Thanks for being patient while we adjust the framework so that you can
> do work into it :)
>

Thanks to you too!

    Neil