Capitolo 7. Oltre la pacchettizzazione

Indice

7.1. Segnalare i bug
7.1.1. Riportare molti bug in una sola volta (presentazione massiccia di bug)
7.1.1.1. Usertag
7.2. Costo della Quality Assurance
7.2.1. Lavoro giornaliero
7.2.2. Bug squashing parties
7.3. Come contattare gli altri maintainer
7.4. Rapportarsi con maintainer non attivi e/o non raggiungibili
7.5. Interagire con potenziali sviluppatori Debian
7.5.1. Sponsorizzare pacchetti
7.5.1.1. Sponsorizzare un nuovo pacchetto
7.5.1.2. Sponsorizzare un aggiornamento di un pacchetto esistente
7.5.2. Promuovere nuovi sviluppatori
7.5.3. Gestire nuove candidature di maintainer

Debian è molto più di un semplice software di confezionamento e di mantenimento di questi pacchetti. Questo capitolo contiene informazioni sui modi, modi spesso molto critici, per contribuire a Debian oltre la semplice creazione e la manutenzione dei pacchetti.

Come organizzazione di volontariato, Debian si basa sulla discrezione dei suoi membri nella scelta di ciò su cui vogliono lavorare e nello scegliere la cosa più critica sulla quale trascorre la maggior parte del proprio tempo.

Si consiglia di notificare i bug appena li si trovi nei pacchetti Debian. In realtà, gli sviluppatori Debian sono spesso la prima linea di tester. L'individuazione e la segnalazione di bug nei pacchetti di altri sviluppatori migliora la qualità di Debian.

Si leggano le istruzioni per la segnalazione di bug nel sistema di tracciamento dei bug di Debian.

Provare a presentare il bug da un account di un utente normale dove si preferisce ricevere la posta, in modo che le persone possano rintracciarvi se hanno bisogno di ulteriori informazioni sul bug. Non inviare bug come root.

È possibile utilizzare uno strumento come reportbug(1) per segnalare bug. È in grado di automatizzare e in generale facilitare il processo.

Assicurarsi che il bug non sia già stato presentato per un pacchetto. Ogni pacchetto ha una lista di bug facilmente raggiungibile a http://bugs.debian.org/nomepacchetto . Programmi di utilità come querybts(1) possono anche fornire queste informazioni (e anche reportbug di solito invocherà querybts prima di inviare).

Cercare di indirizzare i bug nella posizione corretta. Quando per esempio il proprio bug è relativo ad un pacchetto che sovrascrive i file appartenenti ad un altro pacchetto, controllare le liste di bug per entrambi questi pacchetti in modo da evitare di presentare duplicati di segnalazioni di bug.

Per maggior credito, si può passare attraverso altri pacchetti, unificando i bug che sono riportati più di una volta, o etichettando bug «fixed» quando sono già stati risolti. Si noti che quando non si è né il mittente del bug né il maintainer del pacchetto, non si dovrebbe in realtà chiudere il bug (a meno che non si ha il permesso del maintainer).

Di tanto in tanto si consiglia di controllare lo stato di avanzamento del bug che si è inviato. Cogliere l'occasione di chiudere quelli che non è possibile più riprodurre. Per scoprire tutti i bug che si sono inviati, è sufficiente visitare http://bugs.debian.org/from:proprio-indirizzo-email.

Segnalare un gran numero di bug per lo stesso problema su un gran numero di pacchetti differenti - vale a dire, più di 10 - è una pratica sconsigliata. Prendete tutte le misure possibili per evitare del tutto di sottoporre bug massicci. Per esempio, se il controllo per il problema può essere automatizzato, aggiungere un nuovo controllo per lintian in modo che venga emesso un errore o un avviso.

Se si riportano più di 10 bug sullo stesso argomento in una sola volta, si consiglia di inviare un messaggio a dove descrivete la vostra intenzione prima di presentare il rapporto e di menzionarla nell'oggetto della mail. Questo permetterà ad altri sviluppatori di verificare che il bug sia un problema reale. Inoltre, aiuterà a prevenire una situazione in cui molti maintainer iniziano ad occuparsi simultaneamente dello stesso bug.

Utilizzare i programmi dd-list e se appropriato whodepends (dal pacchetto devscripts) per generare un elenco di tutti i pacchetti interessati, ed includere l'output nella propria email indirizzata a .

