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" <[email protected]> > > 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 > >[email protected] > >http://lists.qt-project.org/mailman/listinfo/releasing > > _______________________________________________ > Releasing mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/releasing -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com _______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
