On Wed, 2009-04-15 at 20:55 -0400, Aldrin Martoq wrote: > On Wed, 2009-04-15 at 18:02 -0400, Alvaro Herrera wrote: > > Germán Póo-Caamaño escribió: > > > On Wed, 2009-04-15 at 16:58 -0400, Franco Catrin L. wrote: > > > > Para que no se vuelva una discusión inútil, la idea es aclarar que los > > > > ciclos de Debian son más impredecibles que los de Ubuntu LTS. Hace poco > > > > tiempo fue liberada oficialmente la versión de Debian estable y antes de > > > > eso los paquetes de Debian estable oficial eran del año de la cocoa. > > > > > > > > Lo mismo va a volver a pasar en un tiempo más y el problema de fondo es > > > > que no se sabe a ciencia exacta cuando será el release oficial del > > > > próximo, o estoy mal? > > > No. Tanto así como el tiempo de la cocoa no. 22 meses entre una > > > versión y otra no es mucho tiempo. Y Debian intentar ir por un período > > > de 18 meses entre versiones, con un margen de hasta 24 meses. > > > Y para cuando necesitas paquetes más nuevos para una versión estable que > > es "algo vieja", siempre puedes usar backports ... > > Y ahi perdemos toda la gracia de Debian y usas algo con ciclos mas > cortos mejor. He visto millones de Debian (e incluso Ubuntu) stables > pichicateados con urls alienijenas porque les falto tal o cual feature > que no tiene el paquete de hace 4 an~os (o 6 meses en el caso de > Ubuntu!)... Y rompen toda la estabilidad que tenia el sistema.
No mezcles. Creo que Alvaro se refiere particularmente a http://www.backports.org/ los cuales, aunque lo añadas en tu sources.list no se instalarán, porque tienen la menor de las prioridades. Esto es sí y sólo si requieres un paquete especial en una versión dada no disponible en el momento de salir la versión estable. Y el esquema es tal, que no rompe una actualización de sistema, disminuyendo el riesgo que configuraciones alienígenas podrían dar. En lo personal, uso estable y sólo con 'main'. 'contrib' podría ser un caso muy especial. 'volatile' en aquellos donde se requieren los patrones de antivirus/spam actualizados y 'backports' cuando una característica en el programa (no en el paquete) se resolvió a partir de una versión próxima. Sin embargo, si recuerdas la época de Unix (Aix, Slowlaris, HP/UX, DG/UX, Ultrix, etc), lo que tenemos hoy es una delicia. Así que ponerse demasiado quisquilloso, sería como comprarse un 4x4 y reclamar porque las rueditas se ensuciaron con un poco de tierra. > [...] > Lo que comentaba Alvaro de que "va a estar listo cuando este listo" que > traducido significa "nos demoramos porque estamos asegurandonos que no > tenga bugs" es un error. Todo software tiene errores, en particular una > nueva version; Atrasar el proceso eternamente no ayuda a minimizar el > problema (porque resolver es imposible)... de hecho siempre Debian ha > liberado la version x.0.1 en uno o dos meses. No. La semántica de "va a estar listo cuando este listo" es distinta a como lo planteas. Si para la versión X+1 se ha definido que tenga Y característica, entonces no se va a liberar hasta que dicha característica se implemente de forma satisfactoria, no que esté libre de errores. Y la idea de dicho discurso, es no apurarse en parchando discrecionalmente, sino con claridad respecto a la solución que en ese momento se cree mejor. Con los ciclos definidos claramente, cambias el enfoque y abres la posibilidad que si característica Y no está lista, entonces puedes retrasarla para la siguiente. Salvo en casos muy particulares, como la primera versión LTS de Ubuntu, que no le daba para ser considerada LTS y es por ello que se retrasó en 2 meses. El inconveniente del segundo enfoque es te mueves en un péndulo en donde las cotas son 'estabilidad' e 'innovación', con tendencia hacia la 'estabilidad' que a la 'innovación'. -- Germán Póo-Caamaño Concepción - Chile http://www.calcifer.org/