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 jos...@codesourcery.com -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org