Re: Rolling master branch

[Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>]

On 29 September 2014 17:41, Allan McRae <allan@archlinux.org> wrote:
> 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.

In hindsight, the Wundef changes didn't turn out to be the kind that
everyone would be comfortable with and that ought to have been reason
enough to not block on them.  The reason to block on them was a good
one too (aren't they always?), in that Roland and I didn't want them
dragging along forever.  Looking at the current status of the Wundef
changes, one could argue that it was a good thing we didn't wait for
them since they're not done yet.  But one could argue the other side
too, that they've now fallen down the priority stack since they don't
really block anyone.

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

We need some kind of continuous integration testing, probably using
the gcc server farm.

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

Sure, but there will always be things that absolutely *must* make it
into the release (or at least that's how we'll feel then) and hence
justify pushing the release back, especially since we're not really
time bound.

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

Focus on the release branch is a valid point, but TBH I don't see a
lot of effort going into master once it is frozen.  My theory is that
this is because most contributors here do glibc work as an additional
thing and hence, glibc master freezing gives them a chance to focus
their efforts on other projects like gcc, binutils, etc.  So we've
already lost focus of resources due to the freeze.

Siddhesh
-- 
http://siddhesh.in