This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Proposal to revitalize release branches: Make them cheap, and make them work.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, Adam Conrad <adconrad at 0c3 dot net>, Allan McRae <allan at archlinux dot org>, David Miller <davem at davemloft dot net>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Thu, 02 Oct 2014 16:54:07 -0400
- Subject: Proposal to revitalize release branches: Make them cheap, and make them work.
- Authentication-results: sourceware.org; auth=none
The glibc release branches don't work. We know they don't work, and I'd
like to fix that. The only way I see them working is if we make them
super duper easy to use for all the distributions, and from that bootstrap
some active backports. Thus this proposal is aimed at making it as simple
as possible to checkin a bug fix to a release branch and monitor such
fixes.
Here is what I propose:
* Make all release branches rolling releases.
- release/2.20/master is always a valid release with more and
more bug fixes applied continuously.
- no more point releases will be made from the release branch.
- no more work for the release manager.
- Where all distro branches should rebase from.
* The only per-requisite you need to apply a bug fix to a stable release
branch is that the same bug fix was applied to master.
- no ack from release maintainer required.
- obviously you have to do some testing before committing, that's
just expected.
* The release maintainer retains veto for patches on a release branch.
* Post all release branch commits to new libc-stable mailing list.
- If you commit to a stable branch, you post that commit to the
new libc-stable mailing list.
- Parties interested in maintaining stable branches sign up to
the list, and monitor the list for stable patches to backport
to their own branches.
* Only bug fixes are allowed to be checked in following the above rules.
If you hesitate for even a second that the bug fix might be too risky
then post to libc-alpha to get consensus on the fix.
- No new features may be backported without community consensus.
and an ack from the release maintainer.
This way everyone should be committing fixes to 2.20.
This way the distro maintainers have zero red-tape to backport a bug fix
to a relase branch.
Comments?
If nobody disagrees I can adjust the Release wiki to indicate the changes.
Cheers,
Carlos.