This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Rolling master branch
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: 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 20:39:05 +0530
- 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>
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.
> 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.
Siddhesh
--
http://siddhesh.in