release branch?

[Albert Astals Cid]

El Dissabte, 1 de març de 2014, a les 11:05:07, David Faure va escriure:
> 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?

We simply get the other changes that may have been commited, since well, why 
would you not want other bugfixes? :-)

I understand this may be a bit different for the current frameworks scenario 
where you're still doing SIC/BIC changes but for the rest of the branches, 
well, if we have to retag and due to that we get a few more bugfixes, i think 
that's a win :-)

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

Also note that for Betas of the SC we've killed that week (haven't checked 
what you guys are doing in KF), packages are released as soon as they've been 
tarballed and compiled by one person (which nowadays is me).

For the x.y.z releases we mostly have a week to give time to distros to 
compile their packages, since with both me compiling them and jenkins doing 
it, it's hard that they won't compile. Of course it may happen that some huge 
regression is found in that week but from what i remember lately that hasn't 
happened much.

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

I see were you're going and it seems more "professional and rational" to do 
what you suggest, but as I said i don't think getting a few more bugfixes is a 
bad thing if we have to respin a package, so i think it's better that you 
invest your time in something else other than doing bash coding :-)

Cheers,
  Albert