[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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

Reply to: