Open Stack

Thomas Goirand wrote:
> On 06/10/2015 03:46 PM, Thierry Carrez wrote:
>> 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.
> 
> I fail to understand how version numbers are related to doing
> synchronized point releases. Sure, we have a problem with the version
> numbers, but we can still do a point release of all the server projects
> at once.

Agreed. We could still do a "coordinated point release" without using
the same version numbers. We'd call it the kilo.1 release and it would
translate into different point release version numbers for each project.
That could even be done on top of plan D by a group of people caring
enough to create a wiki page to reference the corresponding version numbers.

> FYI, after a CVE, I have uploaded cinder with this version number:
> 2015.1.0+2015.06.06.git24.493b6c7f12-1
> 
> IMO, it looks ugly, and not comprehensive to Debian users. If I really
> have to go this way, I will, but I would have  not to.

Like Alan said, with plan D this actually looks a lot better. You'd be
able to package/distribute 2015.1.25 instead of
2015.1.0+2015.06.06.git24.493b6c7f12-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.
> 
> Though there's now zero guidance at what should be the speed of
> releasing server packages to our users.

I really think it should be a distribution decision. You could release
all commits, release every 2 months, release after each CVE, release
as-needed when a bug in Debian BTS is fixed. I don't see what "guidance"
upstream should give, apart from enabling all models. Currently we make
most models more difficult than they should be, to promote an arbitrary
time-based model. With plan D, we enable all models.

>> 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 ?
> 
> That's not a little thing that you're pointing at: having reference
> points is very important. But yeah, it may be the "only" thing... Like
> we will "only" loose track of what is fixed in which version. :(

As pointed elsewhere, plan D assumes we move to generating release notes
for each commit. So you won't lose track of what is fixed in each
version. If anything, that will give you proper release notes for
CVE-fix commits, something you didn't have before, since we wouldn't cut
a proper point release after a CVE fix but on a pre-determined
time-based schedule.

Overall, I think even your process stands to benefit from the proposed
evolution.

-- 
Thierry Carrez (ttx)