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]

Re: Status of merging distribution patches


On 07/04/2013 06:26 PM, Joseph S. Myers wrote:
> One area where we haven't seen as much progress as I'd like is merging the 
> accumulated piles of distribution patches back into glibc (except in those 
> cases where a patch is for some inherently distribution-specific purpose, 
> e.g. compatibility with ABI mistakes in past distribution binaries).
> 
> I've again updated the list of changes to consider for merging from 
> EGLIBC, linked from 
> <http://sourceware.org/glibc/wiki/Development_Todo/Master#Distribution_merging>.  
> That wiki page section lists what I think are the main distribution trees 
> from which patches need merging - note that I've included gnulib and the 
> separate GNU Hurd glibc trees in what I consider to be distributions.  Do 
> maintainers of those various trees have any similar todo lists of the 
> individual changes to consider for glibc and plans regarding how to merge 
> those changes?
> 
> (Much the same also applies to distribution bug trackers - it would be 
> useful there as well for people to go through bugs and file them in glibc 
> Bugzilla if they represent valid well-defined bugs that are still present 
> in current unmodified glibc sources and aren't currently in glibc 
> Bugzilla.)
 
For Fedora and RHEL we are working hard to make sure everything goes
upstream first. I'd say we are down to ~30 patches in Fedora 19 against
glibc 2.17. I'm hoping we close that gap to something even smaller for
Fedora 20 (glibc 2.18 based). That should help ensure other rpm-based 
distros also have a small set of patches.

The patches to merge are all documented in Fedora's glibc.spec file.
Any patches in the 0-0999 range are needing merging and I'll make sure
we set aside time to move those upstream.

One thing I think might help is to hash out the upstream distro branch
process and make it clear how we should be fixing things in stable
branches and then backporting. That way we keep stable distro branches
close to the upstream stable release branch.

As we resurrect the Fedora branches I'll document the process in more
detail and try to use it as a prototype for how other distros can
participate.

Cheers,
Carlos.


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