This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Rolling master branch
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, Jeff Law <law at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 29 Sep 2014 13:23:50 -0400
- Subject: Re: Rolling master branch
- Authentication-results: sourceware.org; auth=none
- References: <20140929082252 dot GB2217 at spoyarek dot pnq dot redhat dot com> <54295333 dot 8040205 at redhat dot com> <CAAHN_R3ki6T08PVXOOUr3TEDAusBKiCf_O_Si1ZEp+HjvBsWug at mail dot gmail dot com>
On 09/29/2014 11:09 AM, Siddhesh Poyarekar wrote:
> On 29 September 2014 18:10, Jeff Law <law@redhat.com> 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.
Blocker:
- 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?
Cheers,
Carlos.