I grandi risultati prodotti dal progetto Debian sono dovuti contemporaneamente al lavoro svolto sull'infrastruttura dagli esperti sviluppatori di Debian, dal lavoro individuale o collettivo degli sviluppatori sui pacchetti Debian, e dalle opinioni degli utenti.
1.3.1. Gli Sviluppatori Debian
Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is traditionally generally responsible for at least one package, but according to their available time and desire, they are free to become involved in numerous teams and projects, thus acquiring more responsibilities within the project.
Package maintenance is a relatively regimented activity, very documented, or even regulated. It must, in effect, comply with all the standards established by the
Debian Policy. Fortunately, there are many tools that facilitate the maintainer's work. The developer can, thus, focus on the specifics of their package and on more complex tasks, such as “squashing“ bugs.
Le Policy, un elemento essenziale del progetto Debian, stabiliscono le norme che garantiscono la qualità dei pacchetti e la loro perfetta interoperabilità con il resto della distribuzione. Grazie a queste politiche, Debian rimane coerente nonostante le sue dimensioni gigantesche. Queste Policy non sono scritte sulla pietra, ma sono in continua evoluzione grazie alle proposte formulate sulla mailing list
debian-policy@lists.debian.org
. Gli emendamenti che sono stati approvati da tutti sono accettati e applicati al testo da un piccolo gruppo di manutentori che non hanno responsabilità editoriale (loro includono solamente le modifiche concordate dagli sviluppatori Debian che sono membri della suddetta lista). È possibile consultare le attuali proposte di modifica sul sistema di tracciamento dei bug:
Le Policy coprono molto bene gli aspetti tecnici della creazione dei pacchetti. La dimensione del progetto solleva anche problemi organizzativi; questi vengono trattati dalla Costituzione Debian, che stabilisce la struttura ed i mezzi per il processo decisionale. In altre parole, un sistema formale di governance.
La costituzione definisce un certo numero di ruoli e posizioni, compreso le responsabilità e le autorità di ognuno. È particolarmente interessante notare che gli sviluppatori Debian dispongono sempre dell'autorità per la decisione finale, potendo votare le risoluzioni generali, in cui per apportare modifiche significative (come quelle che riguardano i documenti fondanti) è necessaria una maggioranza qualificata dei tre quarti (75%) dei voti. Tuttavia, gli sviluppatori annualmente eleggono un "leader" per rappresentarli nelle riunioni, e garantire il coordinamento interno tra i diversi team. Questa elezione è sempre preceduta da un periodo di intense discussioni. Il ruolo del Leader del Progetto Debian (Debian Project Leader
DPL) non è definito formalmente da alcun documento: i candidati a questo ruolo di solito propongono la propria definizione della posizione. In pratica, i ruoli del leader comprendono quello di mantenere i rapporti con i media, il coordinamento "interno" fra i vari team e l'assegnare un orientamento generale al progetto in cui gli sviluppatori possano riconoscersi: il punto di vista del DPL è implicitamente approvato dalla maggioranza dei membri del progetto.
In particolare, i leader hanno un potere reale: i loro voti risolvono le votazioni in pareggio, loro possono prendere ogni decisione che non sia già assegnata ad un'altra autorità e possono delegare parte delle proprie responsabilità.
Since its inception, the project has been successively led by Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman, Jonathan Carter, and Andreas Tille.
La costituzione definisce anche il "comitato tecnico". Il principale ruolo di questo comitato è quello di derimere dispute in materia tecnica quando gli sviluppatori interessati non hanno raggiunto un accordo tra di loro. Oltre a ciò, questo comitato svolge un ruolo consultivo per qualsiasi sviluppatore che non riesce a prendere una decisione di cui è responsabile. È importante notare che, per essere coinvolto, deve essere comunque interpellato da una delle parti in questione.
Infine, la costituzione definisce la posizione del "segretario del progetto", che si occupa dell'organizzazione delle votazioni relative alle varie elezioni e risoluzioni generali.
La procedura “risoluzione generale” (
GR) è completamente dettagliata nella costituzione, dall'inizio della discussione fino al conteggio finale dei voti. L'aspetto maggiormente interessante di questo processo è quando si arriva alla votazione vera e propria: gli sviluppatori devono mettere in ordine le diverse opzioni di voto e il vincitore è scelto attraverso il
Metodo Condorcet (più specificamente il metodo Schulze). Per maggiori dettagli leggere:
Even if this constitution establishes a semblance of democracy, the daily reality is quite different: Debian naturally follows the free software rules of the do-ocracy: the one who does things gets to decide how to do them. A lot of time can be wasted debating the respective merits of various ways to approach a problem; the chosen solution will be the first one that is both functional and satisfying… which will come out of the time that a competent person puts into it.
Questo è l'unico modo per guadagnarsi i galloni: fare qualcosa di utile e dimostrare di aver lavorato bene. Molti gruppi "amministrativi" di Debian operano per designazione, preferendo i volontari che hanno già contribuito efficacemente e dimostrato la loro competenza. La natura pubblica del lavoro di questi gruppi rende possibile ai nuovi collaboratori di osservare e iniziare ad aiutare senza avere nessun privilegio speciale. Questo è il motivo per cui Debian è descritta come una "meritocrazia".
This effective operational method guarantees the quality of contributors in the “key” Debian teams. This method is by no means perfect, and occasionally there are those who do not accept this way of operating. The selection of developers accepted in the teams may appear a bit arbitrary, or even unfair. Furthermore, not everybody has the same definition of the service expected from these teams. For some, it is unacceptable to have to wait eight days for inclusion of a new Debian package, while others will wait patiently for three weeks without a problem. As such, there are regular complaints from the disgruntled about the “quality of service” from some teams.
1.3.2. Il ruolo attivo degli utenti
Ci si potrebbe chiedere se sia rilevante citare gli utenti tra coloro che lavorano all'interno del progetto Debian e la risposta è, definitivamente, si: svolgono un ruolo fondamentale nel progetto. Lungi dall'essere "passivi", alcuni dei nostri utenti utilizzano versioni di Debian in fase di sviluppo inviando, regolarmente, segnalazioni di bug per notificare dei problemi. Altri vanno anche oltre e propongono idee e miglioramenti, presentando una segnalazione con un livello di gravità "wishlist" (lista dei desideri) o inoltrando correzioni al codice sorgente, dette "patch" (vedi
Sezione 1.3.2.3, «Invio di correzioni»).
1.3.2.1. Segnalazione di bug
Lo strumento fondamentale, utilizzato da gran parte del progetto, per l'invio di bug è il Sistema di Tracciamento dei Bug di Debian (Debian BTS). La parte pubblica (l'interfaccia web) consente agli utenti di visualizzare tutti i bug segnalati, con l'opzione per visualizzare un elenco ordinato di bug selezionati in base a vari criteri, come: pacchetto che ne è affetto, gravità, stato, indirizzo del segnalatore, indirizzo del manutentore incaricato, tag, ecc. È anche possibile consultare l'elenco storico completo di tutte le discussioni riguardanti ciascun bug.
In realtà, il BTS Debian è basato su e-mail: tutte le informazioni che memorizza derivano dai messaggi inviati dalle varie persone coinvolte. Ogni e-mail inviata a
12345@bugs.debian.org
sarà assegnata alla cronologia del bug numero 12345. Le persone autorizzate possono "chiudere" un bug scrivendo un messaggio che descrive i motivi della decisione di chiusura a
12345-done@bugs.debian.org
(un bug viene chiuso quando il problema indicato è risolto o non è più rilevante). Un nuovo bug viene segnalato inviando una e-mail a
submit@bugs.debian.org
secondo un formato specifico che identifica il pacchetto in questione. L'indirizzo
control@bugs.debian.org
permette la modifica di tutte le "meta-informazioni" relative a un bug.
Il Debian BTS ha altre caratteristiche funzionali, come ad esempio l'uso di tag per l'etichettatura dei bug. Per maggiori informazioni, vedere
Users can also use the command line to send bug reports on a Debian package with the reportbug
tool. It helps making sure the bug in question hasn't already been filed, thus preventing redundancy in the system. It reminds the user of the definitions of the severity levels, for the report to be as accurate as possible (the developer can always fine-tune these parameters later, if needed, e.g. using the bts
command). It helps writing a complete bug report, without the user needing to know the precise syntax, by writing it and allowing the user to edit it. This report will then be sent via an e-mail server (by default, a remote one run by Debian, but reportbug
can also use a local server).
Questo strumento si rivolge prevalentemente alle versioni di sviluppo, dove i bug verranno risolti. In effetti, i cambiamenti non sono benvenuti in una versione stabile di Debian, con la sola eccezione degli aggiornamenti di sicurezza oppure altri importanti aggiornamenti (se, per esempio, un pacchetto non funziona affatto). La correzione di un bug minore in un pacchetto Debian, aspetterà, perciò, il rilascio della successiva versione stabile.
1.3.2.2. Traduzione e documentazione
Inoltre, i numerosi utenti soddisfatti del servizio offerto da Debian sono interessati a dare un proprio contributo al progetto. Poiché non tutti hanno adeguati livelli di competenza nella programmazione, possono scegliere di aiutare con la traduzione e la revisione della documentazione. Ci sono mailing list specifiche per varie lingue che coordinano questo lavoro.
1.3.2.3. Invio di correzioni
Gli utenti più avanzati potrebbero essere in grado di fornire una correzione ad un programma inviando una patch.
Una patch è un file che descrive le modifiche da apportare ad uno o più file di riferimento. In particolare, conterrà la lista delle righe da rimuovere o aggiungere al codice, e (talvolta) le righe ricavate dal testo di riferimento, per applicare le modifiche nel contesto (permettono l'identificazione della posizione delle modifiche se i numeri di riga dovessero essere cambiati).
Lo strumento utilizzato per applicare le modifiche scritte in questo tipo di file si chiama semplicemente patch
. Lo strumento che le crea è chiamato diff
, e si utilizza in questo modo:
$
diff -u file.vecchio file.nuovo >file.patch
Il file file.patch
contiene le istruzioni per modificare il contenuto del file file.vecchio
trasformandolo nel file.nuovo
. Possiamo inviarlo a qualcuno, che lo può quindi utilizzare per ricreare file.nuovo
dagli altri due, in questo modo:
$
patch -p0 file.vecchio <file.patch
Il file, file.vecchio
, è ora identico a file.nuovo
.
In pratica, la maggior parte del software è attualmente mantenuta nei repository Git ed i collaboratori sono quindi più propensi ad usare git
per recuperare il codice sorgente e proporre modifiche. git diff
genererà un file nello stesso formato di quello che diff -u
farebbe e git apply
può fare lo stesso di patch
.
Mentre l'output di git diff
è un file che può essere condiviso con altri sviluppatori, di solito ci sono modi migliori per inviare le modifiche. Se gli sviluppatori preferiscono ottenere patch via e-mail, solitamente vogliono che tali patch vengano generate con git format-patch
in modo che possano essere integrate direttamente nel repository con git am
. Questo preserva le meta-informazioni dei commit e rende possibile la condivisione di più commit in una volta sola.
This email-based workflow is still popular, but it tends to be replaced by the usage of merge requests (or pull requests) whenever the software is hosted in a platform like GitHub or GitLab — and Debian is using GitLab on its salsa.debian.org
server. On those systems, once you have created an account, you fork the repository, effectively creating a copy of the repository in your own account, and you can then clone that repository and push your own changes in it. From there, the web interface will suggest you to submit a merge request, notifying the developers of your changes, making it easy for them to review and accept your changes with a single click.
1.3.2.4. Altri modi per contribuire
Non solo gli utenti aiutano sé stessi (e gli altri) su argomenti tecnici che li riguardano direttamente, ma discutono anche relativamente ai modi migliori per contribuire al progetto Debian e aiutarlo a progredire — discussioni che spesso portano a proposte di miglioramento.
Dal momento che Debian non spende fondi per auto-promuoversi con campagne di marketing, i suoi utenti svolgono un ruolo essenziale nella sua diffusione, garantendo la sua fama attraverso il passaparola.
Questo metodo funziona piuttosto bene, dal momento che i fan di Debian si trovano a tutti i livelli della comunità del software libero: a partire dalle feste di installazione (workshop in cui gli utenti esperti assistono i nuovi arrivati nell'installazione del sistema) organizzate dai locali
LUG o "Linux User Group" (gruppi di utenti Linux), fino agli stand di associazioni ai grandi convegni tecnologici che si occupano di Linux, ecc.
I volontari realizzano poster, opuscoli, adesivi ed altro materiale promozionale utili al progetto, che mettono a disposizione di tutti e che Debian fornisce, gratuitamente, sul proprio sito web e sul suo wiki:
1.3.3. Team, Blend e sottoprogetti
Fin dall'inizio, Debian è stata organizzata intorno al concetto di pacchetti sorgenti, ognuno con il suo manutentore o gruppo di manutentori. Nel tempo si sono formati svariati team, che assicurano l'amministrazione delle infrastrutture, la gestione di compiti non specifici di un particolare pacchetto (garanzia della qualità, le Policy Debian, installatore, ecc.), mentre le ultime squadre si sviluppano intorno a sotto-progetti e blend.
1.3.3.1. Sottoprogetti e Blend Debian esistenti
A ciascuno la sua Debian! Un sottoprogetto è un gruppo di volontari interessati ad adattare Debian ad esigenze specifiche. Oltre alla selezione di un sottogruppo di programmi destinati ad un particolare ambito (istruzione, medicina, creazione di contenuti multimediali, ecc.), i sottoprogetti si occupano anche di migliorare i pacchetti software esistenti, creare quelli mancanti, adattare il programma di installazione, creare documentazione specifica ed altro ancora. Sebbene una "miscela" potrebbe non essere esattamente la stessa, funziona in modo abbastanza simile e cerca di fornire una soluzione pronta all'uso per gruppi di persone con esigenze specifiche. Si potrebbe dire che "Debian Pure Blends" è il successore dei sottoprogetti.
Questa è una piccola selezione delle Debian Pure Blend attualmente rilasciate:
Debian Junior, offering an appealing and easy to use Debian system for children;
Debian Edu, focused on the creation of a specialized distribution for the academic and educational world;
Debian Med, dedicated to the medical field;
Debian Multimedia, che si occupa di lavori audio e multimediali;
Debian GIS, che si occupa di applicazioni ed utenti di Sistemi Informativi Geografici;
Debian Astro, per astronomi professionisti e hobbisti;
Debian Science, lavora per fornire a ricercatori e scienziati una migliore esperienza nell'utilizzo di Debian;
Freedombox, realizzato per sviluppare, progettare e promuovere server personali con software libero per comunicazioni private e personali;
Debian Games, fornisce giochi in Debian, da quelli arcade e di avventura a quelli di simulazione e strategia;
DebiChem, indirizzata alla chimica, fornisce suite e programmi per chimici.
Molto probabilmente il numero di progetti continuerà a crescere con il tempo e, mano a mano, la percezione dei vantaggi dei Debian Pure Blend aumenterà. Essendo completamente supportati dall'infrastruttura Debian esistente, possono concentrarsi sul lavoro, fornendo un reale valore aggiunto senza doversi preoccupare della sincronizzazione con Debian, in quanto sono sviluppati all'interno del progetto.
1.3.3.2. Team amministrativi
La maggior parte dei team amministrativi sono piuttosto chiusi e reclutano nuovi volontari solo per cooptazione. Il modo migliore per poter entrare a far parte di uno di questi team è quello di assistere in modo intelligente i componenti attuali, dimostrando di aver capito gli obiettivi ed i metodi operativi del team.
Gli ftpmasters hanno il compito di gestire l'archivio ufficiale dei pacchetti Debian. Essi gestiscono il programma che riceve e memorizza automaticamente i pacchetti trasmessi dagli sviluppatori, dopo alcuni controlli, sul server di riferimento (ftp-master.debian.org
).
Essi devono anche verificare le licenze di tutti i nuovi pacchetti, per garantire che Debian possa distribuirli, prima della loro inclusione nell'elenco dei pacchetti esistenti. Quando uno sviluppatore vuole rimuovere un pacchetto, si rivolge a questo team attraverso il sistema di tracciamento dei bug e lo "pseudo-pacchetto" ftp.debian.org.
Il team
Debian System Administrators (
DSA) (
debian-admin@lists.debian.org
), come ci si potrebbe aspettare, è responsabile dell'amministrazione dei server utilizzati dal progetto. Assicura il funzionamento ottimale di tutti i servizi di base (DNS, Web, e-mail, shell, ecc.), installa i software richiesti dagli sviluppatori Debian e prende tutte le precauzioni necessarie per garantire la sicurezza dei sistemi.
I listmaster amministrano il server di posta che gestisce le mailing list. Essi creano nuove liste, gestiscono i messaggi rimbalzati (segnalazioni di mancata consegna) e mantengono i filtri antispam (e-mail indesiderate).
Ogni singolo servizio ha un proprio team di amministrazione, generalmente composto dai volontari che lo hanno installato (e che spesso hanno anche programmato gli stessi strumenti corrispondenti). Questo è il caso del sistema di tracciamento dei bug (BTS), del sistema di tracciamento dei pacchetti,
salsa.debian.org
(server GitLab, vedi riquadro
STRUMENTO GitLab, Git repository hosting e molto altro), i servizi disponibili su
qa.debian.org
,
lintian.debian.org
,
buildd.debian.org
,
cdimage.debian.org
, ecc.
1.3.3.3. Team di sviluppo, Team trasversali
A differenza dei team amministrativi, quelli di sviluppo sono decisamente più aperti, anche a collaboratori esterni. Anche se Debian non ha una vocazione per creare software, il progetto ha bisogno di alcuni programmi specifici per raggiungere i suoi obiettivi. Naturalmente sviluppati sotto una licenza per software libero, questi strumenti fanno uso di metodi provati in altri settori del mondo del software libero.
Debian ha sviluppato da sé poco software, ma certi programmi hanno assunto un ruolo importante, e la loro fama si è diffusa ben oltre i confini del progetto. Buoni esempi sono dpkg
, il programma Debian per la gestione dei pacchetti (è, infatti, l'abbreviazione di Debian PacKaGe, e generalmente si pronuncia "dee-package"), e apt
, uno strumento per installare automaticamente qualsiasi pacchetto Debian e i pacchetti dai quali dipende, garantendo la coesione del sistema dopo un aggiornamento (il suo nome è l'acronimo di Advanced Package Tool, Strumento avanzato di gestione dei pacchetti). I loro team sono, tuttavia, molto più piccoli, poiché per la comprensione complessiva delle operazioni svolte da questo tipo di programmi è necessaria una capacità di programmazione di livello piuttosto elevato.
Il team più importante è probabilmente quello del programma di installazione di Debian,
debian-installer
, che dal suo concepimento nel 2001 ha compiuto un lavoro gigantesco. Sono stati necessari numerosi collaboratori, poiché è veramente difficile scrivere un programma unico in grado di installare Debian su una dozzina di architetture differenti. Ognuna con un proprio meccanismo per l'avvio e un proprio bootloader. Tutto questo lavoro è coordinato dalla mailing list
debian-boot@lists.debian.org
, sotto la direzione di Cyril Brulebois.
Il team (molto piccolo) del programma debian-cd
deve perseguire un obiettivo ancora più modesto. Molti "piccoli" collaboratori sono ognuno responsabile della propria architettura, dal momento che lo sviluppatore principale non può conoscere tutte le particolarità, né il modo esatto per avviare il programma di installazione dal CD-ROM.
Molti team devono collaborare con gli altri in attività di impacchettamento:
debian-qa@lists.debian.org
cerca, ad esempio, di assicurare la qualità del progetto Debian a tutti i livelli. La mailing list
debian-policy@lists.debian.org
sviluppa le Policy Debian secondo tutte le proposte ricevute. I team incaricati di ogni architettura (
debian-architettura@lists.debian.org
) compilano tutti i pacchetti, adattandoli se richiesto, alle particolarità di ogni architettura.