Si noti che quando si inviano molti bug sullo stesso argomento, si dovrebbe inviare la segnalazione di bug a in modo che la segnalazione non venga inoltrata alla mailing list di distribuzione bug.

Anche se c'è un gruppo dedicato di persone per la Quality Assurance, le mansioni QA non sono riservate esclusivamente a loro. È possibile partecipare a questo sforzo, mantenendo i vostri pacchetti il più possibile privi di bug e il più possibile lintian-clean (si consulti Sezione A.2.1, «lintian»). Se non si riesce a farlo, allora si dovrebbe prendere in considerazione di rendere orfani alcuni dei vostri pacchetti (si consulti Sezione 5.9.4, «Pacchetto orfano»). In alternativa, si può chiedere l'aiuto di altre persone al fine di recuperare il ritardo con i bug arretrati che si hanno (si può chiedere aiuto su o ). Allo stesso tempo, si può cercare un co-maintainer (si consulti Sezione 5.12, «La manutenzione collaborativa»).

Di volta in volta il gruppo QA organizza feste di bug squashing in modo da sbarazzarsi di quanti più problemi possibili. Sono annunciati su e l'annuncio spiega quale area sarà al centro della festa: di solito si concentrano sui bug critici per il rilascio, ma può accadere che decidano di aiutare a terminare un importante aggiornamento (come una nuova versione perl che richiede la ricompilazione di tutti i moduli binari).

Le regole per il caricamento di non-maintainer cambiano durante le feste perché l'annuncio della festa è considerata prioritaria per NMU. Se si dispone di pacchetti che possono essere influenzati dalla festa (perché hanno rilasciato bug critici per esempio), è necessario inviare un aggiornamento per ciascun bug corrispondente per spiegare il loro stato attuale e cosa ci si apetti dalla festa. Se non si vuole un NMU, o se si è solo interessati ad una patch, o se si vuole fare da soli con il bug, spiegarlo nel BTS.

Le persone che partecipano alla festa hanno regole speciali per un NMU, possono fare un NMU senza preavviso se caricano i loro NMU su DELAYED/3-giorni almeno. Tutte le altre regole NMU si applicano come di solito; dovrebbero inviare la patch del NMU al BTS (a uno dei bug aperti fissati dal NMU, o di un nuovo bug, etichettato fisso). Dovrebbero anche rispettare particolari desideri del maintainer.

Se non ci si sente sicuri di fare un NMU, basta inviare una patch al BTS. È molto meglio di un NMU non funzionante.

Durante il corso della vita all'interno di Debian, si dovranno contattare altri maintainer per vari motivi. Si vorrà discutere di un nuovo modo di cooperare tra un insieme di pacchetti correlati, o semplicemente si vorrà ricordare a qualcuno che una nuova versione è disponibile e che se ne ha bisogno.

Cercare l'indirizzo email del maintainer del pacchetto può essere fonte di distrazione. Fortunatamente, c'è un semplice alias di posta elettronica, package@packages.debian.org, che fornisce un modo per inviare email al maintainer, qualunque possa essere il loro indirizzo di posta elettronica individuale (o gli indirizzi). Sostituite package con il nome di un sorgente o un pacchetto binario.

Si potrebbe anche essere interessati a contattare le persone che sono iscritte ad un determinato pacchetto sorgente tramite Sezione 4.10, «L'archivio Debian». È possibile farlo utilizzando l'indirizzo email package@packages.qa.debian.org.

Se si nota che un pacchetto è carente di manutenzione, è necessario assicurarsi che i maintainer siano attivi e che continueranno a lavorare sui loro pacchetti. È possibile che essi non siano più attivi, ma non si sono deregistrati dal sistema, per così dire. D'altra parte, è anche possibile che abbiano solo bisogno di un promemoria.

C'è un sistema semplice (il database MIA) in cui vengono registrate informazioni inerenti i maintainer etichettati come Missing In Action. Quando un membro del gruppo QA contatta un maintainer inattivo o trova ulteriori informazioni su qualcuno, questo viene registrato nel database di MIA. Questo sistema è disponibile in /org/qa.debian.org/MIA sull'host qa.debian.org e può essere interrogato con lo strumento mia-query. Utilizzare mia-query - help per vedere come interrogare il database. Se si scopre che ancora alcuna informazione è stata registrata su un maintainer inattivo, o che è possibile aggiungere ulteriori informazioni, si

