Así es el proceso del lanzamiento de openSUSE

Alguna vez te has preguntado ¿Cómo se desarrolla y lanza una nueva versión de openSUSE? Aqui tienes la explicación a “grosso modo” en tres sencillos pasos.

candado_geekoEste artículo es una traducción propia de un artículo escrito por Michal “|Miska|” Hrusecky un hacker de openSUSE al que tuve la oportunidad de conocer en el hackathon de Nuremberg. Puedes consultar el original en inglés en este link: https://lizards.opensuse.org/the-opensuse-release-process/

En el artículo explica en tres pasos el proceso que siguen los desarrolladores de openSUSE a la hora de realizar un nuevo lanzamiento de una nueva versión. Me pareció interesante, así que me he tomado el (laborioso) trabajo de traducirla. Puedes usarla y difundirla, pero atiende a la licencia del blog, citando expresamente las fuentes! 😉

Por cierto os recuerdo (y si no lo buscais por mi blog) que openSUSE 13.1 saldrá en Noviembre, que tendrá un largo soporte oficicial y extendido por el proyecto Evergreen, y que ya incluye novedades en la gran herramienta YaST. No te lo pierdas!!

Gracias por permitir la reproducción y difusión. Espero que a ti (como buen geek) también te interese! 😉

Antes que nada aclarar que openSUSE Factory es la versión de openSUSE que se encuentra en desarrollo. Es decir, descargando la versión Factory tendrás los últimos paquetes pero no versiones estables, si no versiones en desarrollo. Por lo que pueden estar llenas de inestabilidades, problemas, etc… No está aconsejada para un uso normal de la distro y sí para desarrolladores o usuarios interesados en revisar, testear y ayudar en el desarrollo de la distro reportando errores, problemas, etc.

Conseguir un nuevo lanzamiento de openSUSE conlleva mucho trabajo. Puedes leer parte de lo que hacemos los desarrolladores en este artículo. Pero como te puedes imaginar hay muchas más cosas que hacer. Veamoslo simplificado en esta guía en tres pasos.

Primer paso: Desarrollando Factory

Una vez lanzada la versión estable de openSUSE, inmediatamente empieza el trabajo para la nueva versión: es una historia sin fin. Lo primero que sucede durante un nuevo ciclo de desarrollo es que “Coolo” (un hacker de openSUSE) anuncia la hoja de ruta con las fechas de los hitos (lanzamientos de RC’s, betas, …) Este es el esquema de trabajo del lanzamiento y los puntos claves que debemos seguir para alcanzar la meta.

Después la versión Factory (nuestra versión de desarrollo) no se vuelve a “congelar” ya más y la gente puede empezar a mandar nuevo material para que sea incluido. Normalmente se vuelven locos y mandan un montón de material y paquetes experimentales con lo que puede que algunas partes de la versión Factory sufran errores e inestabilidades.

Ahora es la hora de dejar que la versión Factory ruede. Una imagen vale más que mil palabras. Así se incluyen paquetes en Factory:

Un desarrollador crea un paquete de software en su repositorio local y lo manda a los desarrolladores del proyecto que le dan un repaso básico (dependiendo del trabajo que haya). De allí, el paquete de software pasa a Factory, donde se le pasarán muchas pruebas automatizadas (que mencionaremos más adelante) y además se le revisa de manera visual por el equipo de repaso.

Una vez que el paquete pasa todas esas comprobaciones, ya forma parte de Factory. Y “rompe” algo más una vez allí. así que alguien debe crear una nueva rama, arreglarlo y de nuevo todo el proceso, esta vez con un paquete diferente…

Estamos trabajando en documentar de manera más detallada todo el proceso de desarrollo de Factory, ¡así que estate atento en los próximos meses!

Comprobando los requisitos…

Hay unos cuantos bots (N.d.T: Scrips automatizados) que comprueban los paquetes que se mandan a Factory.

El primero es factory-auto que hace algunas comprobaciones básicas comprobando el archivo spac, alertas rpmlint y otros similares. Si pasas este rápido test, es hora de una comprobación más profunda.

Un bot llamado factory-repo-checker intenta instalar tu paquete de software en un entorno de pruebas para segurarse de que es posible hacerlo, y también busca posibles conflictos con archivos, así que no debería sobreescribir el software de otros.

La última comprobación antes de que el software llegue al equipo de revisión es legal-auto. Este comprueba la licencia (¿es un cambio?¿es un nuevo paquete?) y si es necesario avisa al equipo legal de openSUSE para que echa un vistazo al software.

El paso final es una revisión manual por los miembros del equipo de revisión que intentarán encontrar errores, que se les pasó a las comprobaciones automáticas.

Segundo paso: congelando

Podríamos estar rompiendo cosas y arreglándolas indefinidamente, pero como hay que lanzar openSUSE en algún punto, tenemos que hacer algunas “congelaciones” del código.

La primera se llama Toolchain Freeze. Cuando llegamos a este punto, no se aceptan nuevas versiones de compilaciones, sólo reparaciones de errores. De esta manera se pueden arreglar los errores sin tener miedo a que nuevas compilaciones lo estropeen todo.

La siguiente se llama Base System Freeze que significa que se congelan el kernel, KDE, Gnome, X11, etc… Todo esto son componentes importantes de los que depende mucho software.

El resto de paquetes (después de que se hayan corregido/actualizado) se congelan con el lanzamiento de la última versión Beta1  que es cuando se alcanza lo que se llama Full Feature Freeze. En este punto sólo se incluyen correcciones de errores, ya no se incluyen nuevas versiones, o cosas así que pudieran echar todo a perder.

fondo1

Tercer paso: Seleccionando una ISO

Cuando nos vamos acercando al lanzamiento, Factory se divide en repositorios separados, actualmente 13.1 Factory que sigue descongelado y empieza a vivir una nueva vida empezando el proceso de nuevo.

Y el nuevo lanzamiento que sigue una última estabilización y una fase de comprobaciones profundas (tanto de manera manual como a traveś de la herramienta openQA ) Cada ISO automaticamente compilada se comprueba hasta que se selecciona la versión Gold Master.

La versión Gold Master debe ser instalable y no puede contener errores críticos de funcionalidad. Todavía contiene errores menores y conocidos, sería imposible realizar un lanzamiento si esperásemos a que la ISO estuvira libre de errores!

Pero esos errores pueden ser corregidos mediante actualizaciones o algunos de ellos solucionados antes del la fecha del lanzamiento oficial.

Después de seleccionar la versión Gold Master, nos lleva normalmente dos semanas sincronizarla en nuestros “mirrors” de descarga y tenerlo todo a punto para el gran día.

Durante ese tiempo los desarrolladores se han estado reservando algunas soluciones de errores y cuando descargas tu flamante nueva ISO de openSUSE, ya hay muchas soluciones de errores listas y esperando ser actualizadas e instalas.

Enlaces de interés

8 pensamientos en “Así es el proceso del lanzamiento de openSUSE

  1. Grandioso, hace unos días que estoy usando OpenSuse por trabajo de la Universidad y está información me viene perfecta, te agradezco como siempre compañero.

Me gustaría saber tu opinión. Deja un comentario (Puedes usar MarkDown)

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s