Open Stack

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.

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

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

-- 
Thierry Carrez (ttx)