What is glibc-ports?

["Carlos O'Donell" <carlos at systemhalted dot org>]

Community,

At the Linux Foundation Collaboration Summit presentation on The
Future of GLIBC there were several good questions talking about the
perception of what it means to be a machine or library in glibc-ports.

General consensus from the audience was:

* Being in glibc-ports means you aren't an important machine.

* Being in glibc-ports means you don't get generic updates done to all
the machines which are in the glibc git tree and you have to wait for
the machine maintainer to pay-attention and apply the fixes in a
separate commit.

* The fact that ARM is in glibc-ports is silly since it's an important
machine to a lot of people, even if those people aren't in the
server/enterprise market.

My take-away was that the distinction between glibc and glibc-ports
seemed artificial and out-dated.

During the presentation Roland and I argued that glibc-ports serves
the very useful purpose of providing a generic add-ons mechanism for
supporting machines, libraries like libdfp, etc. Having ARM in ports
also meant that the generic mechanism worked for the most complicated
case possible: supporting a new machine. Bottom-line was that we
didn't want to loose the ports add-on mechanism (in fact nptl is also
an add-on but not as complex).

Do we need to do something to correct the perception of our users?
Note that it is more than perception, it is confusion. Why is ARM in
glibc-ports given that it's used in many devices, or MIPS which is
supported by Mentor Graphics through work that Joseph Myers does?

Why doesn't x86 and x86_64 move to ports given that nobody has stepped
up as an active maintainer for either on MAINTAINERS in the wiki? ;-)

My opinion:

* If a port isn't maintained we should remove it from the tree. You
can use source control to resurrect it.

* glibc v.s. glibc-ports is an artificial distinction that we should kill.

* Move glibc-ports back into glibc under ports/ so I can stop dealing
with two repos.

* Keep ports/ the way it is because the add-ons mechanism is very
useful for future ports and libraries from 3rd parties.

* Some day in the future we move all machines into ports/ leaving
generic code outside of ports. If ports is good enough for ARM it's
good enough for everything else, and using ports/ day-to-day will
ensure it doesn't bit-rot.

I know that we've got a lot on our plates, but because these comments
about glibc-ports were made in public, I felt that I should respond in
a timely fashion to the criticism and perception.

Comments?

Cheers,
Carlos.