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/2014 11:09 AM, Siddhesh Poyarekar wrote:
> 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
> too.

I had not considered that.

If true then it calls for more horse whipping.

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

We already have something like this but not fully formalized, the
list of blocker issues is the list of things we need to fix.

Perhaps Allan's comments are more on-point here, particularly coming
up with a strict definition of blocker would help.

- ABI defects that would cause an application compiled with
  a previous version of glibc to fail to run with the new version.
- API defects that would cause an application to fail to compile
  with the new version of glibc.

What else?


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