Quién está concedido para modificar cuales paquetes

Con la disposición actual de Git, cada miembro del grupo normativa de empaquetador puede modificar la mayoría de los paquetes. Como una excepción, algunos paquetes específicos pueden cerrarse a los proveedor de paquetes, previa aprobación de FESCo.

Resumen

Normalmente el mantenedor que aparece como mantenedor principal en repositorio dist-git de un paquete es el único que modifica el paquete o da permiso a otros (por ejemplo, aceptándolos como co-mantenedores) para confirmar y construir cambios para ese paquete. Bugzilla o los pull requests del repositorio son normalmente la mejor forma de contactar con el mantenedor del paquete o de enviarle parches y sugerencias porque son neutrales y trazables; pero pinchar a la gente una o dos veces en IRC o directamente por correo puede ser una buena idea.

Pero hay ciertas excepciones en las que los mantenedores deben aceptar que otros empaquetadores modifiquen los paquetes de los que son responsables. Estas excepciones se describen con detalle a continuación. La mayoría se reducen a esto: En cualquiera de los siguientes casos, los provenpackagers están autorizados para reparar material en otros paquetes ajenos:

  • un empaquetador no corrige defectos importantes a tiempo

  • hay problemas conocidos que quizá sean perjudiciales para todo el Proyecto o para muchos usuarios del repositorio/paquete particular

  • los cambios son bastante menores o se consideran una purga general de un montón de paquetes

  • los cambios forman parte de un Objetivo Fedora, con un plan específico aprobado por FESCo

Detalles

Esta sección intentará explicar las reglas anteriores con más detalle. Nunca será capaz de cubrir todas las cosas que puedan surgir en Fedora, pero proporcionaría a cada uno alguna idea de cómo desplegar las reglas anteriores.

Asuntos sin resolver

Los empaquetadores llevarían un seguimiento de mantenimiento de los paquetes para los cuales son responsables. Es decir:

  • responder a los defectos reportados en el bugzilla, especialmente rápido si se trata de un problema grave, como un asunto de seguridad

  • repara asuntos sin ocuparse explícitamente si está mencionado en algún lugar de los informes del problema — que incluye:

    • rapara problemas de EVR, cuando se mencionan en los informes del problema (por ejemplo, una ruta de versión nueva rota)

    • solucionar asuntos de dependencia (aquellos incluidos en el repo devel) — el guion envía los problemas a ambos mantenedor y el listado

    • participe en recompilaciones masivas y repara defectos en Fallos para Compilar desde la Fuente

  • actualiza a las versiones de software a medida que estén disponibles, siguiendo la normativa de actualizaciones

Si el empaquetador no hace un seguimiento de esos elementos, otros empaquetadores experimentados pueden arreglar cosas por ellos. Es imposible establecer un plazo en el que un colaborador deba dar un paso al frente para arreglar cosas, porque eso depende de la gravedad del problema que haya que arreglar. Pero hay algunos ejemplos:

  • problemas de seguridad:

    • Las cosas importantes serían marcadas como rápidamente si es posible — esperando un día a que aparezca el mantenedor e intervenir para solucionar un asunto del que se les ha informado se considera más que suficiente; incluso puede haber situaciones donde los asuntos requieren solucionarse con mayor rapidez.

    • no es que los problemas importantes deberían tratarse con rapidez, también — esperar de 2 a 7 días (dependiendo de la gravedad del asunto) se considera suficiente

  • defectos que necesitan un tratamiento similar al de los problemas de seguridad:

    • El material importante (corrupción de datos para usuarios) estarían solucionados lo antes posible. — esperando también un día es considerado más que suficiente aquí

    • bichos dañinos, pero no tan malos que puedan perjudicar a los usuarios — esperar de 2 a 14 días (dependiendo de la gravedad del asunto) se considera suficiente

    • irritante, pero no como esos bichos tan dañinos — esperar 21 días se considera suficiente

Algunas notas:

  • Si un empaquetador está fuera de línea durante períodos más largos (por ejemplo, cinco días o más) debido a vacaciones, viajes u otros problemas, puede anunciarlo en calendario de vacaciones. En este caso, los demás saben que no deben esperar una respuesta antes de que el empaquetador regrese y pueden proceder inmediatamente a arreglar las cosas (p.e. si es necesario aplicar una corrección de seguridad).

  • No manipulado actualmente realmente significa completamente no manipulado — si el mantenedor respondió una vez en un informe de fallo, pero luego se quedó en silencio, inténtalo de nuevo, puede que se hayan olvidado de este fallo. O puede que haya alguna buena razón por la que aún no hayan confirmado la corrección.

  • Si ha realizado cambios en otro paquete, espere algunas horas si es posible (normalmente 24 o 48) antes de compilar el paquete actualizado, siempre que no se trate de nada grave que deba solucionarse rápidamente (problemas de seguridad, …​). Eso deja algo de tiempo para que el mantenedor se despierte.

  • Los empaquetadores experimentados limitarían sus cambios a otros paquetes de otras personas a cosas que estén bien consensuadas. Es decir, no arreglar cosas que se consideren controvertidas o una cuestión de estilo.

Cambios menores, generales o de purga

A veces hay situaciones en las que simplemente es mucho más fácil arreglar cosas directamente en Git que a través de bugzilla y los mantenedores adecuados. Tanto más fácil que deberíamos dejar esta vía abierta. Estas situaciones no deberían darse tan a menudo. Algunos ejemplos de situaciones en las que eludir el mantenimiento adecuado se considera correcto:

  • mantenimiento para una arquitectura nueva — que a menudo requiere que muchos paquetes necesitan ajustes o parches que los empaquetadores a menudo ni siquiera pueden probar ellos mismos. Introducir todas esas modificaciones a través de bugzilla es mucho trabajo molesto, así que estas cosas pueden arreglarse directamente en rawhide sin contactar con los mantenedores individuales si el esfuerzo general se anuncia de antemano. Un SIG se encargaría de estas cosas y continuar con las operaciones normales una vez finalizados los esfuerzos iniciales de portabilidad.

  • las pequeñas correcciones o ajustes de directrices de empaquetado de nuevas o modificadas pueden hacerse directamente en Git tras anunciarse con algunos días de antelación.

  • recompilaciones masivas.

Cambios para los Objetivos de Fedora

A veces, es posible que queramos hacer grandes cambios que vayan más allá de la purga, en mantenimiento de un Consejo Objetivo Fedora aprobado. Estos cambios serán más fáciles de hacer en coordinación que individualmente. En estas situaciones, FESCo debatirá un plan que incluya el ámbito de los cambios y lo comunicará a través del listado de desarrollo.

Want to help? Learn how to contribute to Fedora Docs ›