Xfce

Subdomains
 

Modelo de publicación

En el pasado han surgido las mismas preguntas y discusiones una y otra vez cada vez que había una publicación nueva a la vista, como:

  • ¿Cuáles son los componentes principales de Xfce?
  • ¿Con qué frecuencia se quiere publicar y de qué modo (en función del tiempo, en función de las características)?
  • ¿Quién está a cargo del proceso de publicación?
  • ¿Cuáles son las versiones de las dependencias?
  • ¿Cuándo se congelan las características, las cadenas, el código y otros elementos similares?
  • ¿Cuántas publicaciones previas hay que hacer y cómo hay que llamarlas?
  • ¿Por qué se reemplazó el sistema de revisión SVN por Git?

Este documento pretende responder a estas preguntas y tiene como objetivo definir una política a la que nos podamos referir a la hora de planificar las publicaciones.

El núcleo del escritorio Xfce

Componentes principales

  • exo
  • gtk-xfce-engine
  • libxfce4ui
  • libxfce4util
  • thunar
  • thunar-volman
  • xfce4-appfinder
  • xfce4-panel
  • xfce4-session
  • xfce4-settings
  • xfconf
  • xfdesktop
  • xfwm4
  • garcon
  • tumbler
  • xfce4-power-manager

Todos los componentes principales del escritorio Xfce deben cumplir la política de publicación definida en este documento.

Dependencias esenciales

  • GTK+
  • GLib

El ciclo de publicación

El ciclo de lanzamiento consiste en una corta fase de planificación, una fase de desarrollo con versiones de desarrollo y una fase de liberación, eventualmente precediendo a una nueva versión estable del escritorio Xfce completo. En paralelo a estas fases, se lleva a cabo un proceso de mantenimiento de la versión estable actual. Durante esta fase, se publicarán las modificaciones para corrección de errores y parches de seguridad en la versión estable de Xfce.

A continuación puede ver una cronología gráfica de un ciclo de publicación de ejemplo y el proceso de mantenimiento de Xfce 4.8 con tres componentes: Thunar, exo y xfwm4.

example-release-cycle

Ejemplo del ciclo de publicación

Fase de planeación (2(+2) semanas)

Esta fase marca el inicio del ciclo de publicación y se utiliza para decidir las dependencias a usar y también para nombrar el equipo de publicación para el ciclo (primeras 2 semanas). Finalmente lleva al estabilización de dependencias (después de 4 semanas).

Nombramiento del Equipo de publicación

Al comienzo de la fase de planificación hay un derecho a voto (formal o informal) para el equipo de desarrollo. El equipo de publicación supervisa versiones de desarrollo y mantenimiento durante el ciclo de lanzamiento. Su objetivo principal es llevar a cabo un doble chequeo en los lanzamientos del escritorio Xfce en la fase de publicación así como en la fase final del ciclo de liberación. Esto se explica con más detalle en la sección del equipo de publicación de este documento.

Equipo de publicación

El equipo de publicación se compone de al menos dos personas: un encargado de la distribución, que puede ser ayudado por otras personas para llevar a cabo la distribución (etiquetado, la creación de archivos comprimidos, escritura de notas de la versión y anuncios) y la otra persona para el aseguramiento de la calidad (comprobar si se compilan los componentes, las etiquetas están en su lugar, notas de la versión están al día y así sucesivamente). Esto se define en mayor detalle más adelante.

Estas son las funciones del equipo de publicación y sus responsabilidades:

Administrador de Publicación

  1. Organización del ciclo de publicación
  2. Fijar plazos a los desarrolladores y traductores (en varias ocasiones y lo suficientemente pronto)
  3. Supervisión de las versiones de mantenimiento y el desarrollo
  4. Etiquetado de Xfce-X.Ypre1, Xfce-X.Y.pre2, Xfce-X.Y.pre3 y Xfce-X.Y
  5. Generar achivos comprimidos desde etiquetas (posiblemente automatizado)
  6. Escribir notas de publicación
  7. Escribir anunciones de publicación
  8. Crear etiquetas de nuestro seguidor de errores (Bugzilla)
  9. Aprobar correcciones de errores de bloqueo durante la estabilización de código

Asistent(es) de publicación

  1. Actualizar los sitios web
  2. Ayuda al administrador de publicaciones con sus tareas

Oficial QA

  1. Prestar atención a las versiones de libtool en las versiones de soporte y desarrollo
  2. Recordar a los mantenedores sobre la falta de actualizaciones de NOTICIAS
  3. Revise dos veces los archivos comprimidos generados
  4. Revisar los anuncios de liberaciones

