The wikis are now using the new authentication system.
If you did not migrate your account yet, visit https://idp-portal-info.suse.com/

openSUSE:Modelo de desarrollo de Factory

Saltar a: navegaci贸n, buscar

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.

Knotes 128x128.png

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.

Factory workflow 2014.png

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铆.

Factory submississions 2014.png

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:
    1. Factory-Auto: un script que comprueba las reglas b谩sicas [10]
    2. Legal-Auto: un script que comprueba si la licencia del paquete est谩 en la base de datos de las permitidas [10]
    3. Repo-Checker: una comprobaci贸n autom谩tica m谩s en profundidad (y lenta) [10]
    4. Equipo de revisi贸n: comprobaci贸n por personas de la solicitud
    5. 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.

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.

Encargado 鉄 Encargados del proyecto de desarrollo 鉄 Equipo de publicacionesConsejo 鉄 Votaci贸n de los miembros de openSUSE

Puede leer una informaci贸n m谩s detallada sobre el proceso de desarrollo de openSUSE/Factory.

Ver tambi茅n