This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Release branch maintenance - Was: glibc 2.19 status?


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

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]