[Releasing] rethinking the branching scheme

[Turunen Tuukka]

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
working.

Yours,

		Tuukka

On 19/02/14 13:47, "Oswald Buddenhagen" <oswald.buddenhagen at digia.com>
wrote:

>moin,
>
>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
>  dependencies.
>  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
>CI delay.
>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
>release).
>
>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
>    downmerge)
>  - 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.
>
>regards
>_______________________________________________
>Releasing mailing list
>Releasing at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/releasing