Normativa de no responsabilidad del mantenedor

Propósito

El propósito de esta normativa es proporcionar un mecanismo interno a Fedora para manipular situaciones cuando un mantenedor de paquete se vuelve incapaz de continuar el mantenimiento, a menudo referenciado como «no-responsable». El objetivo final es ayudar a prevenir que los paquetes se vuelvan obsoletos a través del no mantenimiento, reduce problemas abiertos en paquetes sin mantenimientos, e incrementando la calidad general de Fedora.

Cobertura

Esta directiva cubre los paquetes, contenedores y módulos existentes de Fedora. Para quienes envían o revisan paquetes que no responden, consulte la Normativa para revisiones de paquetes estancadas. Si no colabora con Fedora, también puede seguir este procedimiento. Si desea asumir el mantenimiento, debe encontrar un patrocinador siguiendo las reglas especificadas en Cómo obtener patrocinio para el grupo de empaquetadores.

Pasos

Cuándo un miembro de Fedora nota que un mantenedor no está respondiendo a sus fallos, sin responder a peticiones de recompilación, solicite peticiones en src.fedoraproject.org para solicitudes, correos-e, tiene una dirección de correo-e no válida o la cuenta de Bugzilla desactivada puesta en FAS, como p.e. estos pasos estarían siguiendo:

