[Releasing] rethinking the branching scheme / sha1 proposal

[Oswald Buddenhagen]

On Wed, Feb 19, 2014 at 08:04:28AM -0800, Thiago Macieira wrote:
> Em qua 19 fev 2014, às 16:47:55, Simon Hausmann escreveu:
> > 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?
> 
> I propose we don't pick it at random. Instead, I propose we pick it up at one 
> very specific CI pass during the weekend of the feature freeze.
> 
> If we're very strict, it would be the SHA-1 of the branch at midnight UTC, 
> whether changes have passed or not. That forces people to get their changes 
> early and not submit major new features in the week of feature freeze. That's 
> a positive sign.
> 
that doesn't solve the problem to the maximal possible degree. you'd be
surprised how effective some people are at missing any kind of
announcement (and then still complaining. i kid you not).

so i really do not want to resign from the temporary lockdown (the
Submission Masters group can still stage to dev, so this isn't a total
lockdown, and blocks only accidental submission to the wrong branch).

the lockdown needs to happen before the merge starts (to let pending
integrations finish).

so combining the two proposals, we arrive at this sequence:
- lockdown precisely at the specified time. this happens in all repos at
  the same time (doing it per-repo would be prohibitively expensive).
- when the integrations finish (successfully or not), we fix the sha1s
  from the branch tips.
- afterwards, the temporary lock stays on, but Submission Masters can
  stage changes which are confirmed to be in the right branch. this does
  not change the sha1s that will be downmerged.
- about two days later the lock is lifted, assuming that even the most
  tenacious contributor noticed the branching by now (or doesn't care in
  the first place).

note that, as frederik noted, this does in no way address the problems
with the downmerge itself. it is 100% orthogonal (subjects being the
source resp. the target branch).