Open Stack

Clark Boylan wrote:
> On Mon, May 5, 2014 at 5:14 PM, John Dickinson <me at not.mn> wrote:
>> tl;dr: (1) the current tag names used don't work and we need
>> something else. (2) Swift (at least) needs to burn a
>> release number with a new tag
>>
>> The current process of release is:
>>
>> 1) branch milestone-proposed (hereafter, m-p) from master
>> 2) tag m-p with an RC tag (eg 1.13.1.rc1)
>>     * note that since there are no commits on m-p,
>>       this tag is an ancestor of master (effectively on master itself)
>> 3) continue development on master
>> 3.1) backport any changes necessary to m-p
>> 4) after QA, tag m-p with the final version
>> 5) merge m-p into master, thus making the final version tag
>>    an ancestor of master[0]

Small sidenote: this is how the OpenStack synchronized release works.
For intermediary Swift releases, we currently don't do RC tags. We just
cut the m-p branch, let that branch cool off for a few days, and tag it
with final version number when it's deemed ready.

>> This process has 2 flaws:
>>
>> First (and easiest to fix), the rc tag name sorts after the final
>> release name (`dpkg --compare-versions 1.13.1.rc1.25 lt 1.13.1`
>> fails). The practical result is that if someone grabbed a version of
>> the repo after m-p was created but before the merge and then packaged
>> and deployed it, their currently-installed version actually sorts
>> newer than the current version on master[1]. The short-term fix is to
>> burn a version number to get a newer version on master. The long-term
>> fix is to use a different template for creating the RC tags on m-p.
>> For example, `dpkg --compare-versions 1.13.1~rc1.25 lt 1.13.1` works.
>>
> Going to defer to mordred on this, but isn't this a known problem with
> known fixes?

The issue here is that Debian (dpkg) sorts in a different manner than
Python (pip). We used to use Debian-sortable tags but under mordred's
pressure we switched to Python-sortable ones. I don't really mind either
way, but IMHO Python-sortable makes more sense than Debian-sortable
(that "~rc1" only works for Debian packages).

>> Second, the process creates a time window where the version number on
>> master is incorrect. There are a few ways I'd propose to fix this. One
>> way is to stop using post-release versioning. Set the version number
>> in a string in the code when development starts so that the first
>> commit after a release (or creation of m-p) is the version number for
>> the next release. I'm not a particular fan of this, but it is the way
>> we used to do things and it does work.

FWIW that is how we work for all the other projects. We bump to the next
version when we open the next cycle, and cut the m-p branch from the
previous commit. So this would be my preferred way of fixing this.

>> Another option would be to not tag a release until the m-p branch
>> actually is merged to master. This would eliminate any windows of
>> wrong versions and keep master always deployable (all tags, except
>> security backports, would be on master). Another option would be to do
>> away with the m-p branch altogether and only create it if there is a
>> patch needed after the RC period starts.
>>
> I don't have all the answers, but I am pretty sure that the m-p
> branches are just a source of pain and don't really help us in our
> release process. Hoping to talk to ttx about this a bit more at the
> summit but the existence of the m-p branch introduces some weird
> interactions in the test infrastructure allowing for periods of time
> where we don't correctly test everything, then we release, cut the
> stable branch, start testing properly and hope that nothing broke
> during that time period. So I am a fan of removing these branches.
> 
> For not swift I think that means we cut the stable/foo branch instead
> of an m-p branch. For swift maybe we cut a stable/releaseversion
> branch or forgo it completely as you suggest. But going straight to
> stable makes a clear delineation between this is our release and any
> associated fixes backported from master and what master is. It will
> also open up master to development sooner in the dev cycle which may
> help things move along more quickly.

We'll have a session to discuss that at the summit:
http://sched.co/RKqBl4

There are a few reasons why we use a specific branch rather than
stable/foo in the pre-release period.

The first reason is purely due to the name: we'd call "stable" something
that is still not released, so not "stable".

The second reason is that a lot of different policies apply to
milestone-proposed and stable/foo. Acceptance of patches is governed by
different rules. Teams that approve patches to those branches differ. If
we were to reuse the same branch name, humans would have to apply
different rules (and set different parameters) to that branch based on
whether we are pre-release or post-release. It just seems easier to
teach the tools to use one or the other based on their existence.

The third reason was that it allowed us to reuse the same branch names
and processes for development milestones (like "icehouse-2"). We can get
rid of those (and replace them with some "floating" tag that would point
to the likely commit in master), but it was a nice way of exercising
some of the release machinery throughout the cycle.

That said, I fear this is an orthogonal discussion, as I'm not totally
sure using stable/foo would, in itself, solve the issue that John
raised. For that, pushing the next version as a commit to the code (like
we do for all the other integrated projects) would be my preferred option.

-- 
Thierry Carrez (ttx)