Il primo passo è quello di contattare educatamente il maintainer, ed attendere un ragionevole lasso di tempo per la risposta. È abbastanza difficile definire tempo ragionevole, ma è importante tenere in considerazione che la vita reale a volte è molto frenetica. Un modo per gestire questa situazione sarebbe quello di inviare un sollecito dopo due settimane.

Se il maintainer non risponde entro quattro settimane (un mese), si può supporre che la risposta probabilmente non arriverà. Se ciò accade, si dovrebbe indagare ulteriormente e cercare di raccogliere quante più informazioni utili possibili sul maintainer in questione. Ciò include:

  • Le informazioni echelon disponibili attraverso il database LDAP degli sviluppatori, che indica quando lo sviluppatore ha pubblicato l'ultimo post in una mailing list Debian. (Questo include email su aggiornamenti distribuiti tramite la lista ). Inoltre, ricordare di controllare nel database se il maintainer è contrassegnato come in vacanza.

  • Il numero di pacchetti dei quali questo maintainer è responsabile e lo stato di quei pacchetti. In particolare, ci sono dei bug RC che sono stati aperti da tempo? Inoltre, quanti bug ci sono in generale? Un altro pezzo importante di informazioni è se i pacchetti sono stati NMUed e se sì, da chi.

  • C'è qualche attività del maintainer al di fuori di Debian? Ad esempio, potrebbero aver inviato qualcosa di recente a mailing list non-Debian o newsgroup.

Un po' problematici sono i pacchetti che sono stati sponsorizzatiì: il maintainer non è uno sviluppatore Debian ufficiale. Le informazioni echelon non sono disponibili per le persone sponsorizzate, per esempio, quindi è necessario trovare e contattare lo sviluppatore Debian che ha effettivamente caricato il pacchetto. Dato che hanno firmato il pacchetto, che sono responsabili per il caricamento in ogni caso, e sono probabilmente intenzionati di sapere cosa è successo alla persona che hanno sponsorizzato.

È anche consentito inviare una query a chiedendo se qualcuno è a conoscenza del luogo in cui si trova il maintainer mancante. Si metta in Cc: la persona in questione.

Dopo aver raccolto tutto questo, è possibile contattare . Persone su questo alias utilizzeranno le informazioni fornite al fine di decidere come procedere. Per esempio, potrebbero rendere orfano uno o tutti i pacchetti del maintainer. Se un pacchetto è stato NMUed, potrebbero preferire di contattare la NMUer prima di rendere orfano il pacchetto; forse la persona che ha fatto la NMU è interessato al pacchetto.

Un'ultima parola: ricordare di essere educati. Si è tutti volontari e non si può dedicare tutto il proprio tempo a Debian. Inoltre, non si è a conoscenza delle circostanze della persona che è coinvolta. Forse potrebbe essere gravemente malata o potrebbe anche essere morta: non potete sapere chi potrebbe essere dall'altra parte. Si immagini come un parente si sentirà se leggesse l'email del defunto e trovasse un messaggio molto scortese, arrabbiato e accusatorio!

D'altra parte, anche se si è volontari, si ha una responsabilità. Così si può sottolineare l'importanza di un bene più grande: se un maintainer non ha più il tempo o interesse, dovrebbe lasciar andare e dare il pacchetto a qualcuno con più tempo.

Se si è interessati a lavorare nel team MIA, si dia un'occhiata al file README in /org/qa.debian.org/mia su qa.debian.org dove i dettagli tecnici e le procedure di MIA sono documentate e contatti .

Il successo di Debian dipende dalla sua capacità di attrarre e trattenere nuovi e talentuosi volontari. Se si è uno sviluppatore esperto, si consiglia di partecipare al processo per coinvolgere nuovi sviluppatori. Questa sezione descrive come aiutare i nuovi potenziali sviluppatori.

Sponsorizzare un pacchetto significa caricare un pacchetto per un maintainer, che non è in grado di farlo da solo. Non è una cosa da poco, lo sponsor deve verificare il package ed assicurarsi che esso soddisfi l'elevato livello di qualità che Debian si sforza di avere.

Gli sviluppatori Debian possono sponsorizzare i pacchetti. I maintainer Debian non possono.