Responsables individuales

  1. Crear etiquetas para componentes específicos para su mantenimiento y versiones de desarrollo
  2. Generar archivos comprimidos de las publicaciones de mantenimiento y desarrollo
  3. Escribir registros de cambios y actualizar los archivos de NOTICIAS
  4. Escribir anuncios de publicación de un componente específico
  5. Crear etiquetas en nuestro segudor de errores (Bugzilla) para sus lanzamientos
  6. Asegúrese que la documentación de la API esta actualizada

Estabilización de dependencias

Durante las primeras 2 semanas de la fase de planificación cada desarrollador tiene la obligación de

  1. Lista de características que quiere implementar en el ciclo de publicación
  2. Investigar qué dependencias están implicadas por esta

Al final de este, se toma una decisión acerca de las dependencias de la próxima versión estable del escritorio Xfce. En particular, esto incluye las versiones mínimas requeridas para las dependencias esenciales del escritorio Xfce núcleo.

Una vez que un error ha sido encontrado, la causa del error necesita ser identificada, y luego (obviamente) arreglada. Si quiere ser parte del actual proceso de desarrollo de Xfce una buena forma de comenzar es solucionando errores y enviando los parches.

Al final de estas 4 semanas, se suspende cualquier cambio en todos los componentes y sus dependencias (y de sus versiones), aunque se permite la modificación de dependencias opcionales.

Informe a la comunidad

Al final de la fase de planificación, un correo con las características previstas y las dependencias de todos los componentes del núcleo del escritorio Xfce se envía a las listas de correo y xfce4-dev@xfce.org xfce@xfce.org.

Fase de desarrollo (5 meses)

Durante la fase de desarrollo de cada desarrollador es libre de hacer el mantenimiento y versiones de desarrollo de sus componentes, independientemente del resto de Xfce.

Versiones de desarrollo

La versiones de desarrollo suelen dar una vista previa de características de la próxima versión estable. Deben seguir el formato X.Y.Z. de versiones, donde Y es un número impar (por ejemplo, xfwm4-4.7.10 o thunar-1.3.37).

Se anima a los mantenedores a desarrollar versiones con nuevas características que quieran poner a disposición de los demás. Los lanzamientos frecuentes de versiones de desarrollo pueden actuar como un sustituto de la revisión de versiones SVN que existía en el pasado. Si un componente A depende, en una nueva función, de un componente B, A solamente podrá ser liberado si hay una versión de desarrollo que tenga este componente. Para que esto funcione adecuadamente, las versiones de libtool tienen que ser actualizadas debidamente en cada versión de desarrollo.

Ha de tenerse cuidado de la rama principal de cada componente. La rama principal debe siempre permanecer preparada para ser lanzanda. Las características nuevas deben desarrollarse en otras ramas haste que esten completas(la compilación y el componente permanecerán funcionales incluso después de la inclusión de la nueva característica en la rama principal)para reducir el riesgo de retrasos en el lanzamiento final del núcleo completo del escritorio Xfce.

Las nuevas características de la API de última hora u otros componentes del núcleo deben ser comunicadas oportunamente. Se sugiere a los mantenedores que prepararen los componentes de estas características nuevas en una rama separada antes de incluirlas en la nueva entrega. De este modo, los demás componentes se conservan listos para ser liberados.

Así es como el flujo de trabajo en el desarrollo básico luce:

feature-branching

Flujo de trabajo en el desarrollo

Fase de publicación (10+ semanas)

Durante la fase de publicación, habrán tres prepublicaciones y una versión final:

  1. Xfce X.Ypre1 (después de 0 semanas, estabilizado de características),
  2. Xfce X.Ypre2 (después de 4 semanas, estabilizado de cadenas) y
  3. Xfce X.Ypre3 (después de 8 semanas, estabilización del código)
  4. Xfce X.Y (después de 10+ semanas)

donde Y tiene que ser un número par. Cada una de estas entregas tiene que incluir las últimas versiones de desarrollo de todos los componentes ( o las estables sino hay versiones de desarrollo desde la última estable) del núcleo del escritorio Xfce. El número de versión de estos componentes puede diferir del esquema anterior. Por ejemplo, para Xfce 4.8.0pre2, xfwm4 puede tener la versión 4.7.17 y Thunar puede tener la 1.1.9.

Esto significa que los mantenedores no necesariamente tienen que lanzar nuevas versiones de sus componentes a lo largo de uno de sus prelanzamientos. El equipo de publicación siempre recoge los últimos avances disponibles de cada componente para la versión estable, las versiones previas y la final.

