This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Proposal to revitalize release branches: Make them cheap, and make them work.
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: 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: Fri, 3 Oct 2014 13:24:30 +0530
- Subject: Re: Proposal to revitalize release branches: Make them cheap, and make them work.
- Authentication-results: sourceware.org; auth=none
- References: <542DBB6F dot 6040109 at redhat dot com>
On 3 October 2014 02:24, Carlos O'Donell <carlos@redhat.com> wrote:
> * 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.
This is not strictly necessary. Any reverts if necessary could be
consensus based with the release manager/Roland making the final call
if there is a deadlock. That is, it could just be like master except
that the consensus would be for a revert instead of a commit.
> * Post all release branch commits to new libc-stable mailing list.
This should be automated using commit hooks. On a marginally related
topic, can we expose the commit hook scripts somehow so that more
maintainers can have a look at it and fix them up? They could use
some improvements with things like ignoring private namespace branches
when doing IRC notifications, better commit announces in the bugzilla,
etc.
> If nobody disagrees I can adjust the Release wiki to indicate the changes.
+1.
Siddhesh
--
http://siddhesh.in