Capitolo 3. Doveri di un Debian Developer

Indice

3.1. Doveri di un maintainer di pacchetti
3.1.1. Lavorare per il prossimo rilascio stable
3.1.2. Mantenere i pacchetti in stable
3.1.3. Gestire i bug critici per il rilascio
3.1.4. Coordinamento con gli sviluppatori originali
3.2. Doveri amministrativi
3.2.1. Gestire le vostre informazioni Debian
3.2.2. Mantenere la vostra chiave pubblica
3.2.3. Votare
3.2.4. Andare in vacanza con garbo
3.2.5. Congedarsi
3.2.6. Ritornare dopo il congedo

Come un maintainer di un pacchetto, si suppone che si forniranno pacchetti di alta qualità che siano ben integrati nel sistema e che aderiscano alla Policy di Debian.

Fornire pacchetti di alta qualità in unstable non è abbastanza, la maggior parte degli utenti beneficeranno dei vostri pacchetti solo quando sono rilasciati come parte del prossimo rilascio stable. Si è quindi tenuti a collaborare con il gruppo di rilascio per essere sicuri che i vostri pacchetti vengano inclusi.

Più concretamente, si dovrà controllare che i pacchetti stiano migrando verso testing (si consulti Sezione 5.13, «La distribuzione testing»). Quando la migrazione non avviene dopo il periodo di prova, si deve analizzare il motivo e lavorare per correggerlo. Potrebbe significare correggere il pacchetto (nel caso dei bug critici per il rilascio o di fallimenti nella compilazione su alcune architetture), ma potrebbe anche significare l'aggiornamento (o di correzione, o di rimozione da testing) di altri pacchetti per aiutare il completamento di una transizione in cui il proprio pacchetto è incastrato a causa delle sue dipendenze. Il team di rilascio potrebbe fornire alcuni input sugli attuali blocchi di una data transizione, se non si è in grado di identificarli.

In generale si dovrebbe affrontare le segnalazioni di bug sui propri pacchetti come è descritto in Sezione 5.8, «Gestione dei bug». Tuttavia, c'è una categoria speciale di bug di cui vi dovrete prendere cura - i cosiddetti bug critici per il rilascio (RC bug). Tutte le segnalazioni di bug che hanno gravità critical, grave o serious rendono il pacchetto non adatto per l'inclusione nel prossimo rilascio stable. Quindi possono ritardare il rilascio di Debian (quando riguardano un pacchetto in testing) o bloccare migrazioni in testing (quando influiscono solo sul pacchetto in unstable). Nello scenario peggiore, procederanno alla rimozione del pacchetto. Ecco perché questi bug devono essere corretti al più presto.

Se, per qualsiasi motivo, non potete risolvere un bug RC in uno dei vostri pacchetti entro 2 settimane (per esempio a causa di vincoli di tempo, o perché è difficile da correggere), si dovrebbe accennarlo chiaramente nel bug report e si dovrebbe contrassegnare il bug come help in modo da invitare altri volontari a partecipare alla sua risoluzione. Si sia consapevoli che i bug RC sono spesso bersaglio di Non-Maintainer Uploads (si consulti Sezione 5.11, «Caricamenti dei Non-Maintainer (NMU)») perché in grado di bloccare la migrazione in testing di molti pacchetti.

La mancanza di attenzione per i bug RC è spesso interpretata dal team QA come un segno che il maintainer è scomparso senza aver correttamente reso orfano il suo pacchetto. Il team MIA potrebbe anche mettersi in gioco, che potrebbe concretizzarsi nel rendere orfani i vostri pacchetti (si consulti Sezione 7.4, «Rapportarsi con maintainer non attivi e/o non raggiungibili»).

Grande parte del proprio lavoro come maintainer Debian sarà quello di restare in contatto con gli sviluppatori originali. Gli utenti Debian a volte segnaleranno al nostro sistema di bug-tracking bug che non sono specifici di Debian. Dovrete inoltrare tali segnalazioni di bug agli sviluppatori originali in modo che possano essere corrette in una futura versione originale.

