Politica sui repository di terze parti

Scopo

Lo scopo di questa politica è quello di fornire un meccanismo all’interno di Fedora per gestire le situazioni in cui un responsabile di un pacchetto non è più in grado di continuare a occuparsene, spesso definito come “non rispondente”. L’obiettivo finale è quello di contribuire a evitare che i pacchetti diventino obsoleti a causa della mancata manutenzione, ridurre il numero di bug aperti relativi a pacchetti non mantenuti e migliorare la qualità complessiva di Fedora.

Copertura

Questa politica riguarda i pacchetti, i container e i moduli Fedora esistenti; per i segnalatori o i revisori di pacchetti che non rispondono, consultare Politica per le revisioni di pacchetti in stallo. Se non sei già un collaboratore di Fedora, puoi seguire questa procedura. Se desideri assumere il ruolo di manutentore, devi trovare uno sponsor seguendo le regole specificate in Come ottenere la sponsorizzazione nel gruppo dei packager.

Passi

When a Fedora member notices that a maintainer isn’t answering their bugs, not answering rebuild requests, src.fedoraproject.org pull requests, emails, has an invalid email address or deactivated Bugzilla account set in FAS, or the like, these steps should be followed:

Settimana 0

  1. Check if the non-responsive maintainer is on vacation. To see if the maintainer has been recently active on Fedora, fedora-active-user can be employed.

  2. File a new bug against the package in Bugzilla asking for the maintainer to respond using an appropriate template and fill in all the fields (template for nonresponsive package maintainer or nonresponsive container maintainer. If the maintainer’s email address or Bugzilla account are inactive, this step can be skipped.

  3. Post to the Fedora devel list with a link to the bug report (if applicable) and ask if anyone knows how to contact the maintainer. CC the maintainer unless the maintainer’s email address is known to be invalid. Links to all other bug reports open on all neglected packages from the same maintainer should be included.

"Settimana 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. Se almeno un membro di FESCo vota +1 e nessuno vota in modo diverso, il ticket viene approvato dopo tre giorni. Se viene espresso anche un solo voto -1 o 0, FESCo discuterà la questione durante una riunione. Questa policy di voto è intenzionalmente più semplice rispetto alla consueta policy di voto per i ticket.

  3. Se la richiesta viene approvata, e il segnalatore è un attuale manutentore (packager) di Fedora in regola che sia interessato alla co-manutenzione, FESCo procederà di norma ad aggiungerlo come amministratore del pacchetto (package admin). Qualora gli attuali co-manutentori non desiderino che il pacchetto venga riassegnato al segnalatore, dovranno dichiararlo esplicitamente nel ticket. Una volta ottenuta la proprietà del pacchetto, il segnalatore potrà eseguire ogni operazione di manutenzione necessaria.

Settimana 2

  1. Una settimana dopo, il FESCo pubblica un promemoria nel ticket, menzionando il manutentore con una @-mention.

Settimana 3

  1. Senza ulteriori risposte da parte del proprietario originale, il FESCo chiude il proprio ticket e il ticket su Bugzilla. Se nel ticket del FESCo era stata richiesta la gestione del pacchetto, il segnalatore verrà assegnato come manutentore principale; in caso contrario, il pacchetto verrà reso orfano. Anche tutti gli altri pacchetti vengono resi orfani e potranno essere presi in carico da co-manutentori o altri packager. Il proprietario originale viene rimosso come co-manutentore (accesso admin/commit/ticket) o come "watcher" da tutti gli altri pacchetti.

"Una volta avvenuta la riassegnazione finale, il nuovo proprietario deve anche riassegnare a se stesso tutti i bug aperti relativi a questo pacchetto.

"Note per i manutentori"

"Resta inteso che i manutentori possano andare in vacanza o risultare non disponibili per periodi di tempo potenzialmente significativi. Ci sono alcune precauzioni che i manutentori dovrebbero considerare di adottare qualora sappiano in anticipo di non poter essere reperibili:"

  • "Designa un co-manutentore. In generale, è preferibile che ogni pacchetto abbia più manutentori. I co-manutentori possono essere aggiunti nella scheda 'Settings' (Impostazioni) del pacchetto su dist-git.

  • "Modifica la pagina 'Vacation' per indicare quando sarai assente.

indirizzo email non valido

Bugzilla uses the email address in the Fedora Account System to send messages to the package maintainer. If it becomes known that this email address no longer goes to the package maintainer, the issue with the email address should be noted in the mailing list post and FESCo ticket. In this case, the requirement to file a nonresponsive maintainer Bugzilla bug is waived but the requirement to send a devel list post remains.

"Le situazioni in cui si viene a sapere che un indirizzo email non raggiunge più il manutentore sono:

  1. Email to the address bounces with an invalid user error (such as Recipient address rejected: User unknown in local recipient table).

  2. The provider or company associated with the address otherwise communicates that the address is invalid.

  3. Email to the address bounces for another reason (to differentiate from temporary bounces like a mailbox full, this should go on for a period of 7 days).

"Nel caso speciale in cui un account non abbia un indirizzo email valido collegato in Bugzilla, non gestisca alcun pacchetto e non faccia parte del gruppo packager, può essere rimosso immediatamente dai "watchers" (osservatori) del pacchetto."

Procedura di eccezione

"Esistono alcuni casi in cui potrebbe essere necessario riassegnare un pacchetto anche se questa procedura non è ancora giunta al termine. Gli esempi includono situazioni in cui molte dipendenze risultano rotte, quando sono necessari aggiornamenti di versione per motivi di sicurezza o stabilità, oppure quando la risposta del manutentore impedisce alla procedura di 'non-responsività' di proseguire senza che venga effettivamente ripresa la manutenzione. In tali casi, è possibile utilizzare questa procedura di eccezione."

Passi:

  1. "Spiega perché è necessario il processo di eccezione e annota tutti i tentativi di comunicazione in un’email indirizzata alla mailing list devel@lists.fedoraproject.org, mettendo in copia conoscenza (CC) il manutentore che non risponde.

  2. "Apri il ticket FESCo descritto al punto 4 senza attendere una settimana e descrivi lì la situazione."

"Processo di orfanizzazione

"A meno che non vi sia una ragione contraria (l’email del manutentore risulta non consegnabile, o il manutentore ha comunicato di non essere più interessato a gestire i pacchetti Fedora), aggiungeremo il manutentore come co-manutentore del pacchetto in tutti i rami di cui era proprietario. Successivamente, i pacchetti verranno resi 'orphan' (orfani).

Esatto, la traduzione è corretta. Se stai traducendo della documentazione tecnica o delle linee guida (come quelle del progetto Fedora che abbiamo visto finora), potresti anche adattarla leggermente a seconda del resto della frase.

"Alternativa: Procedura semplificata per richieste in sospeso da parte di altri pacchettizzatori"

La procedura per i manutentori non reattivi è un impegno serio e, se portata a termine con successo, comporta l’abbandono (orphaning) dei pacchetti di cui il manutentore è l’amministratore principale; come indicato nella [procedura-eccezioni], la risposta di un manutentore interrompe tale processo.

Prerequisiti

  1. Devi essere un manutentore di pacchetti Fedora già garantito (sponsored).

  2. Dovresti essere disposto a co-mantenere il pacchetto in questione. Questa opportunità non deve essere utilizzata per contributi occasionali e fugaci (drive-by contributions).

Settimana 0

  1. Apri un nuovo bug per il pacchetto in Bugzilla, includendo un link alla pull request se pertinente (questo potrebbe non essere necessario se stai richiedendo un ramo EPEL e un ramo esistente viene compilato correttamente; in tal caso, fornisci una prova, ad esempio il risultato di una scratch build).

"Settimana 1"

  1. Dopo 7 giorni, invia un sollecito sul bug (ping), imposta lo stato in NEEDINFO per l’assegnatario e richiedi una risposta.

Settimana 3

  1. After another 14 days with no action, submit a releng ticket requesting commit permissions in order to co-maintain the package. The non-responsive maintainer and all existing maintainers must be @-mentioned in the ticket. If the request is for the purpose of an EPEL branch, also state that you are willing to be made the default EPEL bugzilla assignee.

    This releng ticket must be approved with a +1 vote by at least one FESCo member (other than the request creator, if also a FESCo member). As soon as that happens and as long as there are only +1 votes, the ticket is considered approved. If there are any other votes (0 or -1), FESCo will follow its usual voting policy to approve or reject the ticket.

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