This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Rolling master branch

On 09/29/14 02:22, Siddhesh Poyarekar wrote:

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]