Open Stack

Dave Walker wrote:
> On 10 June 2015 at 09:53, Thomas Goirand <zigo at debian.org> wrote:
>>> What would be your preferred option ?
>>
>> I see no point of doing D. I already don't use tarballs, and those who
>> do could as well switch to generating them (how hard is it to run
>> "python setup.py sdist" or "git archive"?).
>>
>> What counts is having a schedule date, where all distros are releasing a
>> point release, so we have a common reference point. If that is a fully
>> automated process, then great, less work for everyone, and it wont
>> change anything from what we had in the past (we can even collectively
>> decide for point release dates...).

That would be option B.

The main issue with B is that it doesn't work well once server component
versions start to diverge, which will be the case starting with Liberty.
You can't tag everything with the same version number anymore. We
already couldn't (with Swift using separate versioning), but we worked
around that by ignoring Swift from stable releases. As more projects opt
into that, that will no longer be a possible workaround.

So we could do what you're asking (option B) for Kilo stable releases,
but I think it's not really a viable option for stable/liberty onward.

> This is really one of the things I think we want to get away from...
> If *every* stable commit is treated with the seriousness of it
> creating a release, lets make every commit a release.
> 
> This means that Debian may be using a (micro)patch release newer or
> older than a different distro, but the key is that it empowers the
> vendors and/or users to select a release cadence that best fits them,
> rather than being tied to an arbitrary upstream community wide date.

+1

It also removes the stupid encouragement to use all components from the
same date. With everything tagged at the same date, you kinda send the
message that those various things should be used together. With
everything tagged separately, you send te message that you can mix and
match components from stable/* as you see fit. I mean, it's totally
valid to use stable branch components from various points in time
together, since they are all supposed to work.

So I totally get that we should still have reference points to be able
to tell "this is fixed in openstack/nova stable/liberty starting with
12.1.134post34" (or whatever we settle with). I totally get that any of
those should ship with relevant release notes. But that's about all I
think we need ?

-- 
Thierry Carrez (ttx)