Responsabilidades del mantenedor del paquete

Mantenedores de paquetes se encargan de los paquetes en Fedora. Esto incluye tanto el empaquetado del software upstream en los rpms de Fedora como trabajar con upstream para mejorar el software de varias maneras.

¿Cuanto tiempo hay que mantenerlo?

Cada versión de Fedora dura al menos 13 meses hasta que llega al final de su vida útil. Un mantenedor de paquetes es responsable del paquete durante al menos este periodo de tiempo. Consulte Fedora Release Life Cycle para más detalles.

Pertenecer al listado apropiado de correo de tráfico bajo

Los mantenedores de paquetes recibirán anuncios importantes a través del listado devel-announce de correo moderado. Los mantenedores se suscribirán automáticamente a esta lista. Se recomienda encarecidamente a todos los mantenedores principales de paquetes de Fedora que se suscriban al listado devel, aunque no es obligatorio.

Gestionar problemas de seguridad

Los responsables del mantenimiento de los paquetes deben resolver los problemas de seguridad con rapidez y, si necesitan ayuda, deben ponerse en contacto con el Equipo de respuesta de seguridad.

Funcionar con desarrollo

Es recomendado que los mantenedores del paquete trabajen de cerca con los desarrolladores siempre que sea posible. Esto puede incluir:

  • Envíe cualquier cambio a upstream.

  • Participar en el listado de correo de upstream.

  • Obtén una cuenta en los seguimientos de defectos en upstream.

  • Reenvía los defectos severos al desarrollo cuando sea posible para asistencia.

Consulte el Mantenerse cerca de los proyectos anteriores para obtener más información al respecto.

Trabajo con Testeos

Hay muchos lugares en los que los mantenedores de paquetes pueden interactuar con QA para mejorar la calidad de Fedora. Se recomienda que los mantenedores:

  • Al enviar el paquete, proporcione información a QA sobre cómo depurar/triage el paquete, para uso de defectos enviados y triages

  • Proporcione casos de pruebas de funcionalidad general, para utilizar cuando pruebe las regresiones

  • Al enviar la actualización, proporcione casos de prueba para las cosas corregidas en la actualización, para que los evaluadores los utilicen

Tratar con los defectos informados de una manera oportuna

  • Si se encuentra incapaz de manejar la carga de errores de su(s) paquete(s), por favor solicite ayuda en los listados de devel y/o listado de prueba. Enseñar a los triages sobre cómo realizar triages de sus fallos u obtener ayuda de otros mantenedores no sólo puede reducir su carga, sino mejorar Fedora. Considere la posibilidad de solicitar la ayuda de algunos (más) co-mantenedores.

  • Si hay fallos que no eres capaz de arreglar por ti mismo porque tienen que ver con complejidades del código fuente el cual no entiendes del todo, entonces tienes que solucionarlos. Puede ser útil trabajar con el mantenedor del código, obtener ayuda de personas más orientadas al código en fedora-devel, o buscar parches en otras distribuciones. Asegúrese siempre de publicar en el informe de errores lo que ha hecho para que el informador sepa lo que está pasando y qué puede esperar. Se recomienda que los empaquetadores que no sean codificadores encuentren co-mantenedores que estén familiarizados con el lenguaje de programación utilizado por su(s) paquete(s), y que puedan ayudar con estos fallos como una especie de «mantenimiento de segunda línea».

  • Intentar resolver los fallos o asuntos en la versión de la que se han notificado o, si no es posible, explicar a los notificadores por qué su defecto no puede solucionarse en ese lanzamiento

Actualizaciones de paquete

La Normativa de actualización de paquetes ofrece orientación a los mantenedores que actualizan paquetes en cuero crudo, en «versiones ramificadas» y en las ramas «estables» ya publicadas.

En resumen, sin embargo, los mantenedores deben tener en cuenta que:

  • Las versiones irían de menos conservadoras (Rawhide) a más conservadoras (la versión estable mantenida más antigua).

  • Muchos usuarios de Fedora se actualizan automáticamente, por lo que es muy importante que una actualización no provoque que las aplicaciones o el sistema de un usuario dejen de funcionar repentinamente.

  • Los usuarios de Fedora quienes no se actualizan automáticamente pueden revisar las descripciones adjuntadas para las actualizaciones antes de elegir si se aplicarían.

  • No todos los usuarios de Fedora disponen de un buen ancho de banda de Internet y pueden preferir una única actualización con múltiples cambios en lugar de muchas actualizaciones en un periodo de tiempo breve.

Mentoría y supervisión sobre co-mantenedores

Cuando se contrata a un co-mantenedor, se entra en una asociación con él. Ellos pueden trabajar en el paquete, lo que te libera de parte de la carga, pero también tienes que estar preparado para ayudarles y asegurarte que no cometen equivocaciones graves. Por lo tanto, debes estar disponible para responder a las preguntas que puedan tener los co-mantenedores y vigilar los cambios que realicen en el paquete para evitar que surjan problemas de forma inesperada.

