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" ):
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" 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. ).
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
Where we are today:
- we do active development, planning a liberty release soon, on our
- 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 , 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
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
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
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)
OpenStack Development Mailing List (not for usage questions)