On Mon, Feb 24, 2014 at 02:22:49PM -0800, Thiago Macieira wrote: > Em seg 24 fev 2014, às 21:11:47, Knoll Lars escreveu: > > * We have one dev branch for all new development > > I.e., nothing changes. I propose this branch stay named "dev", for clarity of > purpose, not "master". > i don't think the clarity buys us much. like the rest of the branch naming stuff, it is really a minor detail for the average contributor. otoh, the deviation from the default leads to *every* project so far having to rename their master branch upon promotion to being an official part of qt. so i would actually vote for switching back to the master name (though keep merging dev for a while, so we don't have to re-target hundreds of changes again). this isn't a very strong preference, though.
> > * After creating the branch for a new minor release we do a forward merge > > from the previous branch before creating the alpha. The advantage here is > > that the forward merge is something we know how to handle (it’s done on a > > rather regular basis), and we then know we have all changes from the > > previous patch level release in the new release. > > My objection here is that the merging is not the problem. We still need to > get > changes through the CI and *that* is currently the problem. > it remains a problem for the release (though still smaller than now). we solve the problem for the development (no need to lock down the "new" branch for days). > I still feel we're solving the wrong problem. Or, we can say we're > working around the problem because really solving it is not within our > means right now. > even if we could optimize CI to the point where a forward-merge would reliably go through in half an hour (which i think is a realistic target when we actually concentrate on that, but we likely won't get there within the next months), we still have a) that half-hour lockdown which is weird in itself and b) the administrative overhead of implementing the lockdown (fiddling with gerrit permissions). so even in the optimal case, branching would be *still* cleaner than downmerging. > > * To create the actual patch level releases (5.x.y), I would propose that > > we create a short-lived branch from 5.x. That branch gets tested, but no > > patches get directly committed to it (as opposed to the release branch we > > have today). Instead I would propose that the release team creates a list > > of P0 bugs that still have to be fixed before we can fix 5.x.y. Fixes for > > these bugs get pushed to 5.x and cherry-picked to 5.x.y by the release > > team. Like that we can control in a better way what goes into the final > > release and no developer has to deal with a release branch. It should also > > reduce the risk that other changes go in that again break qt5.git CI or > > have other negative side effects. > probably not unexpectedly, i don't like that. thiago insists on the forward merge, and all other things being equal, the number of commits wouldn't go down, so we would arrive at a significant number of duplicated commits. the crucial point is policy enforcement, i.e., the release team being much stricter about what gets staged. but we have a problem here: the fact that we repeatedly were about to release alpha quality software (and sometimes did) makes it pretty much unavoidable that numerous changes are being made until the last moment. when that is fixed, the number of commits goes down to a point where it doesn't matter whether we are cherry picking (only few duplicate commits) or continue to push directly to the release branch (few people are concerned with it anyway). all things being equal, i'd still prefer fewer cherry-picks, i.e., the latter. note that there is an alternative to the forward merge that thiago at least didn't reject outright last time i proposed it: create a shadow tag on the stable branch which marks the last commit that went into a particular release (but obviously also already contains commits that were not released at that time). that would make the cherry-pick solution more palatable. > * The Git repository's HEAD continues to point to the current "stable" > release. The fact that we're changing the names of the branches does not > invalidate the reason why we chose HEAD to point to "stable" back in 2011: > people should be presented with the most currently relevant yet stable > release > available when they clone the repository. And given 2½ years of experience on > this, I can confidently say that this is also the this is the branch that > most > of our developers spend time on. > i would argue that this is one of the branch-related things that really don't matter for the vast majority of contributors. a reasonable developer makes a conscious decision about his target branch rather than cloning and just hacking away. > That means when we create 5.x from dev, someone needs to go and update > all the Gerrit and Gitorious repositories' HEAD. > only if you volunteer to either do that yourself, or write (and maintain) a http client script that reliably does it for us. > > (In addition gerrit 2.8 will then finally solve this by allowing > > to retarget a change) > > Any ETA on when we can expect 2.8? > ismo would have to comment on that. given the bug sean pointed out, we may need to forward-port again before we deploy (or we find the fix and cherry-pick it into 2.7). > Though, to be honest, as long as 5.x is not closed, we can and should always > just push bugfixes to 5.x, even if 5.y (y > x) is already open. > yes, with increasingly stricter requirements, obviously. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
