This is the mail archive of the
mailing list for the glibc project.
Re: Rolling master branch
- From: Jeff Law <law at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 29 Sep 2014 06:40:19 -0600
- Subject: Re: Rolling master branch
- Authentication-results: sourceware.org; auth=none
- References: <20140929082252 dot GB2217 at spoyarek dot pnq dot redhat dot com>
On 09/29/14 02:22, Siddhesh Poyarekar 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 :-)
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.
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.