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: What is glibc-ports?


On Wed, 25 Apr 2012, Carlos O'Donell wrote:

> On Tue, Apr 24, 2012 at 7:32 PM, Roland McGrath <roland@hack.frob.com> wrote:
> > I think the flattening is adequately justified now. ?If any of this is
> > done, I think that flattening should be done first in two stages. ?First,
> > remove unused sysdeps/unix/bsd/ files that are directly overridden by
> > sysdeps/unix/bsd/bsd4.4/ files. ?Second, move the bsd4.4/ files up to bsd/.
> >
> > Only after that would I want to consider removing more code, and I'd want
> > to talk to the kfreebsd folks first.
> 
> I've was poked by Bruno Haible and I started a discussion with Robert
> Millan to encourage the kfreebsd patches to be submitted again. I hope
> that we see something from the msoon.

I'd also like to see the various out-of-tree Hurd patches coming in so 
glibc is closer to actually working on Hurd out of the box.

Given that glibc is reportedly far from working out of the box on Hurd, 
with 86 separate topic branches being involved 
<http://sourceware.org/ml/libc-alpha/2012-02/msg00556.html>, there can't 
really be issues of "testing" the patches submitted on Hurd (as opposed to 
making sure they don't break things for GNU/Linux) - that's only 
meaningful when glibc plus one or two patches will actually work on Hurd.  
Obviously patches should still be submitted as individual logical changes, 
but review can't be for much more than whether they look right and appear 
to be an improvement - until we're much closer to working out of the box 
it should be a matter of human time to separate out, post and review 
patches, rather than of machine time to do slow test runs under Hurd 
itself.  I think it would be better to get hundreds of "approximately 
right, and certainly better than the previous state" patches in bit by 
bit, with the expectation that bits of them may need subsequent fixups, 
rather than try to get a complete and perfect patch series against current 
glibc ready up front and then submit that whole series at once.

-- 
Joseph S. Myers
joseph@codesourcery.com

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