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 bleed".

me da la sensación de que crees que no hay gente de "nivel" en Gentoo
No he afirmado eso en ningún momento. Es más, ya he especificado en varias ocasiones que hay gente muy competente en el proyecto. Lo que sí he afirmado es que *también* hay gente con muchos menos conocimientos, y que estos pueden introducir en Gentoo ebuilds peligrosos (ojo, sin mala fe) sin una revisión suficiente. No hablo de cerrar la distribución a cal y canto; sin la ayuda de "la comunidad Gentoo", el "core" solo no podría haber hecho crecer el número de paquetes al mismo ritmo. Hablo de *revisar* convenientemente, cosa que por lo menos en el pasado no se hacía. Y que aunque así fuera, los de QA tienen un problema mucho más gordo y difícil de manejar que los de debian o redhat, por ejemplo. Evidentemente, la mayoría de problemas no serán ni de lejos tan graves como los que he descrito con las aplicaciones web, pero también por eso serán mucho más difíciles de detectar.
Yo mismo hize un ebuild para xdiskusage [gentoo.org], y me encontré con el problema de modificar los sources. He hecho miles de expresiones regulares, y no me costaba nada hacer otra más como en tantos ebuilds he visto. Pero preferí no hacerlo y avisar del problema para que un desarrollador lo arreglase. Y como era de esperar, Brandy encontró la manera correcta de hacerlo. Si hubiese puesto una expresión regular y me hubiese callado sin más, ¿se habría dado cuenta alguien?

JDK/JRE: blackdown es libre e instalable. Igual que en Gentoo se tiene un virtual/x11 equivalente a x-window-system (no, no hacía falta que explicaras eso, ni lo de que Gentoo no inventó lo de compilar, ni lo de las webapps, me da la sensación de que crees que no hay gente de "nivel" en Gentoo...), se tiene uno (con el concepto de "slots") para el JDK. Como ya dije, en Gentoo no hay problema.
Blackdown no es libre [blackdown.org] porque Java no lo es: As a developer, you unfortunately may not redistribute the Blackdown JDK on CDROM without permission from Sun. Sun has suddenly become very clear about this. Commercial Linux distribution vendors such as Red Hat must work with Sun directly to secure such rights.
Esto significa que *NO* se puede hacer un paquete DEB oficial de Blackdown. Punto final, que este tema ya cansa. Mucho se ha hablado de ello en muchos sitios, y no hace falta repetirse hasta la saciedad.

En cuanto a lo de las XWindow, ¿tienes que "adivinar" que el paquete se llama "x11"? ¿Verdad que lo tienes que buscar, o consultar en alguna parte? Pues eso.

Pues eso es de lo que iba mi post principal, y que cualquiera puede comprobar, tanto en una como en otra, si dan o no problemas.
Y yo no te negué en ningún momento que hubieran problemas en Debian Sid. Pero solo un caso me pareció grave, y algunos de los otros más que discutibles. Lo que yo comentaba es que esa Gentoo que pareces haber estado usando sin problema alguno, a mi me dió muchos más problemas de los deseables. Yo ya tengo comprobado qué problemas me dan una y otra respecto a mantenibilidad, y te los he comentado. Ninguna de las dos es perfecta, y cada una tiene sus defectos, pero a mi los de Gentoo me provocan bastantes más problemas que los de Debian (incluso si hablamos de Sid).

Ni que buscársela por errores que hubo en los .DEB ni buscársela para tener un JDK.
Completamente de acuerdo en lo primero, completamente en desacuerdo en lo segundo. Si SUN quiere que te busques la vida en su página web, y asi lo expresa en su licencia, te buscas la vida. A ver si *encima* los otros nos vamos a buscar problemas legales por distribuir su maldita tecnología. Ya he expresado que lo del ebuild/deb de sun jdk/jre está rozando la línea de lo legal, sin saber muy bién por qué lado.

Esa es la actitud o culturilla "conservadora" basada en "axiomas" totalmente _falsos_ que ha creado escuela entre muchos administradores de sistemas/redes y usuarios de algunas distribuciones. Dime, ¿quién dice que una distribución "no se lleva" desde un foro? ¿Es esto como el concepto de "seriedad"? Dos cosas te digo: la primera, un "foro" es un medio más de comunicación perfectamente válido y, como se ha demostrado, más que eficaz especialmente de cara a los usuarios, y la segunda, en Gentoo también saben lo que son los servidores de correos, las listas de correo y los gestores de bugs, como bien sabes.
Un foro, como su nombre indica, es un lugar de discusión (en el buen sentido de la palabra). Punto. No tiene control de estado de un paquete por arquitectura. No tiene asignación ni gestión de bugs, ni su criticidad, ni su antigüedad. No permite adjuntar ficheros core, volcados de memoria, trazadas o logs. No genera resúmenes automáticos del estado general de la distribución para saber si está preparada para un release "estable". Por algo Gentoo tiene su Bugzilla (aunque que yo recuerde le costó algún tiempo tenerlo). Pero es que tiene cojones que para encontrar la manera de solucionar un bug, ¡debieras irte a los foros!.

Al final, la cuestión inicial, mostrar que efectivamente hay bastantes problemas con sid ha quedado clara. Lo mismo sobre Gentoo queda para otra vez que alguien -ya que tú no quieres- quiera hacer la prueba, y compare los resultados.
Pero eso no es lo que yo entiendo por mantenibilidad. Tu criticabas la mantenibilidad de Debian, pero basándote en lo que yo entiendo que es su instalación. Encima, la instalación beta de la rama inestable. Y si te mantienes en la rama inestable, ya te vaticino que el mantenimiento tampoco será un camino de rosas, principalmente por problemas de dependencias.
Yo ya he hecho la prueba de mantenibilidad de Gentoo, y ya he dicho con lo que me he encontrado en este tiempo, y con lo que me sigo encontrando cuando intento actualizar alguna de las máquinas ya instaladas. Ya sé que haciendo "borrón y cuenta nueva" los resultados son mejores, puesto que los problemas surgen normalmente por cambios de versiones importantes, con dependencias de librerías de por medio. Pero es que yo he criticado la mantenibilidad de Gentoo en su rama estable, no su instalación. Si hubiese hablado de instalación, me habría centrado en las horas de compilación (GLEP aparte) y la absoluta inexistencia de un programa de instalación (aunque se que hay un proyecto desde hace tiempo para crear uno).