El final de esta fase marca una nueva publicación estable del núcleo del escritorio Xfce y con ello el inicio de un ciclo nuevo de publicación.

Congelamiento antes de las publicaciones

Hay diferentes tipos de estabilización antes de las publicaciones.

Estabilización de características

Con Xfce X.Ypre1, todos los componentes básicos mantienen suspendidas sus características, lo que significa que a partir de ahí solamente traducciones y correcciones de errores se permiten en la rama principal.

Estabilizado de cadenas/IU

Con Xfce X.Ypre2, todos los componentes básicos entran en período de estabilización, lo que significa que no habrá cambios en las traducciones. De la misma forma ocurre para la interfaz de usuario que no admitirá cambos.

Estabilización de código

Hay 2 días de estabilización en la elaboración de código antes de cada prepublicación. Durante este período de tiempo, no se deben realizar aportaciones a menos que sean firmadas por el administrador de la versión.

Con Xfce X.Ypre3, todos los componentes básicos entran en estado de estabilización de desarrollo, lo que significa que no se permiten cambios en el código a menos que estén avalados por el administrador de la versión. Estos suelen ser, por lo general, para la corrección de problemas críticos. En esta fase se permite la realización de traducciones.

Fase de estabilización del código (2+ semanas)

Con Xfce X.Ypre3, todos los componentes básicos entraron en estado de estabilización del código. Esta fase se ilustra en la siguiente figura y se explica con más detalle en esta sección.

Las pausas en la escritura de código así como las excepciones a estas están debidamente gestionadas. Hay actualizaciones de la rama principal que no permite ningún cambio a menos que estén firmados por el encargado de la publicación.

code-freeze-branching

Etiquetado y ramas para las publicaciones

Correción de errores/Cambios

Si un componente básico requiere correcciones o cambios durante la estabilización del código, el responsable está obligado a crear una nueva rama llamada ELS (//nombre abierto a debate//) a la que él o ella enviarán las correcciones. Consulte la sección si hay algunos cambios críticos o correcciones para los errores bloqueantes.

La rama ELS solamente está activa por un corto período de tiempo. Esta se combina con la master y en los componentes de la rama estable (por ejemplo, xfwm4-4.8 o thunar-1.2) después de la liberación final. Solamente se permiten correcciones en esta rama.

Excepciones de la estabilización del código.

Errores bloqueantes

Ciertos errores pueden retrasar la publicación final, si se consideran bloqueantes. Este es el caso en alguna de las siguientes circunstancias:

  • hace fallar una aplicación del núcleo
  • causa pérdidas de datos
  • provoca una perdida de memoria cada vez mayor
  • bloquea el GUI entero del escritorio

Un error puede no retrasar la publicación si se conocen los siguientes criterios:

  • el hardware o la arquitectura en el que se produce el error es excepcional o no hay modo de que los desarrolladores lo reproduzcan

Las soluciones para estos errores pueden ser aplicadas durante la estabilización de código si y solamente si están firmadas por el encargado de la publicación.

Cambios de importancia crítica para la publicación

Algunos cambios pueden ser de gran preocupación en lo que respecta a la calidad de la publicación. Se les permite entrar si, y sólo si son firmados por el administrador de la publicación.

Publicando

Para la versión final (Xfce X.Y), todos los componentes principales están marcados (dos veces: una con su propia versión y otra con xfce-X.Y.0) y ramificados para el ciclo de mantenimiento (por ejemplo, como thunar-1.2 o xfwm4 4.8). Después, la rama ELS se combina con la master (donde el desarrollo de la próxima versión se lleva a cabo), en el ejemplo thunar-1.2 o 4.8 xfwm4.

Proceso de mantenimiento

Después del lanzamiento de una versión final, las correcciones de fallos y actualizaciones de la traducción se sitúan en una rama de componentes estables específica (como thunar-1.2 o xfwm4-4.8). No se requiere la sincronización de componentes individuales.

Publicaciones de mantenimiento

Puede que no hayan cambios de API o ABI en las versiones de mantenimiento si se comparan con la versión final del escritorio Xfce. También debe seguir el formato de versiones de XYZ, donde Y es un número par (por ejemplo, xfwm4-4.8.4 o thunar-1.2.4). No hay características nuevas y nuevas traducciones pueden ser introducidas en estas versiones.

Autores

  • Jannis Pohlmann <gro.ecfx@sinnaj>
  • Stephan Arts <gro.ecfx@nahpets>