openSUSE:Modelo de desarrollo de Factory
Contenido
|
La mayoría de enlaces llevan a las páginas de la wiki en inglés por no estar traducidas en este momento. Puedes aportar tu contribución traduciendo alguna de ellas. |
|
Modelo de desarrollo
Factory se desarrolla en su propio proyecto openSUSE:Factory en el servidor de referencia Open Build Service. Como puede verse, es un repositorio de paquetes enorme. Sin embargo, el desarrollo no se lleva a cabo en openSUSE:Factory directamente sino en los llamados proyectos de desarrollo. Un proyecto de desarrollo, como sugiere su nombre, es un proyecto donde se lleva a cabo el desarrollo de un grupo específico de paquetes. Por ejemplo, multimedia, GNOME, KDE o kernel. La relación de los paquetes en el proyecto openSUSE:Factory con los de los proyectos de desarrollo se expresa en los metadatos de los paquetes en openSUSE:Factory.
Proyectos de desarrollo
Cada proyecto de desarrollo tiene su propio conjunto de procesos, reglas y canales de comunicación que mejor se les ajustan. El punto de referencia para esta información es la descripción del proyecto de su proyecto Build Service. Los proyectos de desarrollo son también objeto de cambio porque el mundo del software FOSS evoluciona constantemente. Esto significa que los proyectos de desarrollo cambian de nombre, se eliminan, se crean o cambian de contenido y dirección al igual que pueden hacerlo los paquetes de dichos proyectos. Los proyectos de desarrollo que actualmente nutren a Factory se pueden encontrar en un menú desplegable en la parte superior de ésta página. Puede encontrar una descripción resumida del proceso de aportaciones a Factory aquí.
Una descripción más detallada sobre el tema se encuentra aquí.
Proyectos de transición (Staging Projects)
De vez en cuando, un paquete básico específico (una nueva versión de GCC, p. ej.) tiene el riesgo potencial de romper tantas cosas que los encargados de Factory deciden crear un proyecto especial de transición con el que se construye Factory usando el nuevo paquete. Sus desarrolladores pueden entonces corregir las roturas que aparezcan antes de integrarlo de vuelta en Factory.
Los proyectos de transición se pueden ver como una rama de Factory en la que cada desarrollador puede preparar cambios o actualizaciones a diversos paquetes, construirlos juntos, probarlos y enviarlos juntos para que se incluyan en Factory cuando todo haya sido testado con éxito.
Factory está dividido en tres anillos (0-bootstrap, 1-minimalX, 2-testDVD). El anillo más interno (0-bootstrap) contiene paquetes que forman el sistema más básico y minimalista. El siguiente anillo contiene al anillo 0 más todo lo necesario para el funcionamiento de un sistema X mínimo. Finalmente, el anillo más externo contiene todo lo demás.
Cuando se hace una solicitud de envío de un paquete que pertenece al anillo interno, la petición se coloca automáticamente en espera para la revisión Staging Master y se le asigna a un proyecto de transición específico. En la actualidad hay 10 proyectos de transición ̣—llamados A, B, C, D, E, F, G, H, I y J— cuyo propósito y paquetes cambian con el tiempo. La etapa J es un caso especial; su propósito es testar paquetes que no pertenecen a ningún anillo (paquetes nuevos p. ej.). Para cada proyecto de transición se genera una imagen ISO de instalación y se testea con openQA para verificar que sus paquetes no rompen el Factory actual.
Es posible que fallen otros paquetes debido a estas solicitudes de envío, en cuyo caso se añaden dichos paquetes al mismo proyecto de transición para que se construyan los unos junto con los otros.
Una vez que se construye con éxito cada paquete del proyecto de transición y los tests de openQA son satisfactorios, el encargado de Factory puede enviarlo y dejar el proyecto de transición libre para probar otros cambios en el futuro.
osc-plugin-factory es la herramienta que gestiona todo lo relacionado con el proyecto de transición. El documento del complemento de transición explica el uso de la herramienta.
Visión general del proceso de desarrollo
El proceso de desarrollo completo se detalla en esta página. Consta de los siguientes pasos:
- La hoja de ruta y planificación de características se gestiona por el encargado de publicaciones, que crea una hoja de ruta inicial. Mientras tanto, los desarrolladores establecen los objetivos técnicos para la distribución basándose en las fechas previstas de publicación y congelación.
- El desarrollo de paquetes comienza en un proyecto de usuario en el OBS [8]. El desarrollador de paquetes puede trabajar ahí si afectar a nadie más. Una vez que el paquete es lo suficientemente bueno se puede crear una una solicitud de envío a un proyecto de desarrollo.
- La integración con el proyecto de desarrollo continua, supervisada por encargados de proyecto que mantienen un ojo en la calidad técnica de las solicitudes de envío y en el estado general del proyecto de desarrollo. Tras una integración exitosa, los encargados de proyecto crean una solicitud de envío para Factory.
- El proceso de revisión se asegura de que todos los paquetes que van camino de Factory pasen por 4 (a veces 5) revisiones:
- Factory-Auto: un script que comprueba las reglas básicas [10]
- Legal-Auto: un script que comprueba si la licencia del paquete está en la base de datos de las permitidas [10]
- Repo-Checker: una comprobación automática más en profundidad (y lenta) [10]
- Equipo de revisión: comprobación por personas de la solicitud
- Opcional: comprobación por personas del Equipo de seguridad (si Legal-Auto lo estima necesario)
- La Integración con Factory se supervisa por el encargado de Factory y los encargados de publicaciones que aceptan la solicitud de envío que llega de los distintos proyectos a Factory [9]. Mayormente toman las decisiones en base a fechas y factores políticos como las congelaciones que pueden estar vigentes mientras el proceso de revisión ya se ha ocupado de la calidad. En algunos casos deciden que se necesita un proyecto de transición. Cuando sucede, la solicitud de envío tiene que pasar por openQA y debe producir un resultado positivo. Una vez todo va bien, el encargado de Factory podría aceptar el proyecto de transición para que todas las solicitudes de envío que pertenecen a él se chequeen en Factory.
- El Quality Assurance Process (openQA) funciona todo el tiempo. El OBS genera imágenes ISO de forma periódica y se las hace pasar por un conjunto de tests predefinidos. Si se encuentran problemas se crea un informe que recoge los fallos en la citada ISO. En la actualidad, openQA se dedica principalmente al testeo de proyectos de transición y de imágenes de Factory a probar (Factory-To Test).
- Factory-To Test. En el modelo actual de Factory, Factory-To Test representa | el proyecto que almacena varias instantáneas de Factory que son candidatas para la publicación si la calidad fuera suficientemente buena en openQA.
- Proceso de publicación. En base a fechas y a resultados del proceso QA, el encargado de publicaciones puede liberar una milestone o beta. Quién ocupe el puesto en ese momento se hace cargo de las tareas de la publicación: calcula los códigos hash (verificación) MD5/SHA1 de la ISO, configura los repositorios, prepara los servidores espejo (mirrors) semilla, distribuye los productos y avisa a marketing para que comunique la publicación.
- Los tests públicos tienen lugar después de la publicación de una milestone, normalmente en hardware real y en menor medida en máquinas virtuales.
No mucho después de la publicación de la beta (última milestone antes de la congelación total), el equipo de publicación crea una rama separada de Factory para la publicación y usa el proceso de actualizaciones de mantenimiento para estabilizarla.
- Puedes consultar información más detallada sobre el proceso de desarrollo de openSUSE.
- Averiguar más sobre el proceso de publicación aquí.
- Saber qué es qué en el glosario de términos.
Modelo de gobernanza
Las correcciones de fallos y nuevas características deben enviarse primero a un proyecto de desarrollo, y de ahí se redirigen al repositorio principal del proyecto Factory. Por esto, la gobernanza del proyecto Factory también está dividida en partes.
Responsabilidades
| Paquete | Proyecto de desarrollo | Factory |
|---|---|---|
| Encargado y Propietario del fallo | Encargado del proyecto y Propietario del fallo | Equipo de publicaciones |
Vea una lista más detallada de los roles y responsabilidades aquí.
Cadena de decisiones
La mayoría de decisiones las toma el encargado del paquete. Si no puede tomar una decisión, o si surge un conflicto entre mantenedores, los encargados del proyecto de desarrollo deben decidir entre sí. Si no llegan a ninguna conclusión o surge un conflicto entre dos proyectos de desarrollo, el equipo de publicaciones de openSUSE toma la decisión. Si no se puede tomar una decisión por dicho equipo, apelan al Consejo de openSUSE que intenta facilitar la decisión con todas las partes involucradas. Si eso tampoco tiene éxito, el consejo somete el asunto a votación entre los miembros.
Puede leer una información más detallada sobre el proceso de desarrollo de openSUSE/Factory.