What is glibc-ports?

[Mike Frysinger]

On Monday 16 April 2012 13:37:48 Carlos O'Donell wrote:
> Do we need to do something to correct the perception of our users?

not to be pedantic, but i don't think "correct" is quite the right word.  
"update" might be better since that's what we're doing here.  after all, 
pretty much every release since ports/ was created has shown the main tree is 
tested + released "on time" while the ports/ dir significantly lagged.

> 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?

i think the answer is obvious given the history of where the sep ports/ tree 
came from in the first place ;)

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

in general, i agree

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

would be nice

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

i like this too, except i'm not sure if there's a way to do it without losing 
history :(

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

i'm not sure people would be happy with adding arbitrary 3rd party addons to 
the main glibc repo ...

> * 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.

sounds reasonable
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120416/d32dfe76/attachment.sig>