Semana 0

  1. Comprobar si el mantenedor que no responde se encuentra en vacaciones. Para ver si el mantenedor ha sido activo recientemente en Fedora, puede ser utilizado el fedora-active-user.

  2. Envíe un defecto nuevo trente al paquete en Bugzilla pidiendo al mantenedor que responda utilizando una plantilla apropiada y llenar en todos los campos (plantilla para mantenedor de paquete no respondible o paquete sin mantenedor responsable. Si la dirección del correo-e del mantenedor o la cuenta de Bugzilla están inactivas, este paso puede ser omitido.

  3. Publicar en el listado de desarrollo de Fedora con un enlace al informe de fallo (si aplicable) y solicitar si cualquiera sabe como contactar con el mantenedor. CC al mantenedor a no ser que la dirección de correo-e del mantenedor es conocida que no sea válida. Los enlaces a todos otros informes de fallo se abren encima de todos los paquetes desatendidos del mismo mantenedor estaría incluido.

Semana 1

  1. After 7 days, submit a FESCo issue with the bug link and mailing list post link. State if you are a packager and want to take over the nonresponsive maintainer’s package or packages. The non-responsive maintainer and all existing maintainers must be @-mentioned in the ticket. This ticket MAY be filed at the same time as the devel post is sent in which case the FESCo voting period will start 7 days after the devel post was sent.

  2. Si al menos uno FESCo el miembro vota +1 y nadie vota de manera diferente, la entrada está aprobada tras tres días. Si cualquiera de los votos -1 o 0 hechos, FESCo discutirá sobre el asunto durante una reunión. Esta normativa de voto es más sencilla intencionadamente que la normativa de voto#ticket-votes habitual.

  3. Si se aprobó, y el informante es un empaquetador actual de Fedora en estado bueno, interesado en co-mantenedor del paquete, FESCo por defecto añadirá al informante como el paquete admin. Si el co-empaquetador existente del paquete no desea que el paquete sera reasignado al informante, se mantendría tal en el ticket. Si asignó la propiedad, el informante ahora puede realizar cualquier mantenimiento del paquete requerido.

Semana 2

  1. Una semana posterior de FESCo publica un recordatorio en el ticket, @-mencionando el mantenedor.

Semana 3

  1. Sin ninguna réplica más para el propietario original, FESCo cierra su ticket y el ticket de bugzilla. Si fue solicitado el mantenimiento en el ticket FESCo, el reportador será asignado como el mantenedor principal del paquete, y el paquete estará huérfano en otro caso. Todos otros paquetes también están huérfanos, y puede ser tomados por co-mantenedor u otro de los empaquetadores. El propietario original es retirado como co-mantenedor (admin/commit/ticket access) o "vigilante" desde todos los demás paquetes.

Una vez que suceda reasignación final, el propietario nuevo además debe reasignar todos los fallos abiertos para este paquete para sí mismo.

Notas para mantenedores

Se entiende que los mantenedores se irán en vacaciones o en otro caso estén indisponibles para periodos posiblementes significativos de tiempo. Hay un par de cosas que los mantenedores tendrían que considerar hacer si saben por adelantado que no estarán disponibles;

  • Designar un co-mantenedor. En general, es mejor por cada paquete tener múltiples mantenedores. Los co-mantenedores pueden ser añadidos en la pestaña Ajustes del paquete en dist-git.

  • Editar la página de Vacaciones para indicar cuando estarás ausente.

Direcciones de correo-e no válidas

Bugzilla utiliza la dirección de correo-e en el Sistema de Cuenta de la Fedora para enviar mensajes al mantenedor del paquete. Si pasa a concederse que esta dirección de correo electrónico ya no va al mantenedor del paquete, la incidencia con la dirección de correo electrónico tendría que ser notado en el listado de publicación del correo y el ticket de FESCo. En este caso, el requerimiento para archivo un mantenedor no responsable del fallo de Bugzilla es esperado pero el requerimiento para enviar un correo al listado de desarrollo permanece.

Situaciones donde de vuelve conocido que una dirección de correo-e no está más yendo al mantenedor es:

  1. El correo-e para la dirección rebota con un error de usuario nulo (tal como Dirección del destinatario rechazada: usuario desconocido en tabla de destinatarios locales).

  2. El proveedor o la empresa asociada con la dirección, de lo contrario comunica que la dirección no es válida.

  3. El correo electrónico enviado a esa dirección rebota por otro motivo (para diferenciar desde rebotes temporalmente como un buzón lleno, esto iría para un periodo de 7 días).

En el caso especial donde una cuenta no tiene una dirección de correo-e válida conectada en bugzilla, y no mantienen ningunos paquetes y no es parte del grupo packager, puede ser abandonado desde el paquete "watchers" inmediatamente.

Procedimiento de excepción

Hay algunos casos donde puede ser necesario reasignar un paquete incluso si este procedimiento no ha sido finalizado aún. Ejemplos incluyen cunado muchas dependencias están rotas, las actualizaciones de versiones son necesarias para tazones de seguridad o estabilidad, o mantenedor responde prevenir proceso no responsable desde procedimiento sin resumir actualmente el mantenimiento.

Pasos:

  1. Explica por qué el proceso de excepción es necesario y note todos los intentos de comunicación en un correo-e al listado devel@lists.fedoraproject.org con el mantenedor no responsable del CC en el correo-e.

  2. Abra el ticket de FESCo descrito en el paso 4 sin esperar una semana y también describir la situación allí.

Proceso huérfano

A no ser que haya una razón no al (correo del mantenedor está acotado, el mantenedor ha dicho a alguien que no está interesado en continuar el mantenimiento de paquetes de Fedora) haremos el mantenedor un co-mantenedor en el paquete en todas las ramificaciones estuviera un propietario. Entonces los paquetes estarán huérfanos.

Si el correo-e del mantenedor es rebotado o hemos estado diciendo que el mantenedor no está interesado en continuar la contribución de Fedora retiraremos todos los acls del mantenedor.

Alternativo: Proceso de solicitud ligero y estancado para otros empaquetadores

El proceso de mantenimiento que no responde es una tarea seria y, si es logrado, da como resultado que los paquetes en los que el mantenedor es el administrador principal queden huérfanos; como se indica en el [procedimiento de excepción], una respuesta del mantenedor también interrumpe este proceso.

Prerequisitos

  1. Serías un empaquetador de Fedora patrocinado.

  2. Estaría dispuesto a co-mantener el paquete en cuestión. Esto no sería utilizado para contribuciones de conductor.

Semana 0

  1. Envía un defecto nuevo respecto al paquete en Bugzilla, con una solicitud enlazada si es aplicable (esto quizá no es necesario si está solicitando una rama EPEL y una rama existente compila bien, en la cual caso proporcione, por favor, alguna evidencia p.e. resultado de compilación incorrecto.

Semana 1

  1. Tras los 7 días, hacer ping al defecto, NEEDINFO al asignado y solicitar una respuesta.

Semana 3

  1. Tras otros 14 días sin ninguna acción, entregar un ticket releng solicitando efectuar permisos para co‐mantener el paquete. El mantenedor no-responsive y todos los mantenedores existentes deben ser @-mentioned en el ticket. Si la petición es para el propósito de una rama EPEL, también el estado que está deseando ser hecho en el EPEL predeterminado del apoderado del bugzilla EPEL.

    Esta etiqueta releng debe ser aprobada con un voto +1 por al menos un miembro FESCo (distinto del creador de petición, si también un miembro FESCo). Tan pronto como suceda y mientras hay sólo +1 votos, la etiqueta está considerada aprobada. Si hay cualquiera otros votos (0 o -1), FESCo seguirá su habitual normativa de voto para aprobar o rehusar la etiqueta.

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