Open Stack

> On Nov 19, 2015, at 4:43 AM, Thierry Carrez <thierry at openstack.org> 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.

In my mind the “independent” release model was originally meant to mean that the project was completely on their own, doing potentially incorrect and random releases. It wasn’t something I anticipated projects *wanting* to use. It evolved to mean something closer to the opposite of the “managed” tag, but I think we should pull back from that use. We want projects to clearly indicate which of the other cycle-oriented models they intend to follow, and we want something cycle-based for most projects to help distributors and deployers understand which versions of things should be used together.

If neither of the existing cycle-based tags meets the needs of a large number of projects, then we should have a clear description of the model actually being followed so we can tag the projects following it. That may mean, in this case, a cycle-with-intermediary-following or something similar, to mean “we have cyclical releases but they come after the cycle of most of the other projects”.

On the other hand, it would be better to work to sync up development. If you’re releasing long after the other projects do, distributors may not prioritize packaging the project at all.

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

It’s unfortunate that we have so many tools that depend on the “stable/“ prefix. I looked, and in addition to devstack-gate the release tools assume the name stable. It’s not something we can change this cycle, because of the other priorities, but it would be useful to think about whether we could treat a series/ prefix the same way as stable/ in those tools, to have an option for the branch name. I have no idea how much work that would be. In the mean time, I agree that using the tag as the true indicator that the stable policy is being followed is a good compromise.

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

I’ve added that to the meeting agenda for this week so we can at least work out next steps.

> 
> * 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 :)
> 
> -- 
> Thierry Carrez (ttx)
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev