Open Stack

Hi Thierry,

Thanks for you answers, more below.

Thierry Carrez :
> 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.

I get your point. This would indeed correctly model intermediate releases.
But since no other project in Openstack depends on networking-bgpvpn, 
what is the value of forcing a release of the project synched at the end 
of a cycle ?

(also, there is maybe an implication of release milestones and code 
freezes that may be overkill for some big tent projects, in particular 
when they are young)


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

"weird" I don't know: isn't it consistent with "release independently" ?

> When are you likely to start shipping your liberty branch ?

We're mostly done and we target November.

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

I would think so.

The reason is that we want to still do the majority of the work in one 
branch, to avoid the overhead of cherry-picking between branches a large 
amount of changes (e.g. if we had been working in a liberty branch since 
September, all this work would have had to be cherry-picked to our 
master -- and vice-versa: working in master would have meant 
cherry-picking everything in the liberty branch).


>> Note that we aren't the only big tent project having this kind of
>> expectations (e.g. [3]).
>>
>> 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).

Since some issues seems to be related to the fact that various semantic 
and behavior
are tied to the stable/* name, decoupling seems to makes sense.

>> [...]
>> ### 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 ?

Given the issue we hit, it seems the infra team needs to be involved as 
well to decide in these cases how to make the tools aware that 
project-foo's master is tracking Openstack stable/x .

Another thing to plan for is project that for some reason would end up 
with their master tracking a stable release older than the last one (not 
what networking-bgpvpn is targeting, but rumors mention that to be 
existing in some places).

> * 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 :)
>

We will be glad to patient and be pilot for whatever ends up being 
decided as being the right thing.

But still...one last, very practical, question: until the framework is 
adjusted, can we pursue our liberty-targeted work in our master branch, 
and our backport work in our backport/kilo and backport/juno branches  ?
(of course, we will accept the inconvenience of having these renamed to 
stable/x if that becomes the right thing to do)

-Thomas