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

As a package maintainer, you're supposed to provide high-quality packages that are well integrated into the system and that adhere to the Debian Policy.

Providing high-quality packages in unstable is not enough; most users will only benefit from your packages when they are released as part of the next stable release. You are thus expected to collaborate with the release team to ensure your packages get included.

Più concretamente, si dovrà controllare che i pacchetti stiano migrando verso testing (si consulti Sezione 5.14, «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»).

A big part of your job as Debian maintainer will be to stay in contact with the upstream developers. Debian users will sometimes report bugs that are not specific to Debian to our bug tracking system. These bug reports should be forwarded to the upstream developers so that they can be fixed in a future upstream release. Usually it is best if you can do this, but alternatively, you may ask the bug submitter to do it.

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.

In cases where a bug report is forwarded upstream, it may be helpful to remember that the bts-link service can help with synchronizing states between the upstream bug tracker and the Debian one.

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».

Be very careful with your private keys. Do not place them on any public servers or multiuser machines, such as the Debian servers (see Sezione 4.4, «Le macchine Debian»). Back your keys up; keep a copy offline. Read the documentation that comes with your software; read the PGP FAQ and OpenPGP Best Practices.

È 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.

If you add signatures to your public key, or add user identities, you can update the Debian key ring by sending your key to the key server at keyring.debian.org. Updates are processed at least once a month by the debian-keyring package maintainers.

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, «Registering as a Debian member».

You can find a more in-depth discussion of Debian key maintenance in the documentation of the debian-keyring package and the http://keyring.debian.org/ site.

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. Notify the Debian key ring maintainers that you are leaving by opening a ticket in Debian RT by sending a mail to with the words "Debian RT" somewhere in the subject line (case doesn't matter).

  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.