La supervisión de los cambios en su paquete también se aplica a los cambios realizados por personas que no son co-mantenedores explícitos si ha abierto su paquete para que cualquier empaquetador realiza un commit con él.

También puede incluir en el grupo de empaquetadores a co-mantenedores que aún no han sido patrocinados, siempre y cuando se comprometa a guiarlos en las formas de empaquetar para Fedora: enseñándoles tanto las herramientas que usamos como los alineamientos de empaquetado que deben seguir. Consulte el enlace Cómo ser patrocinado para más detalles sobre cómo patrocinar a un nuevo empaquetador si usted no es patrocinador.

Cuentas de bot

En el caso de que se utilice un proceso automático en lugar de las acciones normales del mantenedor, deberá utilizarse una cuenta bot independiente. El nombre de la cuenta terminaría en "bot". Los mantenedores que configuren el bot deben crear una página wiki para la cuenta bot (https://fedoraproject.org/wiki/User:<bot>;) con información de contacto para los mantenedores y una explicación de lo que hace el bot. Si las actualizaciones enviadas por el bot causan problemas que requieren atención inmediata, rel-eng puede desactivar la cuenta temporalmente.

Punto de contacto del paquete

El admin principal listado en dist-git es el punto de contacto primario para un paquete y es la persona principalmente responsable para cumplir las responsabilidades listadas en este documento.

Por tanto, [cuentas_bot_] o cualquier grupo u otro usuario que no es registrado a una individuo, persona contable NO DEBE ser listada como admin principal del paquete.

Por defecto las asignaciones de fallo PUEDE ser puesto a un grupo que utiliza la característica anulación del cesionario en dist-git el cuál hace el grupo responsable para los requisitos en [_trato_con_bugs].

Seguimiento de los problemas de dependencia de manera oportuna

En Rawhide, las actualizaciones de paquetes pueden hacer que otros paquetes tengan dependencias rotas. Los mantenedores serán alertados cuando esto ocurra, y deben funcionar para recompilar sus paquetes con la debida prisa. Las dependencias rotas pueden dejar los sistemas de los usuarios finales en un estado en el que no se apliquen actualizaciones. Con el fin de mantener la distribución en un estado razonable, alguien intervendrá y recompilarán los paquetes que han tenido problemas de dependencia durante algún tiempo, pero los mantenedores de paquetes no deben confiar en estas recompilación.

Notificar a otros los cambios que puedan afectar a sus paquetes

Algunos paquetes dependen de otros; en este caso, los cambios en un paquete pueden causar problemas en otros. Los mantenedores deben ser conscientes de los efectos que pueden tener los cambios en sus paquetes, y deben alertar en la lista de correo fedora-devel-announce de las actualizaciones que contengan cambios ABI o API los cuales puedan causar problemas de dependencia para otros paquetes.

El anuncio sucedería una semana antes de la actualización de los paquetes, tal que todos los mantenedores afectados sean notificados. El anuncio incluiría la información siguiente:

  • Naturaleza del cambio.

  • Ramas (Rawhide, F9, etc.) que se verán afectadas por el cambio.

  • Fecha prevista del cambio.

  • Lista de paquetes afectados por el cambio. Generalmente, es simplemente el listado de paquetes que dependen directamente del paquete que está siendo actualizando, y se puede encontrar con repoquery --whatrequires <package> donde <package> es el paquete que se está actualizando.

  • Si la actualización de su paquete rompe otros paquetes en Rawhide, debería intentar ayudar a arreglar los paquetes afectados. Por ejemplo, si eres un provenpackager, pon en cola las recompilaciones tú mismo.

Respetar Planificación

Cada lanzamiento de Fedora tiene una planificaicón que indica, entre otras cosas, las congelaciones como la congelación de cadenas. Cuando se crea un paquete nuevo o se actualiza un paquete existente, debe respetarse la planificación de la versión.

Abandonar Fedora

Todos sabemos que las prioridades cambian a lo largo de la vida. Ver partir a un colaborador valioso nos entristece, pero puede suceder. Antes de marcharse, considere la posibilidad de seguir estos pasos:

  • Anuncia en la lista de correo devel que te vas, junto con la lista de paquetes que quedarán huérfanos.

  • Si alguien muestra interés en adoptar alguno de tus paquetes, dáselo.

  • Deja huérfanos todos los paquetes en los que seas el administrador principal, para que otra persona pueda hacerse cargo de ellos.

  • Abandona el grupo packager (busca el botón «Abandonar grupo» bajo la lista de patrocinadores).

Artículos Varios

  • Los mantenedores deben mantener una ruta de mejora para sus paquetes.

    F(actual-1) → F(actual) → Rawhide

  • Los paquetes deben enviarse primero a la rama Rawhide. Si se construye y funciona bien durante unos días, entonces puede ser empujado a F(current). Si hay una buena razón para empujarlo a F(current-1), se debe hacer después de unos días de estar en F(current).

  • Cuando se publica un paquete nuevo en una rama estable, en la mayoría de los casos debe enviarse primero al repositorio de pruebas.

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