Open Stack

Thierry Carrez wrote:
> Thanks everyone for the constructive discussion on this. Lots of good
> stuff. Let me summarize the objections so far:
> 
> 1. we'd lose the focus rhythm
> 
> Point releases triggered some attention to stable branches: the
> necessity to fix the CI there when it's broken, and a surge in backports
> activity.

The focus rhythm was (a) less effective recently as more projects just
ignored the stable release windows and (b) less necessary since we
switched to per-project stable maintenance teams that regularly backport
stuff. I actually tend to think that getting rid of the "let's care
about stable branches only every 2 months" mentality would be a plus.

> 2. it would be difficult to get proper release notes
> 
> If we don't have point releases anymore, we don't have release notes
> anymore. Release notes contain various types of information: the list of
> security fixes, the occasional upgrade warning, and the list of bugfixes.

We'd probably have to find a way to provide the same information in the
tarball itself, so that if you picked any of them you could still get a
list of the fixes in there.

> 3. we'd lose reference points
> 
> Tagged versions made great common reference points to share information
> between various distros/deployments. If a distro packaged 2014.2.2, you
> could take the same tag and package it and assume it was the same thing.
> They also served as "fixed in version X" information on OSSAs.

That one is a valid concern. It is true that the proposed change will
result in making it more difficult to compare post-release deployments
and google for "fixed in 2015.1.1" information. Please note that this
"reference point" was rather fuzzy, since distros would end up applying
their own extra patches on top of our tag, so you are actually not
comparing the exact same thing anyway. But I'd agree that it provided
marginal value.

> 4. we'd lose the "works well together" piece of information
> 
> The various pieces tagged with the same version number could be assumed
> to work well together. Recovering that would have to be pieced back
> together from commit dates and/or openstack/openstack stable branches.

I think this one is an illusion. Stable branch policy enforces that
there is no change in API or behavior in stable branches. So you could
technically take any commit from any branch and it should work as well
together as the "release" one. For those who really want a "CI-tested
combination", I think they can go through the extra hassle of
determining one through openstack/openstack stable branches.

So.. what now ? What would be an alternate solution ?

Plan B
======

We could continue to push random synchronization tags to solve (3). We'd
get rid of most of the release process and just tag things tested
together on a given date (solving (4)). We should find a way to
outsource release notes maintenance to each project, possibly by
maintaining those in stable branches directly (solving (2)).

For kilo we can still call those 2015.1.X and apply them on the Kilo
"integrated release" set of projects.

For liberty we will no longer have an inner sanctum of "integrated"
projects. So we could tag all "server" OpenStack projects which maintain
a stable branch. Since versioning will continue to diverge, the version
tagged will be different for every project, which will be confusing. So
we could also additionally tag with something like "liberty SP1" across
the board to facilitate finding the various pieces tagged at the same
moment.

Coming back to our original list of problems we wanted to solve:

> (1) Projects do not all follow the same versioning, so some projects
> (like Swift) were not part of the "stable point releases". More and more
> projects are considering issuing intermediary releases (like Swift
> does), like Ironic. That would result in a variety of version numbers,
> and ultimately less and less projects being able to have a common
> "2015.1.1"-like version.

I think the alternate proposal is a bit confusing (since over the long
run projects will not have the same version numbers, but people will be
used to assume that anything tagged with the same version number was
issued around the same time).

> (2) Producing those costs a non-trivial amount of effort on a very small
> team of volunteers, especially with projects caring about stable
> branches in various amounts. We were constantly missing the
> pre-announced dates on those ones. Looks like that effort could be
> better spent improving the stable branches themselves and keeping them
> working.

The alternate proposal is slightly less costly than the current
situation (no stable release prep period, just a very large set of tags
to push), but obviously more costly than just getting rid of the whole idea.

> (3) The resulting "stable point releases" are mostly useless. Stable
> branches are supposed to be always usable, and the "released" version
> did not undergo significantly more testing. Issuing them actually
> discourages people from taking whatever point in stable branches makes
> the most sense for them, testing and deploying that.

I still think point releases convey the wrong message, which is that you
should not trust the stable branch unless it's blessed as a point
release. It also reinforces the idea that you can't run a 2015.1.1 nova
with a 2015.1.0 glance, which (if stable branch policy is respected) is
plain wrong.

So I'm not convinced the alternate proposal is a better trade-off than
the "let's just stop tagging common point releases altogether" proposal.

*Plan C* would be to just let projects tag stable point releases from
time to time. That would solve all the original stated problems. And
that would solve objections 2 and 3, which I think are the most valid ones.

-- 
Thierry Carrez (ttx)