[Releasing] rethinking the branching scheme
Tuukka.Turunen at digia.com
Wed Feb 19 13:56:33 CET 2014
This, I think, is a good topic to be discussed in the next QtCS.
For now we anyway need to focus in keeping the existing setup and process
On 19/02/14 13:47, "Oswald Buddenhagen" <oswald.buddenhagen at digia.com>
>you may remember that we arrived at the dev/stable/release scheme after
>a some lengthly discussion a few years back.
>now i'll explain that imo that scheme failed, and that we need to go
>back to a more traditional one. hurray!
>the crucial issue is - surprise surprise - the CI system:
>- a straight downmerge just doesn't work due to the reverse
> this can be temporarily disabled, but that is a hassle. also, even
> when we tried that, things were a huge mess.
>- the workaround is doing a forward merge and then direct-pushing a
> fast-forward downwards.
> for this to work, the target branch needs to be locked down for a day
> or two. that alone is obviously quite a disruption for people not
> involved in the release process.
> another lesson from today's experience is that despite fairly heavy
> restrictions as to who can stage, we *still* got three "rogue" commits
> in qtbase/stable today from people who happened to have the rights,
> but were not involved in the release process this time. locking this
> down even further, tailored to the particular situation each time
> around, would be hassle (and thus error-prone).
>so it basically comes down to non-atomicity, exacerbated by the enormous
>the answer to that is quite obviously using an operation that is
>naturally atomic: branch creation.
>on top of that, we already realized that we need the old/ branch
>namespace to be able to release from older versions (in case of security
>fixes). this is quite a hassle to maintain as well, and the asymmetry
>makes things hard to understand (and virtually impossible to actually
>so i'm proposing that we switch to a master/5.x/5.x.y scheme as we had
>before opengov (and as we still have for qt creator).
>the implications are, afaict:
>- we solve the downmerge problem ... by not having it in the first
> place. only forward merges and branch creations.
> the biggest advantage here is that branching can be done very quickly
> in a uniform process by somebody from the release team, without
> coordinating every step with half a dozen people.
>- CI configs will need to be cloned for each new branch. we need to make
> sure that this is reasonably low-hassle.
>- one of the strong arguments for the current scheme was the purported
> simplicity for the developers.
> i think experience shows that this didn't really work out:
> - the branches still have phases (e.g., "soft freeze" right after a
> - people think in release versions anyway
> - the "missed the deadline and need to cherry-pick" scenario continued
> to exist, and was actually made much worse due to the fuzziness of
> the date (again the CI delays). that's why we now have the staging
> lockdowns on the *source* branches (i.e. dev around the dev =>
> stable downmerge).
> with the traditional scheme:
> - people will need to figure out what "stable" is. no biggie - they
> really do that anyway (in the other direction).
> - pushing to a too high branch will still be prevented by the
> staging lockdown for around two days
> - pushing to a too low branch is no big deal, as we'll just forward
> merge. at some point we'll lock down old branches, too (we
> actually did that in the pre-opengov times)
> - making anything but master the default git branch will be
> unrealistic (we can't script updating gitorious and github). i don't
> think that is a big deal.
>- i can retroactively create/move the branches for previous releases
>- we need a new picture for http://qt-project.org/wiki/Branch-Guidelines
>everybody on irc involved in the current disaster^Wrelease was in favor
>of giving this some serious consideration.
>Releasing mailing list
>Releasing at qt-project.org
More information about the Releasing