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.
La maggior parte del lavoro del maintainer del pacchetto è fornire versioni
aggiornate dei pacchetti in unstable
, ma il loro lavoro
comporta anche prendersi cura dei pacchetti nell'attuale rilascio
stable
.
Mentre i cambiamenti in stable
sono scoraggiati, sono
comunque possibili. Ogni volta che un problema di sicurezza è segnalato, si
dovrebbe collaborare con il team di sicurezza per fornire una versione
corretta (si veda Sezione 5.8.5, «Gestione di bug relativi alla sicurezza»). Quando i bug di gravità
importante (o più) vengono segnalati per la versione
stable
dei propri pacchetti, si dovrebbe valutare la
possibilità di fornire una correzione mirata. Si potrà chiedere al team di
rilascio stable
se accettano tale tipo di aggiornamento e
poi preparare un caricamento stable
(si consulti Sezione 5.5.1, «Caso particolare: caricamenti sulle distribuzioni stable
e oldstable
»).
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».
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, «Registrazione come sviluppatore Debian».
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 <debian-vote@lists.debian.org>
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 <debian-devel-announce@lists.debian.org>
(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 <@debian-private e
liste-host;>
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:
rendete orfani tutti i pacchetti, come descritto in Sezione 5.9.4, «Pacchetto orfano».
Inviare una email gpg-firmata sul perché si sta lasciando il progetto a
Notify the Debian key ring maintainers that you are leaving by opening a
ticket in Debian RT by sending a mail to <keyring@rt.debian.org>
with the words
"Debian RT" somewhere in the subject line (case doesn't matter).
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
<admin@rt.debian.org>
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 <da-manager@debian.org>
.
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.