This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Release branch maintenance - Was: glibc 2.19 status?
- From: Allan McRae <allan at archlinux dot org>
- To: Mike Frysinger <vapier at gentoo dot org>, libc-alpha at sourceware dot org
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>
- Date: Tue, 04 Feb 2014 21:08:55 +1000
- Subject: Re: Release branch maintenance - Was: glibc 2.19 status?
- Authentication-results: sourceware.org; auth=none
- References: <52E649BF dot 5020400 at archlinux dot org> <CAAHN_R2r6jiHWwj2HGDS-sruGewKEMmeQkAS9PXqZtOS95gKAw at mail dot gmail dot com> <52EC58E6 dot 6060702 at archlinux dot org> <3673077 dot Nn8N4XpUPj at vapier>
On 04/02/14 18:38, Mike Frysinger wrote:
> On Saturday, February 01, 2014 12:16:06 Allan McRae wrote:
>> On 01/02/14 11:59, Siddhesh Poyarekar wrote:
>>> On 31 January 2014 22:40, Joseph S. Myers <joseph@codesourcery.com> wrote:
>>>> If a distribution works from a release tarball rather than directly from
>>>> the git tag,
>>>
>>> We have started using release tarballs for Fedora now, with Fedora 20
>>> being the first one to have it...
>>
>> Arch Linux moved to using release tarballs instead of pulling from the
>> release branch around the time release tarballs started being made again.
>
> if there were released tarballs for the branches, i'd use them in Gentoo. but
> until then, i only cherry pick things from the branch as requested.
>
>> I'd like to have it set up so that the only thing the release branch
>> maintainer needs to do is decide when to cut a new release. To achieve
>> that, I'd like the distro maintainers to take any patch they pull from
>> master into their package and commit it onto the relevant release
>> branch. That way, the release branch reflects actual usage of that
>> release, and further releases from it start to make sense. If no
>> patches land, we know that branch is not being used (or is amazingly bug
>> free!) and no more releases need done.
>
> i don't think that's a good idea. there are some things each distro does that
> is unique to it and doesn't really make sense putting onto others. there are
> also some patches we carry that conflict, or are admitted hacks in the face of
> not having a better answer, or that we'd disagree on whether it should even be
> done in the first place.
>
> i think the policy we have currently (master first, and then only cherry picks
> / backports are allowed in the branch) is the only real sane policy.
I suppose I was not very clear, but it was implied that only patches
that have landed on master and are bug fixes are eligible for pulling to
the release branch. My point was that whether distros consider it worth
backporting for their package is a good indicator of the need to
cherry-pick to the release branch.
Allan