[Releasing] rethinking the branching scheme

[Oswald Buddenhagen]

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