Chi è autorizzato a modificare quali pacchetti

Con l’attuale struttura di Git, ogni membro del gruppo provenpackager può modificare la maggior parte dei pacchetti. In via eccezionale, alcuni pacchetti specifici possono essere resi inaccessibili ai provenpackager, previa approvazione del FESCo.

Digest

Normally the maintainer that is listed as primary maintainer in the dist-git repository of a package is the only one who modifies the package or gives others permission (e.g. by accepting them as co-maintainers) to commit and build changes for that package. Bugzilla or repository’s pull requests are normally the best way to contact the package maintainer or to send them patches and suggestions because they are neutral and trackable; but poking people once or twice in IRC or directly via mail might be a good idea.

Esistono tuttavia alcune eccezioni in cui i manutentori devono accettare che altri responsabili dei pacchetti modifichino i pacchetti di cui sono responsabili. Tali eccezioni sono descritte in dettaglio di seguito. In sostanza, si riducono a quanto segue: in uno qualsiasi dei seguenti casi, i [provenpackagers] sono autorizzati ad apportare correzioni ai pacchetti di altri:

  • un responsabile del packaging non risolve per tempo i bug più gravi

  • sono noti alcuni problemi che potrebbero avere ripercussioni negative sull’intero progetto o su molti utenti del repository o di un determinato pacchetto

  • le modifiche sono piuttosto minori o vanno intese come una pulizia generale di molti pacchetti

  • le modifiche rientrano in un obiettivo di Fedora, con un piano specifico approvato dal FESCo

Dettagli

Questa sezione cercherà di spiegare le regole sopracitate in modo più dettagliato. Non sarà mai possibile coprire ogni singola situazione che potrebbe presentarsi in Fedora, ma dovrebbe fornire a tutti un’idea di come applicare le suddette regole.

"Problemi non gestiti"

"I manutentori dovrebbero monitorare i pacchetti di cui sono responsabili. Ciò significa:

  • Rispondi ai bug segnalati su Bugzilla, specialmente con rapidità se si tratta di problemi gravi come le falle di sicurezza

  • Correggi i problemi senza aspettare una richiesta esplicita se questi sono già menzionati all’interno delle segnalazioni d’errore — questo include:

    • correggere i problemi relativi a EVR (Epoch:Version-Release) quando vengono segnalati nei rapporti sulle anomalie (ad esempio, un percorso di aggiornamento interrotto)

    • correggere i problemi di dipendenze (inclusi quelli nel repository devel) — lo script invia le segnalazioni dei problemi sia al manutentore che alla lista

    • "partecipare ai mass-rebuild (ricompilazioni di massa) e correggere i bug di tipo Fails to Build from Source (Errore di compilazione dai sorgenti)"

  • "aggiornare alle nuove versioni del software non appena diventano disponibili a monte (upstream), seguendo le linee guida per gli aggiornamenti"

"Se il manutentore non tiene traccia di questi elementi, allora altri manutentori esperti sono liberi di correggere i problemi al suo posto. È impossibile stabilire un arco di tempo entro il quale un collaboratore debba farsi avanti per risolvere le criticità, poiché ciò dipende dalla gravità del problema che necessita di una correzione. Tuttavia, ecco alcuni esempi:"

  • "problemi di sicurezza:"

    • "Le questioni importanti dovrebbero essere risolte il più rapidamente possibile" — "attendere un giorno che il manutentore si faccia vivo" "e intervenire per risolvere un problema segnalato è considerato più che sufficiente; potrebbero persino esserci situazioni in cui i problemi devono essere risolti più rapidamente"

    • "anche i problemi non così prioritari dovrebbero essere affrontati tempestivamente" — "Aspettare da 2 a 7 giorni (a seconda della gravità del problema) è considerato sufficiente."

  • "Bug che necessitano di un trattamento simile ai problemi di sicurezza:

    • "Le criticità importanti (come la corruzione dei dati per gli utenti) dovrebbero essere risolte il più rapidamente possibile." — "Anche in questo caso, l’attesa di un giorno è considerata più che sufficiente."

    • "Bug dannosi, ma non così gravi, che potrebbero comunque danneggiare gli utenti." — "Un’attesa di 2-14 giorni (a seconda della gravità del problema) è considerata sufficiente."

    • "Bug fastidiosi, ma non così dannosi" — "Un’attesa di 21 giorni è considerata sufficiente"

"Alcune note:

  • "Se un pacchettizzatore rimane offline per periodi prolungati (ad esempio cinque giorni o più) a causa di vacanze, viaggi o altri motivi, può comunicarlo sul calendario delle vacanze. In questo caso, gli altri sapranno di non dover aspettare una risposta prima del suo ritorno e potranno procedere immediatamente a risolvere eventuali problemi (ad esempio, se è necessario applicare una correzione di sicurezza).

  • "'Unhandled' (non gestito) significa effettivamente 'completamente non gestito'." — "se il manutentore ha risposto una volta in una segnalazione di bug (bug report)," "…​ma poi non si sono più fatti sentire; prova a ricontattarli, forse si sono semplicemente dimenticati di questo bug. Oppure potrebbe esserci una buona ragione per cui non hanno ancora applicato la correzione fornita.

  • Se hai effettuato dei commit su un altro pacchetto, aspetta alcune ore se possibile (normalmente 24 o 48) prima di procedere effettivamente con la build del pacchetto aggiornato, a meno che non si tratti di qualcosa di grave che debba essere risolto rapidamente (problemi di sicurezza, ecc.). Questo lascia al manutentore il tempo di "svegliarsi" (ovvero di accorgersi delle modifiche).

  • I manutentori esperti dovrebbero limitare le modifiche ai pacchetti altrui a interventi ampiamente concordati. In altre parole, non bisogna correggere elementi considerati controversi o che riguardano puramente lo stile personale.

Modifiche minori, generali o di pulizia

A volte vi sono situazioni in cui è semplicemente molto più facile correggere le cose direttamente su Git anziché tramite Bugzilla e i manutentori ufficiali. È talmente più semplice che dovremmo lasciare aperta questa strada. Queste situazioni non dovrebbero presentarsi spesso. Alcuni esempi di casi in cui aggirare il manutentore ufficiale è considerato accettabile:

  • Supporto per una nuova architettura — che spesso richiede che molti pacchetti richiedono aggiustamenti o patch che spesso i pacchettizzatori non possono nemmeno testare autonomamente. Gestire tutte queste modifiche tramite Bugzilla è un lavoro lungo e tediante; pertanto, questi problemi possono essere risolti direttamente in Rawhide senza contattare i singoli manutentori, a patto che l’iniziativa generale sia stata annunciata in precedenza. Un SIG dovrebbe gestire queste operazioni e riprendere le normali attività una volta terminati gli sforzi iniziali di porting.

  • piccole correzioni o adattamenti relativi a linee guida di pacchettizzazione nuove o modificate possono essere eseguiti direttamente in Git, previa comunicazione con alcuni giorni di anticipo.

  • Ricompilazioni di massa.

Modifiche per gli Obiettivi di Fedora

A volte, potremmo voler apportare grandi cambiamenti che vanno oltre la semplice pulizia, a sostegno di un Obiettivo di Fedora (Fedora Objective) approvato dal Council. Questi cambiamenti saranno più facili da realizzare se coordinati piuttosto che gestiti individualmente. In queste situazioni, il FESCo discuterà un piano, includendo l’ambito delle modifiche, e lo comunicherà tramite la mailing list devel.

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