release branch?

[David Faure]

Hi,

I have a question about the release process.

It seems to me that we currently have to completely freeze the branch that is 
about to be released, for the few days between making the first set of 
tarballs and the day of the official release, so that we can update tarballs 
with any critical fix meanwhile ("respin") without grabbing other unrelated 
changes that people might have been committing meanwhile.
Right?

It seems to me that this kind of kills productivity during that week, and 
creates the risk that someone forgot that this was the week where they're not 
supposed to push commits, etc.

Shouldn't we use a "release" branch to fix this?
E.g. when releasing 4.13.1, first have the release scripts make a 
KDE/4.13.1-release branch in all affected repos, then make tarballs from that, 
then give a week for packaging, and cherry-pick any urgent bugfixes into that 
branch, to make new tarballs from there.
This prevents accidental commits during that time -- and in fact we could even 
go further and use ACLs so only the "release team" can push to the release 
branch.

I suppose this has been discussed before - in that case I apologize for 
missing that or forgetting it :)

But if there's an agreement I volunteer to adjust the release-tools scripts 
accordingly.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5