[Releasing] rethinking the branching scheme / sha1 proposal

Simon Hausmann simon.hausmann at digia.com
Wed Feb 19 15:13:01 CET 2014

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. 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.


More information about the Releasing mailing list