> On Nov 19, 2015, at 9:28 AM, Thomas Morin <[email protected]> wrote: > > 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 ?
It raises your chances of having your project packaged in distributions along with the other compatible components, and it clearly tells deployers of your project which versions are meant to go with those other components. > > (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) We tend to view the milestone model as suitable for either immature or tightly-coupled projects. Mature, loosely coupled, projects are encouraged to use the intermediary release model. > > >> 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” ? Again, it’s about signaling where your project fits into the ecosystem of other projects. > >> 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). We call them stable branches because we don’t expect them to receive a lot of new features. If you depend on having the final release of neutron for a series available before you can finalize your project, that is indeed a new model. But as I said in my other email, it’s not clear that’s something desirable, and it would be better to have the stadium projects released closer in sync with core neutron. > > >>> 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 . I believe it is already possible to configure cross-branch jobs, since we’ve done that with Oslo libraries in the past. > > 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). I don’t think the community needs to support that. We agree, as a group, how long we’re going to support old stable releases. > >> * 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 > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
