Re: Upstreaming the glibc Hurd port

[Joseph Myers]

Please note (as a reminder from past discussions) that the Hurd libpthread 
will need to be included as part of glibc, much like NPTL is a 
fully-integrated part of glibc - not a separate package (support for 
add-ons has been removed from glibc).  (I'd also suggest that it *not* use 
a top-level directory called simply "libpthread" or similar without 
mention of Hurd, as that would be too confusing to people looking at the 
source tree for pthreads for other platforms.)

Also as per previous discussions: Hurd port maintainers can put in changes 
to Hurd-specific files at any time (regardless of release freeze state) 
until the port is actually working.  All the usual coding standards of 
course apply, and changes to files that might affect non-Hurd may need 
review and not be appropriate at some times, depending on freeze state and 
the risks associated with such patches.

In my view, build-many-glibcs.py support for Hurd would be appropriate 
even before the Hurd port builds (and certainly before it cleanly passes 
the compilation tests).  That support will definitely need patch review.

Before Hurd support is fully integrated in glibc, I'd encourage having a 
branch *in the glibc repository* that contains such support, so we can 
more readily see what the changes yet to be merged are (and possibly 
comment on issues that will need addressing when integrating them in 
glibc).

-- 
Joseph S. Myers
joseph@codesourcery.com