Barrapunto

No, aún no he visto en ningún lado que nadie diga nada sobre que ese ebuild estaba en la estable. Esas "pistas" no dicen nada al respecto, de ahí no se puede deducir que estuviese en la estable.
ChangeLog del ebuild de Squirrelmail [gentoo.org] :
*squirrelmail-1.4.1 (08 Jul 2003)
...
28 Jun 2003; Martin Holzer
squirrelmail-1.4.0-r1.ebuild:
removed apache grep stuff.

*squirrelmail-1.4.0-r1 (29 Apr 2003)
21 May 2003; Martin Holzer
squirrelmail-1.4.0-r1.ebuild:
Marked stable on x86.

Más fácil ya no lo puedo poner. Si con esto no se hace evidente que efectivamente *si* estaba marcado estable, yo ya no sé que más hacer, lo siento. Por otro lado: en *este* caso se corrigió porqué puse un bugreport, pero tengo la intuición de que en muchos otros paquetes esto no se corrigió hasta que estos se adaptaron al plugin webapp del portage.

Y el discurso de la "seriedad" está fundamentado en esto (que, por cierto, débil argumento aunque se probase cierto, teniendo en cuenta su antigüedad y que de momento no ha llegado al oído otro "caso").
No está fundamentado en eso. Ese hecho en si, fuera de contexto, es una anécdota informática como cualquier otra. Sin embargo, es el más claro ejemplo de los peligros que entrañan la naturaleza y la estructura de desarrollo de Gentoo. Si ésta ha cambiado o no, no es algo que yo sepa ni me importe en exceso en este momento. Si tu aseguras que sí, y que el equipo de QA se ha hecho fuerte, me alegro.
La propia naturaleza tecnológica de Gentoo implica cierto "elitismo" de sus desarrolladores. Maximizar las variaciones posibles (useflags, cflags, dependencias "blandas" por poder linkar versiones distantes de las mismas librerias, etc..) significa maximizar la posibilidad de problemas y la dificultad de reproducirlos y depurarlos. Y ser capaz de manejar esto convenientemente no es lo mismo que ser capaz de escribir un ebuild o construir un paquete DEB. Si encima no hay unas "Guidelines" concretos y "Policies" estrictos, la cosa se sale de madre con una facilidad inaudita. No dudo que los desarrolladores del core de Gentoo, así como algunos de la "periferia", tengan la capacidad y conocimientos suficientes. Lo que pongo en seria duda (y confirmo por lo que he visto) no es solo que la mayor parte de desarrolladores carezcan de la capacidad y/o conocimientos para ello, sinó incluso que sean conscientes de donde se están metiendo y de con cuantas variables están jugando. Por esa razón en Debian existen tantas reglas (estúpidas para muchos): para que la mayor parte de esas variables se conviertan en constantes y el problema sea manejable.

Sobre el tema de la organización de la gente en Gentoo: lo que yo ví (en "hardened") fue todo lo contrario. Que pueda ocurrir en lo que tú viste, perfecto. ¿Se puede asegurar que un pequeño grupo no se comporte de forma similar en Debian?
Supongo que los desarrolladores del GLEP hardened serían lo suficientemente avanzados como para coordinarse bién entre ellos y no cometer errores garrafales; la propia naturaleza del subproyecto implica esas características. Tampoco dudo de la sobrada capacidad del "core" de desarrolladores de Gentoo; no se monta una distribución semejante sin unos buenos conocimientos ni capacidad de coordinación. A lo que me refiero es que se aceptan (o aceptaban) paquetes de cualquier usuario sin una revisión en profundidad. Por la estructura del portage, un "inocente" bug en un ebuild puede causar estragos en el sistema (aunque se use el sandbox), y por lo tanto estos deberían revisarse en profundidad. Puedo entender que falten recursos humanos y paciencia para ello, o que el proyecto esté algo verde, pero no que se niegue uno de los principales problemas de la distribución. Tal como leí en alguna firma: "When you are on the cutting edge you WILL