Il processo di sponsorizzazione di un pacchetto è:

  1. Il maintainer prepara un pacchetto sorgente (.dsc) e lo mette in linea da qualche parte (come su mentors.debian.net) o, meglio ancora, fornisce un collegamento a un repository pubblico di VCS (si consulti Sezione 4.4.5, «I server VCS») in cui il pacchetto viene mantenuto.

  2. Lo sponsor scarica (o fa il checkout) del sorgente del pacchetto.

  3. Lo sponsor esamina il pacchetto sorgente. Se trova dei problemi, informa il maintainer chiedendogli di fornire una versione corretta (il processo inizia dal punto 1).

  4. Lo sponsor non può trovare tutti i problemi che ci sono. Compila il pacchetto, lo firma e lo carica su Debian.

Prima di addentrarci nei dettagli su come sponsorizzare un pacchetto, ci si dovrebbe chiedere se l'aggiunta del pacchetto proposto è vantaggiosa per Debian.

Non è semplice rispondere a questa domanda, può dipendere da molti fattori: il codice originale è maturo e privo di falle di sicurezza? Ci sono pacchetti pre-esistenti che possono fare lo stesso compito e come si comparano con questo nuovo pacchetto? Il nuovo pacchetto è stato richiesto dagli utenti e da quanti? Quanto sono attivi gli sviluppatori originali?

Ci si dovrebbe anche assicurare che il potenziale maintainer sarà un buon maintainer. Hanno già una certa esperienza con altri pacchetti? Se sì, stanno facendo un buon lavoro con loro (corretti alcuni bug)? Hanno familiarità con il pacchetto e con il suo linguaggio di programmazione? Hanno le competenze necessarie per questo pacchetto? In caso contrario, sono in grado di impararle?

È anche una buona idea conoscere la loro posizione rispetto a Debian: sono d'accordo con la filosofia di Debian e hanno intenzione di aderire a Debian? Considerato quanto sia facile diventare un Maintainer Debian, si potrebbe voler sponsorizzare solo le persone che hanno intenzione di aderire. In questo modo fin dall'inizio si è consapevoli che non si dovrà agire in qualità di sponsor a tempo indeterminato.

I nuovi maintainer di solito hanno alcune difficoltà nel creare pacchetti Debian - questo è abbastanza comprensibile. Faranno errori. Ecco perché sponsorizzare un nuovo pacchetto in Debian richiede una profonda conoscenza della pacchettizzazione in Debian. A volte saranno necessarie diverse iterazioni fino a quando il pacchetto sarà abbastanza buono per essere caricato in Debian. Quindi essere uno sponsor implica essere un mentore.

Non bisogna mai sponsorizzare un nuovo pacchetto senza revisionarlo. La revisione dei nuovi pacchetti realizzata da ftpmasters assicura principalmente che il software sia veramente libero. Certo, capita che inciampino sui problemi di pacchettizzazione, ma in realtà non dovrebbero. È il proprio compito garantire che il pacchetto caricato sia conforme alle Free Software Guidelines di Debian e sia di buona qualità.

La compilazione del pacchetto e il testare il software è parte della revisione, ma non è anche sufficiente. Il resto di questa sezione contiene un elenco non esaustivo dei punti da controllare nella vostra revisione. [7]

  • Verificare che il tarball originale fornito sia lo stesso che è stato distribuito dall'autore principale (quando i sorgenti sono stati ripacchettizzati per Debian, generare da soli la tarball modificata).

  • Eseguire lintian (si consulti Sezione A.2.1, «lintian»). Troverà molti problemi comuni. Assicurarsi di verificare che qualsiasi lintian che sovrascriva la configurazione fatta dal maintainer sia pienamente giustificata.

  • Eseguire licensecheck (parte di Sezione A.6.1, «devscripts») e verificare che debian/copyright sia corretto e completo. Cercare i problemi di licenza (come i file con intestazioni del tipo “All rights reserved”, o con una licenza non compatibile con DFSG). grep -ri è un amico per questo compito.

  • Compilare il pacchetto con pbuilder (o qualsiasi strumento simile, vedi Sezione A.4.3, «pbuilder») per garantire che le dipendenze di compilazione siano soddisfatte.

  • Correggere debian/control: segue le buone pratiche (si consulti Sezione 6.2, «Buone pratiche per debian/control»)? Sono soddisfatte le dipendenze?

  • Correggere debian/rules: rispecchia le buone pratiche (si consulti Sezione 6.1, «Buone pratiche per debian/rules»)? Vedete alcuni possibili miglioramenti?

  • Correggere gli script del maintainer (preinst, postinst, prerm, postrm, config): preinst/postrm funzioneranno quando le dipendenze non sono installate? Tutti gli script sono idempotenti (cioè si possono eseguire più volte senza conseguenze)?

  • Controllare ogni modifica ai file originali (sia in .diff.gz, o in debian/patches/ o direttamente incluse nella tarball debian dei file binari). Sono giustificate? Sono adeguatamente documentate (con DEP-3 per le patch)?

  • Per ogni file, ci si chieda perché il file è lì e se è il modo giusto per ottenere il risultato desiderato. Il maintainer sta seguendo le best practices per la pacchettizzazione (si consulti Capitolo 6, Buone pratiche per la pacchettizzazione)?

  • Compilare i pacchetti, installarli e provare il software. Assicurarsi di poter rimuovere ed eliminare i pacchetti. Forse provarli con piuparts.

