Pardus:Guida Sviluppatori
Da PardusWiki.
Barış Metin <baris@pardus.org.tr>, A. Murat Eren <meren@pardus.org.tr>
Traduzione: M. Palaja
Proofreading: Shane Shields, Görkem Çetin
Abstract: In questo documento si descrive cosa uno sviluppatore dovrebbe conoscere e fare per unirsi al processo di sviluppo del progetto Pardus.
[modifica] Introduzione
In questo documento cercheremo di spiegare come si possa contribuire al supporto di Pardus Linux, sviluppato seguendo la struttura del Progetto Pardus, e quali siano i requisiti per essere uno sviluppatore Pardus. Anche se qui si parla del modello di sviluppo per Pardus, crediamo che tali requisiti si possano applicare a quasi tutte le distribuzioni.
Potete consultare le pagine web di Pardus per ulteriori informazioni richieste per altri documenti, strumenti utilizzati e servizi. Le pagine Pardus possono essere raggiunte all'indirizzo http://www.pardus.org.tr.
[modifica] Cos'è uno sviluppatore?
In poche parole, non è sbagliato dire che il progetto si propone di raggiungere due tipi di obiettivi. Come per ogni distribuzione, tra le operazioni richieste ci si propone di raccogliere il software e preparare l'infrastruttura che permetta di ottenere questo obiettivo e di supportarlo, così come sviluppare nuovi strumenti e tecnologie che formino il cuore della distribuzione.
Con il termine “sviluppatore” intendiamo non solo coloro che scrivono i programmi, ma anche coloro che eseguono ogni singola operazione. Sappiamo che per completare un progetto software si deve lavorare in ogni area, come documentazione, controllo dei bug, materiale visivo, traduzioni, etc., oltre alla programmazione. Anche per Pardus è necessario tutto ciò.
[modifica] Come potrò cominciare?
Innanzitutto è una buona idea seguire gli attuali progetti. Per fare ciò la cosa migliore è osservare per un certo periodo come procedono i lavori. Può essere utile iscriversi alle liste email accessibili dalle pagine web di Pardus e seguirne le discussioni, le operazioni correnti, le segnalazioni di bug, le soluzioni ai bug proposte, e studiare i documenti pubblicati.
Seguendo i metodi descritti si può aiutare nello sviluppo. Puoi aggiungere i tuoi commenti e le tue proposte di soluzione ai bug testando il software, oppure puoi segnalare i nuovi bug che tu rilevi. Puoi contribuire a sviluppare tecnologie innovative e aggiungere nuove caratteristiche oppure puoi supportare un passaggio di un processo che tu credi non funzioni (o funzioni troppo lentamente) e velocizzarlo. In tutto ciò dovresti sempre essere in comunicazione con gli altri sviluppatori. Come per tutte le operazioni che coinvolgono più di una persona, ci si deve conoscere a vicenda.
Le nostre necessità si possono riassumere come qui sotto:
[modifica] Sviluppo del software e messa a punto
Puoi mettere a disposizione le tue conoscenze nello sviluppo di software con l'assistenza nella pulizia della sorgente e aiutando i team che lavorano nel campo delle tecnologie innovative. Questi possono dare le migliori indicazioni sull'aiuto di cui hanno bisogno. Possono essere d'aiuto le liste email di Pardus raggiungibili al sito http://liste.pardus.org.tr/mailman/listinfo.
Puoi esaminare i bug riportati e proporne le soluzioni utilizzando il sistema di bug tracking di Pardus accessibile tramite web.
[modifica] Traduzione
La localizzazione del software libero per far si che sia utilizzabile in perfetto italiano è un'ulteriore nostro obiettivo. A questo scopo puoi lavorare con i team di localizzazione organizzati per quasi tutti i maggiori progetti di software libero. Ne otterremo il maggior beneficio se darai la priorità al software selezionato per il progetto Pardus.
In breve, supporta gli sforzi di localizzazione. Oltre alla pura traduzione, cerca di migliorarne la qualità. Aiutando i lavori di traduzione entrerai a far parte di un'importante missione aiutando non solo Pardus, ma anche tutte le altre distribuzioni che potranno avere pacchetti Linux senza problemi di italiano.
[modifica] Test e segnalazione bug
Puoi segnalare i bug testando il software da noi scelto. Puoi controllare i bug in altre distribuzioni e riportare la situazione. Sapere che lo stesso bug esiste anche in altre distribuzioni ci può aiutare a trovarne una corretta soluzione. Se tale problema viene risolto – o non è mai esistito – in una particolare distribuzione, se ne troverà una soluzione più velocemente esaminando il lavoro fatto a riguardo da quella distribuzione. Puoi raggiungere il nostro sistema di bug tracking al sito http://bugs.pardus.org.tr/
[modifica] Design grafico e multimedia
Se hai talento in questo settore, puoi essere d'aiuto dove è richiesta una conoscenza nella grafica, come il set delle icone, i font types e i temi dei colori. Puoi chiederci aiuto tramite le liste email se ti serve materiale visivo da usare nel tuo lavoro.
[modifica] Documentazione
Puoi anche supportare i progetti già iniziati di documentazione. Oltre ai documenti per gli utenti, puoi preparare documenti per gli sviluppatori che si sono uniti da poco al progetto. Puoi aiutarci a tenere aggiornate le pagine web, anche quelle scritte in altre lingue.
[modifica] Diffusione
Puoi supportare la diffusione del progetto ed incoraggiare altre persone ad interessarsene.
Ci sono sicuramente altri settori nei quali serve aiuto, oltre a quelli già citati. Ne potrai trovare di nuovi partecipando alle discussioni nelle liste email, avanzando proposte, proponendo critiche costruttive e miglioramenti collegati alla distribuzione.
[modifica] Qual è la responsabilità dello sviluppatore?
La risposta può variare a seconda del settore nel quale cominci a lavorare, ma possiamo elencare le responsabilità di base valide per tutti gli sviluppatori. Si tratta soprattutto di punti basilari per lavorare insieme in armonia. A tale scopo, anche se ciò che diremo è generalmente valido, potrai trovare un sistema personale per cooperare mano a mano che aumenterà la tua familiarità con gli amici e l'ambiente di lavoro.
[modifica] Continuità
Uno sviluppatore dovrebbe essere preparato a lavorare con continuità al lavoro intrapreso. Per continuità non intendiamo un lavoro da 24 ore su 24 e 7 giorni su 7, bensì una continuità sull'argomento con cui si ha a che fare. Poiché aree diverse sono connesse tra loro, i singoli sviluppatori dovrebbero adeguarsi alla velocità degli altri.
[modifica] Precisione
Nel progetto potresti dover lavorare su un argomento con più di uno sviluppatore. Inoltre altri sviluppatori possono dipendere dal tuo lavoro. Per tali ragioni non solo la continuità è di grande importanza, ma anche la precisione del tuo lavoro, in proporzione a quanto incide sul lavoro degli altri. Soprattutto se lavori su uno dei principali repository di sviluppo devi considerare che gli altri sviluppatori dipendono dal tuo lavoro in ogni passaggio. Devi essere sicuro che ogni cambiamento – anche minimo – tu debba apportare, non impedisca agli altri di portare avanti il proprio lavoro.
[modifica] Determinazione
Se sei tu ad avere il potere di decisione sul progetto al quale lavori, cambiare troppo spesso le decisioni rende difficile per gli altri sviluppatori seguire il progetto e, cosa più importante, fa si che gli sviluppatori che dipendono da te abbiano difficoltà nel lavoro. Quindi sarà utile prendere decisioni ben ponderate e prima di applicarle ascoltare le opinioni degli altri.
Se ad un certo punto credi di dover comunque cambiare decisione, fallo rendendo partecipi gli altri sviluppatori e – se il lavoro precedente è già in uso – utilizzando uno spazio “sperimentale” che non crei loro danni.
[modifica] Comunicazione
Sarà sempre una saggia decisione rendere partecipi gli altri delle tue decisioni, così come dei progressi e delle modifiche – anche minime - che apporti. A tale scopo puoi arruolare nuovi sviluppatori – di cui c'è sempre bisogno – per il soggetto a cui stai lavorando, puoi collaborare con gli sviluppatori per procedere più velocemente. In questo modo se in futuro avrai bisogno d'aiuto verrà trovata una soluzione più velocemente, poiché altri sviluppatori sanno ciò che tu vuoi ottenere. Per le comunicazioni puoi utilizzare le liste email, i documenti che preparerai, oppure informazioni che aggiungerai ai cambiamenti da te fatti.
[modifica] Richiesta di adesione di nuovi sviluppatori
C'è sempre spazio per nuovi sviluppatori. Anche tu puoi diventare uno sviluppatore ufficiale Pardus. Il prerequisito di accettare la responsabilità di essere un nuovo sviluppatore non è sempre sufficiente, ma siamo comunque entusiasti di accettare nuovi sviluppatori e delegare nuove responsabilità. Per dettagli, continua a leggere...
[modifica] Chi può fare domanda?
Chiunque lavori per Pardus e accetti le responsabilità descritte in questo documento può fare domanda come nuovo sviluppatore. Il principale canale di comunicazione sono le liste email. Per accettare la domanda si valuterà la determinazione e lo stile di lavoro del richiedente. A tale scopo puoi scegliere un lavoro adatto a te e lavorarci sopra prima di fare domanda. Condividendo il lavoro con gli altri sviluppatori permetterai loro di esaminarlo e di fare la tua conoscenza.
Per esempio può essere un buon punto di partenza lavorare con il software già presente nei repository, proporre nuove patch e soluzioni, esaminare e testare le nuove soluzioni proposte da altri e riportare i tuoi risultati.
[modifica] Come si fa domanda?
Sarà sufficiente inviare una email a admins@pardus.org.tr con indicato:
- 1. l'oggetto di sviluppo a cui stai lavorando
- 2. altri argomenti su cui vuoi lavorare
- 3. l'indirizzo email/nome utente da te usato per il sistema di bug-tracking
- 4. i tuoi settori di specializzazione
- 5. se possibile il nome di uno sviluppatore che conosca il tuo lavoro e faccia da referente
Devi includere il nome utente e il testo cifrato (creato con htpasswd) della tua password per l'applicazione email. Questo ci permette di aggiungere tali dati qualora sia richiesto un controllo di identità.
[modifica] Creare una password con htpasswd
Puoi creare password e nome utente utilizzando il programma htpasswd e allegare il file ottenuto alla tua email. A tale scopo usa il comando seguente:
$ htpasswd -c password_file user_name New password: Re-type new password: Adding password for user user_name
Otterrai il “password_file” da allegare alla tua email.
[modifica] Creare una password con perl
Usa il seguente comando:
perl -e "print crypt('yourpassword','xy'),\"\n\";"
Questo crea solo la password; nell'email dovrai anche indicare il nome utente che intendi usare.
[modifica] Creare una password con python
Usa il seguente comando:
python -c "import crypt; print crypt.crypt('password', 'xy')"
Anche in questo caso otterrai solamente la password. Indica nell'email il nome utente.
[modifica] Repository Subversion
In Pardus il processo di sviluppo avviene tramite un sistema di controllo Subversion. Si tratta di un sistema di tracking open source, una struttura di sviluppo che permette a sviluppatori di diverse applicazioni di lavorare insieme senza la preoccupazione di danneggiare il lavoro reciproco. Grazie a ciò i singoli processi di sviluppo possono essere tracciati a ritroso, si possono vedere i cambiamenti apportati e farli ritornare allo stato originale.
Al momento ci sono due repository Subversion nella struttura di Pardus.
[modifica] Repository Pardus
Il repository Pardus è quello in cui si mantengono i prodotti sviluppati all'interno del progetto. Tutto il software sviluppato per Pardus è mantenuto all'interno di questo repository. Lo si trova all'indirizzo https://svn.pardus.org.tr/pardus. Mantiene i repository per i pacchetti sorgente dove si trovano i pacchetti in formato .pisi
Maggiori informazioni si trovano nel documento Pardus Depo Politikası (Pardus Repository Policy).
[modifica] Gerarchia delle cartelle del repository
Ogni repository Subversion contiene una ben determinata gerarchia per le cartelle.
Ci sono tre cartelle principali: trunk, tags, repos
[modifica] trunk/
All'interno di questa cartella vi è un continuo lavoro.
Al suo interno ciascun progetto ha la propria cartella (documenti, pagine web, progetti software, etc.).
tags/
In questa cartella viene etichettato e copiato il lavoro fatto per ogni modulo in trunk. Al suo interno ci sono tre cartelle:
tags/RELEASE/: usata dai moduli o dai software per indicare il proprio numero di versione. Per esempio laversione 0.2 di tasma è indicata con tags/RELEASE/tasma-0.2
tags/BLACKHOLE/: vi si trovano i progetti il cui sviluppo è bloccato per mancanza di sviluppatori o per la non ulteriore necessità del progetto stesso. Se serve recuperarli è sufficiente copiarli in /trunk.
tags/RESTRUCTURED/: vi si collocano i software in stato di totale ristrutturazione e i cui file vecchi non sono più utilizzati. per esempio il progetto “abc” che si è ricominciato a scrivere il 28 maggio 2005 si troverà in tags/RESTRUCTURED/abc-2005-05-28/.
[modifica] repos/
Qui gli sviluppatori possono portare avanti un modulo sperimentale senza intaccare il lavoro degli sviluppatori impegnati nello stesso modulo sotto /trunk. Possono lavorare creando la propria cartella sotto repos/
(secondo una regola valida per i repository dei pacchetti, la documentazione relativa a tali progetti si trova in repos/doc)
[modifica] Utilizzo di Subversion
E' disponibile un dettagliato manuale utente. Sono, inoltre, disponibili informazioni alla sezione FAQ nel web del progetto Subversion. In questa sezione si elencano i principali comandi di uso pratico con l'aiuto di esempi.
[modifica] Come posso sapere se ho Subversion nel mio sistema?
Il sistema più rapido è valutare il risultato del comando svn –version. Quella seguente è un'indicazione positiva:
evreniz@jaco:~$ svn --version svn, version 1.0.3 (r9775) compiled May 19 2004, 21:28:49 Copyright (C) 2000-2004 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol. - handles 'http' schema - handles 'https' schema * ra_local : Module for accessing a repository on local disk. - handles 'file' schema * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' schema evreniz@jaco:~$
Se non è presente, puoi ottenere il pacchetto per la tua distribuzione al sito http://subversion.tigris.org/project_packages.html e installarlo.
[modifica] Che cos'è un repository?
Un repository è una sezione del disco in cui sono conservate tutte le ultime versioni, le versioni precedenti all'ultima e i cambiamenti tra le diverse versioni dei pacchetti, comprese le informazioni riguardanti il loro utente, la data e le funzioni, ottenibili tramite diversi metodi.
[modifica] Come posso vedere quali cartelle sono contenute in un repository?
Un singolo repository può contenere più cartelle disposte secondo una gerarchia simile a quella delle cartelle nel disco. Si può, quindi visualizzarne il contenuto senza dover copiare l'intero repository nel tuo disco. La lista delle cartelle si può visualizzare nel seguente modo:
$ svn ls http://svn.pardus.org.tr/uludag repos/ tags/ trunk/ $ svn ls http://svn.pardus.org.tr/uludag/trunk COMAR/ comar_prototip_old/ web/ $ svn ls http://svn.pardus.org.tr/uludag/trunk/COMAR COMAR-1.sxw COMARd/ CSL/ OM/ SlicerAPI/ confparser/ $ svn ls http://svn.uludag.org.tr/uludag/trunk/COMAR/confparser GenericParser.py README branchedParser.py comar_configparser.png config_files/ confparser.py flatParser.py sectionedParser.py $
[modifica] Come ottengo la copia di una cartella del repository ?
Con il comando “svn co” si crea una copia del repository. Creata la copia con questo comando non si ottengono altri processi.
$ svn co http://svn.pardus.org.tr/uludag A uludag/trunk ... ...
Puoi gestire il repository come fosse una URL. In tal modo puoi ottenere qualunque sotto-cartella.
$ svn co http://svn.pardus.org.tr/uludag/trunk/COMAR A COMAR/COMAR-1.sxw A COMAR/CSL ... ...
[modifica] Come posso sapere se la mia copia è aggiornata?
Il comando “svn update” aggiorna il tuo repository e mostra gli ultimi cambiamenti. Con il comando da solo aggiorna l'intera cartella nella quale ti trovi; oppure puoi specificare l'indirizzo di una cartella o di un file.
~/work/uludag/[...]/uludag/trunk $ svn update U tasma/modules/tasmanet/device.cpp U tasma/modules/tasmanet/devicesettings.cpp U tasma/modules/tasmanet/device.h U tasma/modules/tasmanet/devicesettings.h Updated to revision 158. ~/work/uludag/[...]/uludag/trunk $
[modifica] Cosa significano i simboli vicino ai file?
I simboli che appaiono nei file durante il lavoro di aggiornamento o ricerca in svn informano sul tipo di cambiamento apportato al successivo file.
Vicino ai file si può trovare una delle seguenti lettere:
- A aggiunto
- D cancellato
- U aggiornato
- G unito (l'ultimo aggiornamento ottenuto dal repository è stato unito e fuso con il file al quale stai lavorando in locale)
- C conflitto (gli ultimi aggiornamenti entrano in conflitto con i tuoi cambiamenti)
[modifica] Ho modificato alcuni file; cosa devo fare ora?
Usa il comando “svn status” per vedere i cambiamenti da te fatti. Puoi ovviamente aggiungere una URL al comando. Qui sotto puoi vedere l'esempio di un file aggiunto all'ultima copia aggiornata del repository, un file rimosso e due file modificati:
~/work/[...]/trunk/COMAR/comar $ svn status A COMARd/csl/degisiklik D COMARd/csl/loader.py M COMARd/COMARValue.py M comar-call/rpc.c ~/work/[...]/trunk/COMAR/comar $ svn status COMARd/csl/COMARValue.py M COMARd/COMARValue.py ~/work/[...]/trunk/COMAR/comar $
Puoi anche apprendere cosa hai modificato di particolare nel file con il comando ``svn diff:
~/work/[...]/trunk/COMAR/comar $ svn diff comar-call/rpc.c
Index: comar-call/rpc.c
===================================================================
--- comar-call/rpc.c (revision 158)
+++ comar-call/rpc.c (working copy)
@@ -146,6 +146,7 @@
if (len == 0) break;
if (len == -1) {
puts("connection broken too soon");
+ //totally different change
break;
}
printf("RECV[%s]\n\n", buf);
~/work/[...]/trunk/COMAR/comar $
[modifica] Ho aggiunto un nuovo file, ma c'è il simbolo "?" affianco...
Se stai lavorando con una copia del repository e vuoi creare un nuovo file dovresti informarne la copia locale con “svn add” (ci sono anche i comandi “svn copy” e “svn del”). Spieghiamo perché: poniamo che tu desideri compilare e testare un'applicazione che si trova nella tua copia locale. In questo caso verranno creati dei file che tu non vuoi inviare al repository principale come Makefiles e *.m4 di cui solamente tu hai bisogno. Con “svn add” aggiungi solo i file che vuoi aggiungere.
~/work/[...]/COMARd/csl/sample $ svn status ~/work/[...]/COMARd/csl/sample $ touch newscript.csl ~/work/[...]/COMARd/csl/sample $ svn status ? newscript.csl ~/work/[...]/COMARd/csl/sample $ svn add newscript.csl A newscript.csl ~/work/[...]/COMARd/csl/sample $ svn status A newscript.csl ~/work/[...]/COMARd/csl/sample $
[modifica] Voglio convertire all'originale i file che ho modificato.
Puoi usare il comando “svn revert”:
~/work/[...]/trunk/COMAR/comar $ svn status A COMARd/csl/thechange D COMARd/csl/loader.py M COMARd/COMARValue.py M comar-call/rpc.c ~/work/[...]/trunk/COMAR/comar $ svn revert comar-call/rpc.c Reverted 'comar-call/rpc.c' ~/work/[...]/trunk/COMAR/comar $ svn status A COMARd/csl/thechange D COMARd/csl/loader.py M COMARd/COMARValue.py ~/work/[...]/trunk/COMAR/comar $
E' anche possibile riconvertire periodicamente tutti i file...
~/work/[...]/trunk/COMAR/comar $ svn revert . -R Reverted 'COMARd/csl/thechange' Reverted 'COMARd/csl/loader.py' Reverted 'COMARd/COMARValue.py' ~/work/[...]/trunk/COMAR/comar $ svn status ~/work/[...]/trunk/COMAR/comar $
[modifica] Voglio inviare i file che ho modificato; come faccio?
Se sei sicuro del file da te modificato, usa “svn committ” per inviare i cambiamenti al repository. Puoi inviare un singolo file o un'intera cartella. Con “svn committ” svn apre un file con elencate le modifiche da te apportate per permettere agli altri di vederle e affinchè siano catalogate per un eventuale rintracciamento nel repository. Con SVN_EDITOR puoi configurare l'editor di testo aperto come preferito:
~/work/[...]/COMARd/csl/sample $ SVN_EDITOR="vi" svn commit ~/work/[...]/COMARd/csl/sample $ SVN_EDITOR="mcedit" svn commit ~/work/[...]/COMARd/csl/sample $ SVN_EDITOR="kwrite" svn commit
Non appena scrivi le modifiche apportate all'editor di testo, salvi e chiudi l'editor, svn comincia ad inviare le modifiche alla tua copia locale del repository.
[modifica] Posso conoscere altri comandi?
Puoi avviare Subversion e impararne i comandi. “svn help command_name” ti da informazioni dettagliate sul comando cercato, mentre “svn help” genera una lista di comandi.
$ svn help usage: svn <subcommand> [options] [args] Type "svn help <subcommand>" for help on a specific subcommand. Most subcommands take file and/or directory arguments, recursing on the directories. If no arguments are supplied to such a command, it will recurse on the current directory (inclusive) by default. Available subcommands: add blame (praise, annotate, ann) cat checkout (co) cleanup commit (ci) copy (cp) delete (del, remove, rm) diff (di) export help (?, h) import info list (ls) log merge mkdir move (mv, rename, ren) propdel (pdel, pd) propedit (pedit, pe) propget (pget, pg) proplist (plist, pl) propset (pset, ps) resolved revert status (stat, st) switch (sw) update (up)
Subversion è uno strumento per il controllo della versione. Per ulteriori informazioni vedi http://subversion.tigris.org/
Per informazioni dettagliate su un comando subversion:
$ svn help add add: Put files and directories under version control, scheduling them for addition to repository. They will be added in next commit. usage: add PATH... Valid options: --targets arg : pass contents of file ARG as additional args -N [--non-recursive] : operate on single directory only -q [--quiet] : print as little as possible --config-dir arg : read user configuration files from directory ARG --force : force operation to run --auto-props : enable automatic properties
--no-auto-props : disable automatic properties
Comandi e FAQ si trovano al sito http://subversion.tigris.org/project_faq.html oppure puoi leggere documentazione su Subversion al sito http://svnbook.red-bean.com
[modifica] Regole per l'uso di Subversion
Il repository Subversion è condiviso da tutti gli sviluppatori; lo si deve quindi utilizzare in modo efficiente ed organizzato.
Le regole sono quelle rispettate dagli sviluppatori con il privilegio di scrittura nei repository di Pardus.
[modifica] Lavorare sempre in un repository aggiornato
Più aumentano gli sviluppatori, più frequenti saranno gli aggiornamenti. Prima di cominciare il tuo lavoro aggiorna sempre il repository con “svn update”, per evitare conflitti tra quello che fai tu e il resto del lavoro.
[modifica] Rifletti prima di inviare
Pensa due volte prima di inviare le tue modifiche al repository Subversion. I tuoi dati influenzeranno il lavoro degli altri. Quindi è di grande importanza seguire i queste indicazioni:
- 1.Non inviare un codice non funzionante.
- 2.Aggiorna sempre il tuo repository prima di inviare per verificare che i nuovi aggiornamenti non siano in conflitto con i tuoi.
- 3.Fai attenzione a ciò che invii. Controlla sempre le tue modifiche con “svn diff” prima di inviarle.
- 4.Verifica empre i cambiamenti che fai. Meglio ancora: verificali due volte!
[modifica] Aggiungi una descrizione sulle tue modifiche
Le descrizioni dovrebbero indicare i cambiamenti apportati nel modo più esteso possibile. Cerca di focalizzarti sui file da te modificati; al limite, puoi includere tutte le descrizioni che non si ricavano con “svn diff”.
Non fare ciò impedisce la comprensione delle modifiche apportate.
[modifica] Attieniti ai piani di lavoro
Se esiste un piano di lavoro per la distribuzione, o se lo sviluppatore principale del progetto cui partecipi ha definito un piano, cerca di rispettarlo.
Per eventuali difficoltà in tale senso devi riferirle nelle liste email, oppure avvertire direttamente lo sviluppatore principale.
Se i cambiamenti apportati riguardano anche altre componenti informane anche gli altri sviluppatori. Per assicurarti che tutti gli sviluppatori conoscano l'aggiornamento principale che tu hai fatto, invia sempre un messaggio nelle liste email.
[modifica] Assumiti la responsabilità per le modifiche che hai apportato
Se l'aggiornamento da te apportato crea un problema, assumitene la responsabilità e risolvilo tu stesso, oppure aiuta gli altri a farlo.
[modifica] Rispetta i principi generalmente accettati
Segui le regole accettate durante le discussioni tra sviluppatori e assicurati che il tuo lavoro non le violi. Se non sei sicuro comunica con gli altri.
[modifica] Immetti il numero del bug nel sistema di “bug tracking” quando risolvi un bug
Per sincronizzare il sistema di bug tracking con gli aggiornamenti nel repository, notifica il bug che hai risolto e poi chiudilo nel sistema di bug tracking.
[modifica] Aggiorna i file di cui sei responsabile
Aggiorna solamente i file di tua pertinenza. Se trovi un bug in un altro file discutine nelle liste email o direttamente con lo sviluppatore e solo dopo aggiorna il repository. Se lo sviluppatore non accetta le tue modifiche, rispettalo.
[modifica] Non aggiungere al repository i file creati automaticamente
Non aggiungere file come Makefile, Makefile.in, scripts di configurazione, etc., che vengono creati dopo la compilazione. Verrebbero ricevuti come aggiornamento dagli altri sviluppatori. Spesso vengono riconosciuti come bug.
[modifica] Effettua gli aggiornamenti “atomic”
Invia tutti in una volta i cambiamenti relativi ad un aggiornamento/miglioramento. Subversion ti permette di inviare più di un file alla volta. Vice versa altri sviluppatori potrebbero risultare confusi da invii separati e non percepire i miglioramenti da te apportati.
Riferimenti
- 1) Metin, Barış & Onur, Çağlar (Novembre 2004). Ulusal Dağıtıma Nasıl Yardım Ederim? http://www.pardus.org.tr
- 2) Metin, Barış (Novembre 2004). Paketler Deposu Yeni Geliştirici Başvurusu. http://www.pardus.org.tr
- 3) Eren, A. Murat (Novembre 2004). Subversion Deposu Kullanma Kılavuzu. http://www.pardus.org.tr
- 4) Barth, Andreas (2005). Debian Developer's Reference. http://www.debian.org/doc/manuals/developers-reference/
- 5] Fox, Tammy & Pennington, Havoc (2003). Fedora Project Developer's Guide. http://fedora.redhat.com/participate/developers-guide/
- 6) KDE (2004). Applying For a KDE CVS Account. http://developer.kde.org/documentation/misc/applycvsaccount.php
- 7) KDE (2004). KDE CVS Commit Policy. http://developer.kde.org/policies/commitpolicy.html

