[Releasing] rethinking the branching scheme / sha1 proposal

Frederik Gladhorn frederik.gladhorn at digia.com
Wed Feb 19 16:44:09 CET 2014

Onsdag 19. februar 2014 07.39.11 skrev Thiago Macieira:
> 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.
> Agreed.
> 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.

Here I would like to be optimistic and hope that we get to a state where 
releases only take a short time in packaging, then get some nice release test 
automation thrown at them and only then a manual checkup that they are OK.

But of course this means more people need to maybe help the release team and 
we also need to manage to clean up the qtsdk repository for example, so that 
the release process becomes easier.

Another thing to be done is to cut down on time we spend on creating packages.
We recently improved the time spent on creating the various archives, but of 
course that doesn't improve the big picture that much.

Best regards,
Frederik Gladhorn
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com

More information about the Releasing mailing list