Se il controllo non ha evidenziato alcun problema, si può compilare il pacchetto e caricarlo su Debian. Ricordare che, anche se non si è il maintainer, in qualità di sponsor si è ancora responsabile per ciò che si carica in Debian. Ecco perché si è incoraggiati a tenere il passo con il pacchetto attraverso il Sezione 4.10, «L'archivio Debian».

Si noti che non dovrebbe essere necessario modificare il pacchetto sorgente per inserire il proprio nome nella changelog o nel file di control. Il campo Maintainer del file control e del file changelog dovrebbe elencare la persona che ha fatto la pacchettizzazione, ossia la persona sponsorizzata. In questo modo riceveranno tutta la posta BTS.

Invece di dovrebbe istruire dpkg-buildpackage ad usare la propria chiave per la firma. Lo si fa con l'opzione -k:

dpkg-buildpackage -kKEY-ID

Se si usa debuild e debsign, si può anche configurarlo in modo permanente in ~/devscripts.:

DEBSIGN_KEYID=KEY-ID

Normalmente si presupporrà che il pacchetto sia già passato attraverso una revisione completa. Così, invece di farlo di nuovo, si analizzerà attentamente la differenza tra la versione attuale e la nuova versione preparata dal maintainer. Se non si è fatta da soli la revisione iniziale, si potrebbe anche voler dare uno sguardo più profondo nel caso in cui il revisore iniziale fosse stato sciatto.

Per essere in grado di analizzare la differenza è necessario avere entrambe le versioni. Scaricare la versione attuale del pacchetto sorgente (con apt-get source) e ricompilarlo (o scaricare gli attuali pacchetti binari con aptitude download). Scaricare il pacchetto sorgente da sponsorizzare (di solito con dget).

Leggere la nuova voce del changelog, dovrebbe dire cosa aspettarsi durante la revisione. Il principale strumento che si utilizzerà è debdiff (fornito con il pacchetto devscripts), lo si può eseguire con due pacchetti sorgente (i file .dsc), o due file .changes (allora confronterà tutti i pacchetti binari elencati nel file .changes).

Se si confrontano i pacchetti sorgente (esclusi i file originali nel caso di una nuova versione, ad esempio filtrando l'output di debdiff con filterdiff-i '*/debian/*'), è necessario capire tutti i cambiamenti che vedrete e che devono essere adeguatamente documentati nel changelog Debian.

Se tutto va bene, compilare il pacchetto e confrontare i pacchetti binari per verificare che le modifiche sul pacchetto sorgente non abbiano conseguenze inattese (come alcuni file cancellati per errore, le dipendenze non soddisfatte, etc).

Si potrebbe controllare il Package Tracking System (si consulti Sezione 4.10, «L'archivio Debian») per verificare se il maintainer non abbia perso qualcosa di importante. Magari ci sono aggiornamenti di traduzioni che stanziano nel BTS e che sarebbero potute essere integrate. Forse il pacchetto è stato NMUed e il maintainer ha dimenticato di integrare le modifiche nel loro pacchetto dal NMU. Forse c'è un rilascio per un bug critico che hanno lasciato non gestito e che sta bloccando la migrazione in testing. Se si trova qualcosa che avrebbero potuto fare (meglio), è il momento di dirglielo in modo che per la prossima volta possano migliorare e in modo che abbiano una migliore comprensione delle loro responsabilità.

Se non si è trovato alcun grande problema, caricare la nuova versione. In caso contrario, chiedere al maintainer di fornire una versione corretta.



[7] Si possono trovare altri controlli nella wiki nella quale diversi sviluppatori condividono le proprie liste di sponsorizzazione.