[Linux-Biella] [RFC] Come e perche' partecipare ad un progetto Open Source

[Paolo Ciarrocchi]

[scrivo questa mail senza la presunzione di insegnare qualcosa ma semplicemente
 per il desiderio di condividere le mie esperienze ed il mio pensiero in merito
 alla collaborazione in progetti Open Source. Penso sia giusto per un LUG
 educare e informare i propri iscritti/simpatizzanti in merito a
questo argomento]

* Perche' partecipare ad un progetto Open Source
I motivi che spingono una persona a partecipare e contribuire ad un progetto
Open Source sono tanti, tuttavia ritengo che il principale sia il divertimento.
Partecipare "for fun" significa sentirsi parte del progetto, sentirsi
parte della
comunita' che opera nel progetto, significa sentirsi utile, significa
confrontarsi
con persone piu' brave e piu' intelligenti di noi e significa imparare
a comunicare
(e questa e' forse la cosa piu' difficile).

* Come partecipare ad un progetto Open Source
Non c'e' bisogno di essere programmatori per partecipare ad un progetto,
un buon modo per avvicinarsi ad un progetto e' quello di segnalare BUG/Problemi
che riscontriamo durante l'uso dei nostri programmi preferiti.
_MAI_ pensare che un problema appena riscontrato venga notato e
segnalato da altri
utenti, e' dovere di chi crede nell'Open Source spendere qualche
minuto per capire
come e dove segnalare il problema che abbiamo appena riscontrato.
Ci sono progetti che usano tool web di BUG tracking e altri progetti
che gestiscono
le segnalazioni dei fault nella mailing list usata per lo sviluppo del progetto
@bilugcms - questo e' il motivo per cui credo sia _sbagliato_ invitare
gli utenti
del vostro progetto a contattare privatamente gli sviluppatori.
I progetti Open Source vivono attorno alla mailing list di sviluppo.

Un altro modo di partecipare attivamente ad un progetto e' quello di migliorarne
la documentazione. Capita a tutti di leggere un documento e faticare a
capire le
indicazioni che contiene. Appena il suo contenuto sara' piu' chiaro potremo
migliorare il documento proponendo delle modifiche.

Infine, se sappiamo programmare (anche in modo assolutamente
amatoriale) possiamo
contribuire facendo bug fixing e/o sviluppando nuove funzionalita'.

Un buon progetto Open Source deve invogliare i suoi utenti alla collaborazione
condividendo _tutto_ cio' che riguarda il progetto, dal suo codice
alla sua roadmap
basando la gestione del progetto sulla trasparenza.
Le modifiche al codice sono condivise immediatamente dopo la scrittura rendendo
possibile commentare, studiare, migliorare il codice _prima_ che questa sia reso
parte del progetto.
@bilugcms - questo e' il motivo per cui _io_ proprio non capisco
perche' le patch
al cms sono spesso condivise solo dopo che le stesse sono applicate a
www.bilug.it
e sempre condivise quando la nuova release e' considerata da voi pronta.

* Strumenti
Il modo migliore per proporre e condividere modifiche al codice/documentazione
e' il semplice uso dei comandi diff e patch.
La produzione di "unified patches" (diff -u) rende semplice la visione di quanto
viene rimosso e aggiunto da ogni singola modifica.
Essendo io un utente di GIT suggerisco di usare il seguente workflow.
- Scaricare il sorgente del programma in questione
- cd dir sorgete
- git init (per inizializzare il repository)
- git add . (per chiedere a GIT di fare il tracking di tutti i file)
- git commit -a -m "Primo commit"
- git checkout -b temp (per creare e fare il checkout di una branch
con nome temp)
- Hack, hack, hack
- git commit -a (per scrivere il messaggio di log del singolo commit)
- hack, hack, hack
- git commit -a (per scrivere il messaggio di log del singolo commit)

Ora siamo pronti a condividere il lavoro che abbiamo svolto.
- git format patch -n --cover-letter -o /dir/di/destinazione

Questo produce una serie di patch numerate (@bilugcms - notare l'uso
del flag -n per numerare le patch)
e crea una patch 0/N contenente un messaggio introduttivo alla serie.
Esempi:
- Cover letter creata con git format patch
  http://ml.bilug.linux.it/pipermail/bilugcms/2009-February/000426.html
- Cover letter "manuale"
  http://ml.bilug.linux.it/pipermail/bilugcms/2009-February/000550.html

Possiamo inoltre creare un file mbox per importare con piu' facilita'
le patch nel nostro
client di posta preferito:
- cd /dir/di/destinazione
- cat *.patch > patch.mbox
- Import del file mbox nel client di posta
oppure possiamo generare direttamente il file patch.mbox
- git format patch -n --cover-letter --stdout > patch.mbox

Una volta inviate la patch in lista riceveremo dei commenti e dovremo
probabilmente apportarne delle modifiche.
Il modo piu' semplice per farlo e' quello di aggiungere dei commit
alla branch tempo e poi usare il comando
- git rebase -i origin
per compiere in maniere _interattiva_ le seguenti operazioni
- cambiare l'ordinamento dei commit
- Fondere due o piu' commit
- Modificare uno o piu' commit

Creare le nuove patch, inviarle nuovamente in lista e se necessario
apportare ulteriori modifiche.

Ogni singola patch/commit deve essere accompagnata da un changelog,
queste patch sono molto difficile da leggere per chi non e' l'autore:
http://ml.bilug.linux.it/pipermail/bilugcms/2009-February/000549.html
http://ml.bilug.linux.it/pipermail/bilugcms/2009-February/000548.html
Questa invece *cerca* di essere piu' descrittiva:
http://ml.bilug.linux.it/pipermail/bilugcms/2009-February/000429.html

Ora siete pronti a prendere parte ad un progetto ;-)

-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://mypage.vodafone.it/