[Releasing] rethinking the branching scheme / sha1 proposal
oswald.buddenhagen at digia.com
Wed Feb 19 16:41:08 CET 2014
On Wed, Feb 19, 2014 at 03:13:01PM +0100, Simon Hausmann wrote:
> On Wednesday 19. February 2014 14.34.51 Frederik Gladhorn wrote:
> > This is independent of Ossi's proposal and tries to solve a different
> > problem.
> > One of the pain points in this release was the "which sha1 makes it in".
> > I'd like to propose defining this part as it hopefully solves quite some of
> > the issues we had.
> > So far the procedure is roughly: "whenever whichever merge passes CI around
> > the cut-off time is in".
> > I would like to propose instead that we define a certain time, let's say a
> > week, where maintainers pick which sha1 in this time frame should be the one
> > used for branching.
> > This means we get a defined sha1 that goes from
> > dev->stable and stable->release
> > and no longer chase a moving target (some tip of the branch).
> > To not overly complicate things for most modules where little changes happen
> > the release team makes a decision.
> > In case of a change in the branching system this is still valid in that it
> > would define the branching point.
> I fully support that and I think we should do this in any case. Module
> maintainers - where present - "deliver" a base sha1 that forms the
> stabilization branch for the next minor release. Whether that delivery happens
> within a week or until a certain point in time and what happens afterwards we
> need to discuss of course :)
> One immediate advantage of this proposal is that we can keep "dev" always
no, not really. the idea behind locking down the source branch is
raising awareness, not some technical limitation. picking a random sha1
from a few days ago would only make the problem worse: a contributor
would have no guarantee that a change that integrated before the
official deadline actually made it into the downmerge, and for qtbase
and other busy repos it would be completely impossible to coordinate
things to a degree which avoids that problem.
the immediate effect of that would be lots of cherry-picks, quite the
opposite of what the temporary lockdown tries to achieve.
so in summary, this seems to be counterproductive.
More information about the Releasing