[Releasing] rethinking the branching scheme / sha1 proposal

[Simon Hausmann]

On Wednesday 19. February 2014 16.41.08 Oswald Buddenhagen wrote:
> 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
> > open.
> 
> 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.

If the sha1 is randomly picked, then I agree it is counter-productive and 
well, doesn't change anything. Are you worried that it's going to be difficult 
to choose a sha1 for qtbase because it seems the biggest inflow of changes from 
many directions?


Simon