[Releasing] rethinking the branching scheme

[Frederik Gladhorn]

Onsdag 19. februar 2014 12.56.33 skrev 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.

It's not working.

Greetings,
Frederik


> 
> 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
> 
> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing

-- 
Best regards,
Frederik Gladhorn
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com