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 _______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
