This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc release branch procedures
On Sun, 24 May 2009, Petr Baudis wrote:
> Hi,
>
> I added glibc maintainers of several major Linux distributions to Cc
> list to gather their opinions on what kind of patches should be included
> in the glibc-2.10-branch if they were to use that instead of the current
> practice (the only release and variously large patchball of backported
> fixes). I included Debian, they just switched to eglibc, but its 2.10
> branch is likely to track glibc-2.10 in the future (is it, jsm?).
Yes, if a glibc-2.10 branch starts receiving commits then EGLIBC 2.10 will
follow it (possibly with other backports specific to EGLIBC as well).
There is an important proviso that release-branch changes that require
corresponding release-branch changes to ports are problematic and cannot
be merged until the corresponding ports changes are on a corresponding
ports release branch. There were such problematic changes on the
glibc-2.5 and glibc-2.6 release branches, but in general it's probably
best to avoid backporting such internal interface changes that need all
targets to change, even if they do fix bugs without affecting the external
interface.
As a ports maintainer I am happy to create a 2.10 branch for ports if one
for libc starts being used and merge selected fixes there (generally
following similar procedures to whatever may be followed for libc) - but
if the internal interface change situation arises, the changes obviously
can't go on the release branch for ports until they are first ready for
mainline development.
I would generally favour being liberal as to what bug fixes are accepted
for a release branch (given that they are in mainline first, do not
involve ABI/API changes and do not require other target-specific changes).
--
Joseph S. Myers
joseph@codesourcery.com