Anche se non è il proprio lavoro correggere i bug specifici non-Debian, si può liberamente farlo se ne si ha la possibilità. Quando si effettuano queste correzioni, ci si assicuri di trasmetterle anche ai maintainer originali. Utenti e sviluppatori Debian a volte invieranno patch che correggono bug dei sorgenti originali: si dovrebbe valutare e trasmettere queste patch allo sviluppatore originale.

Se si necessita di modificare i sorgenti originali al fine di costruire un pacchetto conforme alla policy, allora si dovrebbe proporre una soluzione accurata agli sviluppatori originali che può essere li applicata, in modo da non dover modificare i sorgenti della prossima versione originale. Qualunque cambiamento necessiti, cerca sempre di non effettuare il fork dai sorgenti originali.

Se si scopre che gli sviluppatori originali sono o diventano ostili verso Debian o la comunità del software libero, si potrebbe riconsiderare la necessità di includere il software in Debian. A volte il costo sociale per la comunità Debian non vale i benefici che il software può portare.

Un progetto delle dimensioni di Debian si basa su alcune infrastrutture amministrative per tenere traccia di tutto. Come membro del progetto, si hanno alcuni doveri che assicurano che il tutto continui a funzionare senza problemi.

C'è un database LDAP contenente le informazioni relative agli sviluppatori Debian su https://db.debian.org/. Si dovrebbe immettere le informazioni li ed aggiornarle appena cambiano. Più in particolare, fare in modo che l'indirizzo al quale la propria email debian.org viene inoltrata sia sempre aggiornato, così come l'indirizzo in cui si hanno le proprie iscrizioni debian private se si sceglie di sottoscriverle.

Per ulteriori informazioni sul database, si consulti Sezione 4.5, «Il Database degli sviluppatori».

Si sia molto attenti con le vostre chiavi private. Non le si metta su qualsiasi server pubblico o macchine multiutente, come ad esempio il server Debian (si consulti Sezione 4.4, «Le macchine Debian»). Eseguire copie delle chiavi; si conservi una copia offline. Leggere la documentazione fornita con il software; leggere la PGP FAQ.

È necessario garantire non solo che la vostra chiave è sicura contro il furto, ma anche che è protetta in caso di smarrimento. Generare e fare una copia (meglio anche se in forma cartacea) del certificato di revoca; questo è necessario se la chiave viene persa.

Se aggiungete firme alla vostra chiave pubblica, o aggiungete identità di utenti, è possibile aggiornare il portachiavi Debian inviando la vostra chiave al server delle chiavi all'indirizzo keyring.debian.org.

Se è necessario aggiungere una nuova chiave o rimuovere una vecchia, è necessario che la nuova chiave sia firmata da un altro sviluppatore. Se la vecchia chiave è compromessa o non valida, si deve anche aggiungere il certificato di revoca. Se non vi è alcun motivo reale per una nuova chiave, i Keyring Maintainer potrebbero rifiutare la nuova chiave. Dettagli possono essere trovati presso http://keyring.debian.org/replacing_keys.html.

Si applichino le stesse routine di estrazione di chiavi discusse nel Sezione 2.3, «Registrazione come sviluppatore Debian».

Si può trovare una più approfondita discussione sulla manutenzione delle chiavi Debian nella documentazione del pacchetto debian-keyring.

Anche se Debian non è davvero una democrazia, usiamo un processo democratico per eleggere i nostri leader e ad approvare risoluzioni generali. Queste procedure sono definite dalla Costituzione Debian.

Oltre all'annuale elezione del leader, le votazioni non sono tenute regolarmente e non sono intraprese con leggerezza. Ogni proposta è prima discussa sulla mailing list e richiede diverse approvazioni prima che il segretario del progetto inizii la procedura di voto.

