[Releasing] rethinking the branching scheme
Olli.Hirvonen at digia.com
Wed Feb 19 14:27:45 CET 2014
IMO: QtCS is a bit too late. Planning and discussion can be started even we run 5.3 with the current setup.
Focus is of course to fix things asap and make the Alpha.
> -----Original Message-----
> From: releasing-bounces+olli.hirvonen=digia.com at qt-project.org
> [mailto:releasing-bounces+olli.hirvonen=digia.com at qt-project.org] On
> Behalf Of Turunen Tuukka
> Sent: 19. helmikuuta 2014 14:57
> To: Buddenhagen Oswald; releasing at qt-project.org
> Subject: Re: [Releasing] rethinking the branching scheme
> 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
> > 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
> >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.
> >Releasing mailing list
> >Releasing at qt-project.org
> Releasing mailing list
> Releasing at qt-project.org
More information about the Releasing