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 29 September 2014 18:10, Jeff Law <> wrote:
> 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 problem seems a bit different with glibc.  Master branch freezes
seem to shift focus from glibc to other projects since most
contributors to glibc usually work on other parts of the toolchain

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

That sounds interesting.  We don't really tie in the release process
to bug reports at all, at least not until there is a blocker that we
want to fix.  Carlos and I have previously tried (and not always
managed to follow through on) focusing our efforts on bugs roughly a
month before master freeze, but there has never been a policy around
it.  It would surely be nice to have something on these lines
regardless of whether we decide to stick to the master freeze model or
move on to some other process.


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