Non dovete monitorare le discussioni pre-voto, considerato che il segretario effettuerà diverse chiamate di votazione su (e tutti gli sviluppatori dovrebbero essere iscritti a questa lista). La democrazia non funziona bene se le persone non prendono parte al voto, è per questo che invitiamo tutti gli sviluppatori a votare. Le votazioni sono condotte attraverso messaggi email GPG-signed/encrypted.

L'elenco di tutte le proposte (passate e presenti) è disponibile sul Debian Voting Information pagina, insieme a informazioni su come fare, supportare e votare proposte.

È comune per gli sviluppatori avere periodi di assenza, se queste sono le vacanze programmate o semplicemente se sono sepolti in altri lavori. La cosa importante da notare è che gli altri sviluppatori hanno bisogno di sapere che si è in vacanza in modo che possano fare tutto ciò che è necessario in caso di problemi con i propri pacchetti o altri obblighi nel progetto.

Di solito questo significa che altri sviluppatori sono consentiti NMU (si consulti Sezione 5.11, «Caricamenti dei Non-Maintainer (NMU)») per il proprio pacchetto se un grosso problema (bug critico per la release, aggiornamento della sicurezza, etc.), si verifica mentre si è in vacanza. A volte non è niente di così critico come quelli, ma è ancora il caso di far sapere agli altri che non si è disponibili.

Al fine di informare gli altri sviluppatori, ci sono due cose che si dovrebbero fare. In primo luogo inviare una email a con [VAC] anteposto all'argomento del messaggio [2] e indicare il periodo di tempo in cui si sarà in vacanza. Si possono anche dare alcune speciali istruzioni su cosa fare in caso di problemi.

L'altra cosa da fare è quella di segnare se stessi come in vacanza nel Debian developers' LDAP database (questa informazione è accessibile solo agli sviluppatori Debian). Non dimenticare di togliere il flag vacanza quando si torna!

Idealmente, si dovrebbe firmare la GPG coordination pages al momento della prenotazione di una vacanza e verificare se qualcuno ci sta cercando per la firma. Questo è particolarmente importante quando la gente va in luoghi esotici dove non abbiamo ancora degli sviluppatori, ma dove ci sono persone che sono interessati a presentare domanda.

Se si sceglie di lasciare il progetto Debian, è necessario assicurarsi di eseguire le seguenti operazioni:

  1. rendete orfani tutti i pacchetti, come descritto in Sezione 5.9.4, «Pacchetto orfano».

  2. Inviare una email gpg-firmata sul perché si sta lasciando il progetto a

  3. Comunicare ai keyring maintainer Debian che si sta lasciando con l'apertura di un ticket in Debian RT e con l'invio di una email all'indirizzo con le parole «Debian RT» da qualche parte nella riga dell'oggetto (le maiuscole e minuscole non importano).

  4. Se si ricevono mail da un alias e-mail di @debian.org (e.g: press@debian.org) e si desidera essere rimosso, aprire una segnalazione RT per gli Amministratori dei Sistemi Debian. Si invii una e-mail a con la dicitura "Debian RT" da qualche parte nel soggetto indicando da quali alias si desidera esseere rimossi.

È importante che il processo di cui sopra sia seguito, perché trovare sviluppatori inattivi e rendere orfani i loro pacchetti richiede molto tempo e lavoro.

l'account di uno sviluppatore congedato è contrassegnato come «emerito» quando il processo in Sezione 3.2.5, «Congedarsi» è seguito e «disabled» in caso contrario. Gli sviluppatori ritirati con un account «emerito» possono ottenere il loro account riattivato come segue:

  • Si contatti .

  • Si passi attraverso un processo di NM accorciato (per garantire che il committente tornando sappia ancora parti importanti della P&P and T&S).

  • Si dimostri che ancora si controlla la chiave GPG associata all'account, o si fornisca la prova di identificazione su una nuova chiave GPG, con almeno due firme da altri sviluppatori.

Gli sviluppatori congedati con un account «disabilitato» necessitano nuovamente di passare attraverso NM.



[2] Questo è come il messaggio può essere facilmente filtrato da persone che non vogliono leggere avvisi di vacanza.