# 3. Doveri di un Debian Developer

## 3.1. Doveri di un maintainer di pacchetti

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.

### 3.1.1. Lavorare per il prossimo rilascio `stable`

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

### 3.1.2. Mantenere i pacchetti in `stable`

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 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 Caso particolare: caricamenti sulle distribuzioni stable e oldstable).

### 3.1.3. Gestire i bug critici per il rilascio

In generale si dovrebbe affrontare le segnalazioni di bug sui propri pacchetti come è descritto in 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 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 Rapportarsi con maintainer non attivi e/o non raggiungibili).

### 3.1.4. Coordinamento con gli sviluppatori originali

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. Ideally, you also get upstream to subscribe for Debian Package Tracker notifications for their software in Debian.

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.

As most upstreams nowadays use git for version control, in most cases git-buildpackage offers the most convenient way to create and maintain patches in Debian that so they are submit upstream. For details, see git-buildpackage man pages about using `pq` to write and test `debian/patches` as git commits, and having git remote `upstreamvcs` to easily cherry-pick patches to and from upstream git branches.

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.

## 3.2. Doveri amministrativi

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.

### 3.2.1. Gestire le vostre informazioni Debian

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 Il Database degli sviluppatori.

### 3.2.2. Mantenere la vostra chiave pubblica

Be very careful with your private keys. Do not place them on any public servers or multiuser machines, such as the Debian servers (see 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.

If you need to add a completely new key or remove an old key, you need to get the new key signed by another developer. If the old key is compromised or invalid, you also have to add the revocation certificate. If there is no real reason for a new key, the Keyring Maintainers might reject the new key. Details can be found at https://keyring.debian.org/replacing_keys.html.

Si applichino le stesse routine di estrazione di chiavi discusse nel 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 https://keyring.debian.org/ site.

### 3.2.3. Votare

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.

You don't have to track the pre-vote discussions, as the secretary will issue several calls for votes on `debian-devel-announce@lists.debian.org` (and all developers are expected to be subscribed to that list). Democracy doesn't work well if people don't take part in the vote, which is why we encourage all developers to vote. Voting is conducted via OpenPGP-signed/encrypted email messages.

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.

### 3.2.4. Decision making

Besides the issues covered in Votare, Debian is closer to a do-ocracy, than a democracy. Generally speaking, this means that decisions are taken by the people who do the work, which in most cases is package maintainers and DPL delegates. Public discussion:

- while encouraged and may be appreciated as input to take a decision,

- is not required to take a decision,

- nor can overrule a decision (the latter is possible via a General Resolution or by escalating to the Debian Technical Committee).

In the spirit of do-ocracy, members of the Debian community are expected to contribute in concrete and constructive ways, rather than demand that others do any kind of work for them.

For more on the social aspects of contributing to Debian, you are strongly encouraged to read the Debian Community Guidelines at http://people.debian.org/~enrico/dcg/

### 3.2.5. Andare in vacanza con garbo

È 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 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 [1] 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 Il Database degli sviluppatori (questa informazione è accessibile solo agli sviluppatori Debian). Non dimenticare di togliere il flag vacanza quando si torna!

Ideally, you should sign up at the OpenPGP coordination pages when booking a holiday and check if anyone there is looking for signing. This is especially important when people go to exotic places where we don't have any developers yet but where there are people who are interested in applying.

### 3.2.6. Congedarsi

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

- Orphan all your packages, as described in Pacchetto orfano.

- Remove yourself from uploaders for co- or team-maintained packages.

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

- Please remember to also retire from teams, e.g. remove yourself from team wiki pages or salsa groups.

- Use the link https://nm.debian.org/process/emeritus to log in to nm.debian.org, request emeritus status and write a goodbye message that will be automatically posted on debian-private.

  Salsa is used as authentification provider to the NM site, in case you run into problems opening the retirement process yourself, contact NM front desk using `nm@debian.org`

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

### 3.2.7. Ritornare dopo il congedo

A retired developer's account is marked as "emeritus" when the process in Congedarsi is followed, and "removed" otherwise. Retired developers with an "emeritus" account can get their account re-activated as follows:

- Log on onto nm.debian.org using your salsa credentials.

- Follow the Return from Emeritus Wizard.

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

In case your run into problems contact `nm@debian.org` for further instructions.

Retired developers with a "removed" account need to go through full NM again.

[1]

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