Re: Rolling master branch

[Allan McRae <allan at archlinux dot org>]

On 29/09/14 18:22, Siddhesh Poyarekar wrote:
> Hi,
> 
> Our current release model requires us to freeze the master branch for
> releases, until the release is cut and branched out.  This results in
> a halt in development for usually about a month or so and any new
> patches that don't qualify for the current release have to wait till
> whenever the release happens.
> 
> Instead, we could just create a release branch to indicate the freeze,
> which means that the release branch can only have pre-decided
> exceptions on top of it and nothing else, until we're ready to
> actually cut the release, the point which is tagged as the release.
> This would work more or less the same as the current workflow, except
> that it frees up master for continuous development and the release
> manager and committers may have to push to two branches instead of one
> until the release is tagged.
> 
> Thoughts?
> 
> Siddhesh
> 

Here are lessons I learned from the last two releases, which may not
answer your question directly, but looks at why the freeze is so long.
>From memory, 2.19 took a week longer than planned and 2.20 took five
weeks longer.  For 2.20, we were always going to be at least two weeks
late given the timing of the cauldron and various holidays, so three
weeks were effectively added.  This is on top of a four week release freeze.

Here is what I learned:

1) We need to be very stringent in defining what is a release blocker.
For 2.20, the -Wundef fixes should never have been added as they were
too far away and this was the major delay.  Goals like that should
appear very early in the release cycle or delayed to the next.

2) If during freeze there is controversy regarding something added
during development, be more readily prepared to revert it if it is not
very important.  This happened with some TLS patches in the glibc-2.19
release phase and was the primary delay.

3) Collecting test results takes time.  I'm not sure how this can be
improved given the number of machines we test means that some
maintainers are bound to be away.  I also note that only one
architecture tested gcc-4.4, with the rest mostly tested on gcc-4.8 and
gcc-4.9.  So our test coverage is not stunning.


So I see two points.  How can we speed up the release phase and is a
separate release branch needed?

Both the main delays in the 2.19 and 2.20 release were caused by my
inexperience at pushing a release.  I had not encountered issue #1 and
#2 during a release before, and so it took time to make a decision.
This will always be a problem with the two release cycle we are doing
with release managers and if you select someone who is not a large
contributor and thus needs more informed for their decision making
(although, I think it is far better to have large contributors doing
coding and not release management).  That can be improved by people
looking at the wiki status with blockers early on and speaking out that
things should not block, reversion should happen, etc.

Most of the testing status updates on the wiki happen in the final two
weeks.  And translations are generally done over a two week span.  So I
think the freeze could be substantially shortened if we track blockers
during development phase and be heavy handed in removing them.

If the release phase was two weeks, with a probably week extension,
would a separate branch for release stabilization be needed?

And, if you are still here after that wall of text, my opinion on
branching for release and continuing development on master are
pessimistic. Every experience I have of that situation is that releases
take substantially longer due to focus - or at least resources -
remaining on the master branch. As pointed out above, I think we are
under-tested anyway in terms of gcc/binutils/etc coverage and architectures.

Allan