Re: Proposal to revitalize release branches: Make them cheap, and make them work.

[Will Newton <will dot newton at linaro dot org>]

On 2 October 2014 21:54, Carlos O'Donell <carlos@redhat.com> wrote:
> 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.

It's not clear to me how "absence of veto" is going to work versus
"explicit ack". Is the power of veto in this case just the power to
revert?

> * 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.

This sounds like something that could be automated.

>         - 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.



-- 
Will Newton
Toolchain Working Group, Linaro