[Releasing] rethinking the branching scheme / sha1 proposal

Thiago Macieira thiago.macieira at intel.com
Wed Feb 19 16:39:11 CET 2014

Em qua 19 fev 2014, às 15:13:01, Simon Hausmann escreveu:
> 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 :)

I fully support Frederik's suggestion too. I don't think Ossi's suggestion 
buys us anything more than just confusion: the underlying problems will still 
be there no matter what.

> One immediate advantage of this proposal is that we can keep "dev" always
> open. We still have to lock down "stable" until the sha1 -> stable merge is
> through the CI system for all modules. However in the spirit of incremental
> changes to the project and also in light of the advantages the simple three-
> naming scheme has, I think we should try this first and see how much
> "frustration" remains before we re-design the naming scheme itself.


The one think that Frederik's proposal doesn't address that Ossi's might is 
how to stage 5.2 things while 5.3/5.4 are being branched off from one another. 
However, experience has shown that the number of commits on the stable branch 
taper off very quickly close to the dev feature freeze, enough not to be a 
problem. Yes, there was a rogue commit (sorry about that, I'm guessing it was 
my ICC make-math-strict commit), but I wasn't aware that there would be a 
freeze in the first place and there was no email it was happening.

We're also unable to make further releases due to lack of manpower: right now, 
the release team is skeptical whether it is able to make 5.2.2. Changing the 
branching scheme does not buy us more manpower.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Releasing mailing list