Rolling master branch

[Jeff Law]

On 09/29/14 02: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.
What we've found in GCC-land is it gets really hard to focus engineers 
efforts on fixing the important bugs to get a release out the door. 
Most folks would rather continue their work on features, optimizations, 
etc rather than fix bugs.  The nerve :-)

The one really effective tool the release manager has is refusing to cut 
the branch until the trunk hits a set of metrics around stability 
(usually expressed in terms of P1-P3 regressions in bugzilla).

It's far from perfect, but does give the release manager a reasonable 
lever to get developers to focus on release issues rather than the next 
round of development.

jeff