Re: glibc 2.15

[Roland McGrath <roland at hack dot frob dot com>]

> Yes - the lists don't appear to have been updated since 2.3 in 2004.  
> Regarding the other obsoletion discussions, all the non-TLS cases in the 
> lists could certainly be removed, and there ought to be a solution for 
> keeping lists for ports in sysdeps directories (as-is, the m68k data is 
> still in abilist/ in libc).  

Agreed.  The original intent was geared at not having too much duplication
in the same source tree, hence the goop that merges commonalities together.
But some slightly large text files in a repository and/or source tarball
really don't seem like such a big deal any more.  And IMHO certainly those
concerns are trumped by the proper segregation into add-on directories.

I can't tell any more whether we still intend for the ports repository to
be able to produce individual add-on tarballs instead of just the one big
glibc-ports tarball.  If we don't care about that any more, then having a
single abilist set in ports that does the deduplicating merge of all the
ones for configurations maintained in that repo would make sense.  (More on
that is a subject for libc-ports rather than here.)  But I think I'd really
be fine with abilist files living in sysdeps/ instead now.

The text file bloat aside, one nice feature of the deduplicating merge was
that you could really easily notice the divergence between configurations
by eyeball.  It's good to avoid gratuitous differences going in
inadvertently.  But that's eminently doable just with scriptery to do
comparisons as well.  It doesn't particularly require that the repository
contain merged files.  The most important thing is that people actually
look at both the version-to-version changes and the inter-configuration
divergence and make sure it's all what we want and not what we don't want.
Of course, it's no help unless that happens well before a release, when
we still have the chance to fix things.

> It's certainly much closer to being useful 
> than the other things discussed for removal, however - but it works best 
> when each configuration has someone who will update the ABI for that 
> architecture shortly before each major release is tagged.

Yes, that's how it was when I originally added it.  But it's fallen off.
We should make it part of the official responsibilities of port maintainers
and release branch maintainers.

For that to really work, we'd need to start naming the maintainer for each
release branch before we actually make that release.  That would be a
better way to operate in numerous ways, but it hasn't happened yet.
I hope we can get more coherent about our procedures before 2.16.


Thanks,
Roland