Re: Upstreaming the glibc Hurd port

[Joseph Myers <joseph@codesourcery.com>]

On Thu, 18 Jan 2018, Samuel Thibault wrote:

> Joseph Myers, on jeu. 18 janv. 2018 15:34:56 +0000, wrote:
> > On Thu, 18 Jan 2018, Samuel Thibault wrote:
> > > Coding standards can be worked on by anybody, this is really something
> > > that bug-hurd people can unload us from.
> > 
> > Which is also something that having a branch with the patches is helpful 
> > for -
> 
> Well, we already have that on
> 
> git clone git.savannah.gnu.org:/srv/git/hurd/glibc.git/
> 
> with almost a hundred branches to be looked after...

A hundred branches with many different purposes is not something at all 
convenient for glibc people to look over!

> Not all of them are necessary for managing to build glibc. Some of them
> are just hacking, others are perhaps almost ready to commit, just
> missing changelogs & formatting. That's the triaging thing that takes
> time, and having to do all the work including changelogs & formatting
> makes it get lower in my global TODOlist.

I'm still arguing on bug-standards for removing the requirement for 
ChangeLog format (given a public distributed version control system), but 
that wouldn't remove the requirement for proper explanations of patches, 
just mean that explanations intended to be read together with the patches 
themselves would suffice, without needing to duplicate the low-level 
details of how the patches change each affected named entity.

> > (A branch close to current master also provides a basis for anyone working 
> > on build-many-glibcs.py support for Hurd, if you don't already have such 
> > support among your glibc patches.)
> 
> That's why I suggested just committing the required patches to a branch
> that we rebase regularly, so there's a master that does build.

Yes, that's what I'd like to see.  From the perspective of people wanting 
to do global changes to glibc I think the priorities would be (a) building 
cleanly for Hurd; (b) building for Hurd with the intended ABI exported 
from each library at each symbol version; (c) having ABI test baselines to 
verify the ABI stays as expected; (d) having all the rest of the 
compilation parts of the testsuite passing.  Even given just (a) I might 
look at setting up build-many-glibcs.py support.

-- 
Joseph S. Myers
joseph@codesourcery.com