This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Release branch maintenance - Was: glibc 2.19 status?
- From: Allan McRae <allan at archlinux dot org>
- To: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: 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>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Sat, 01 Feb 2014 12:16:06 +1000
- Subject: Release branch maintenance - Was: glibc 2.19 status?
- Authentication-results: sourceware.org; auth=none
- References: <52E649BF dot 5020400 at archlinux dot org> <20140128205657 dot 16DBA74438 at topped-with-meat dot com> <52E9DEB7 dot 4000709 at redhat dot com> <52E9E84F dot 50907 at redhat dot com> <52EA682D dot 90900 at archlinux dot org> <ormwid428y dot fsf at livre dot home> <Pine dot LNX dot 4 dot 64 dot 1401302131080 dot 12540 at digraph dot polyomino dot org dot uk> <20140131032418 dot GK2149 at spoyarek dot pnq dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1401311709310 dot 26476 at digraph dot polyomino dot org dot uk> <CAAHN_R2r6jiHWwj2HGDS-sruGewKEMmeQkAS9PXqZtOS95gKAw at mail dot gmail dot com>
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.
>> I'd imagine that having such release tarballs for point
>> releases would make it more likely distributors would use the release
>> branches (via those release tarballs)....
>
> ... However, even with that change, I don't see us using point
> releases extensively for Fedora given the relatively short release
> cycle and life. It probably won't happen even for RHEL for other
> reasons, but that's not completely out of the question. However, even
> if we do decide to use release branches for RHEL, it would mean that
> we maintain only one out of every 5-7 release branches and other
> branches may again go unmaintained if nobody else is using them.
>
> In any case, I am not arguing against the utility of maintaining
> release branches; I just wanted to know if anyone is actually using
> them since if they are not in extensive use then it is quite obvious
> why release branches are not actively maintained. Further, if nobody
> has any plans to use point releases in future then it is futile to
> even expect their active maintenance. If there is in fact an interest
> then we probably need do define a more open workflow for them so that
> those distribution maintainers can decide on when these point releases
> go out.
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.
Saying that, I am not in the best position to comment on maintenance
releases given glibc-2.18.x will be dead to Arch Linux the day
glibc-2.19 is released...
Allan