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]

Release branch maintenance - Was: glibc 2.19 status?


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



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