Re: Directory for localplt / c++-types data

[Roland McGrath <roland at redhat dot com>]

> What do you think of this patch?  The data files have long names;
> having them in the top level of the ports add-on would be ugly, and
> there's a precedent (the "sysdeps" subdir).

That seems fine enough I suppose.  I put it in.  If anyone ever actually
used the "make dist-port-foo" support in ports/Makefile, it would need
to be fixed to select the right files from data/ too.

It sucks for the ACL maintenance too.  But feh.  It probably should have
been sysdeps/something/data a la preconfigure to keep the per-add-on
bits of the layout simple.

> On a related note, if Joseph's agreeable, I'd like to suggest him as a
> ports maintainer or at least write-after-approval.  Basically the only
> thing I've done on ports in a year is commit Joseph's patches
> (usually late).

You and aoliva are empowered as general "ports" committers.  That means
general write-after-approval for anything in ports, and discretion about
what parts of ports need what manner of approval from whom.  I am fine with
anyone joining that class whom the libc-ports consensus agrees is known
responsible in those ways.

Each specific arch port in ports has a list of empowered maintainers.
(You are on the lists for arm and mips.)  Who goes on each arch port's
list and with what understanding about approvals is entirely up to those
maintainers, and I'll add/remove anyone you like on request (and you can
take care of the overseers part of putting the user in the glibc group).
The only hard requirement from me is strict adherence to the copyright
regime, and I trust each current arch port maintainer to ensure that
anyone they give access understands and upholds those reliably.  (This
means nothing not already clearly under an FSF assignment, nor anything
new with any copyright owners other than FSF, can ever go in.)


Thanks,
Roland