Manuale per sviluppatori Gentoo

Indice:

• Introduzione
  Questa parte copre aspetti da applicare nella maggior parte delle aree dello sviluppo di Gentoo. Questa sezione è rilevante soltanto se si è uno sviluppatore Gentoo, altrimenti la si può saltare.
  1. Introduzione
     Questa sezione definisce gli scopi del manuale per gli sviluppatori Gentoo.
  2. Diventare uno sviluppatore
     Questa sezione mira a spiegare come diventare uno sviluppatore Gentoo.
  3. Cosa si ottiene
     Questa sezione delinea i servizi disponibili agli sviluppatori Gentoo.
  4. Aiuto per i nuovi sviluppatori
     Questa sezione fornisce aiuto ed istruzioni ai nuovi sviluppatori.
  5. Gerarchia degli sviluppatori
     Questa sezione delinea la gerarchia degli sviluppatori Gentoo e dello sviluppo.
  6. Politica membri dello Staff
     Questa sezione delinea le politiche di reclutamento e ritiro per i membri dello staff di Gentoo.
• Politiche
  Questa parte copre le differenti politiche che ci si aspetta che gli sviluppatori rispettino quando effettuano il commit di elementi su CVS.
  1. Politica per gli Ebuild
     Questa sezione delinea la politica che ogni ebuild del Portage deve seguire.
  2. Politica di Etiquette
     Questa sezione delinea la politica di etiquette per gli sviluppatori Gentoo.

A. Introduzione

1. Introduzione

1.a. Introduzione

Lo scopo di questo manuale è quello di definire le regole per lo sviluppo di Gentoo, e informare lo sviluppatore riguardo alle regole, gli standard e le procedure che Gentoo ritiene opportuno usare come cuore del sistema di sviluppo.

Questo manuale non è inteso come una guida universale per tutto - le opportunità che si hanno sono infinite, questo manuale è scritto per insegnare i principi che probabilmente possono aiutare a diventare un buon sviluppatore Gentoo - il resto spetta a chi vuole diventarlo!

Sia i nuovi sviluppatori Gentoo che quelli veterani aventi dubbi su qualsiasi argomento possono scrivere liberamente alla mailing list gentoo-dev oppure sul canale IRC #gentoo-dev.

1.b. Requisiti

Prima di iniziare a lavorare, è importante avere una installazione di Gentoo funzionante sia per la documentazione che per gli scopi dello sviluppo, inoltre si raccomanda anche di avere delle buone conoscenze dei temi trattati nella sezione ``Lavorare con Gentoo`` del Manuale per l'utente, utile durante il lavoro di sviluppo.

La maggior parte di questa guida è rivolta agli sviluppatori, ma, se l'unico interesse è quello di vedere come viene eseguito il lavoro per lo sviluppo di Gentoo, questa guida potrebbe dare degli utili chiarimenti.

Il modo migliore per avere notizie [ e la possibilità di diventare uno sviluppatore Gentoo! ] è di compilare accurati report dei bug su Gentoo Bugzilla, con (se possibile) le relative patch, e di aiutare con tutto ciò si crede possa migliorare Gentoo fornendo patch per nuove caratteristiche, nuovi ebuild oppure risolvendo problemi esistenti.

2. Diventare uno sviluppatore

2.a. Introduzione

Ci sono diversi modi, discussi in questa sezione, per diventare uno sviluppatore Gentoo. Ci sono pure diversi passi che le nuove "reclute" devono compiere prima di diventare sviluppatori ufficiali.

2.b. Aiutare

Prima di tutto, per poter richiedere di diventare uno sviluppatore si può sia proporsi per un posto vacante, o anche soltanto aiutare sia in veste di supporto utenti oppure registrato report sui bug - il vasto numero di gente che contribuisce a Gentoo viene notato e si cerca di premiarli dando loro la possibilità di diventare sviluppatori Gentoo. Gentoo ha diversi percorsi, ed il "Gentoo Developer Relations Recruitment Team" (Gruppo di Reclutamento e Coordinamento Sviluppatori) è sempre alla ricerca non soltanto di sviluppatori - autori di documentazione e mantenitori di infrastrutture sono allo stesso livello di importanza per permettere a questa distribuzione di funzionare al meglio.

È opportuno verificare i posti vacanti per gli sviluppatori nella GMN, come pure nei topic del canale #gentoo-bugs su irc.freenode.net - se ci si sente all'altezza è possibile proporsi per uno di questi compiti, cercando di trovare un mentore disposto a fare da garante oppure contattando i Reclutatori Gentoo dove sarà possibile trovarne uno. Non creare autonomamente bug "New developer", in quanto è compito del mentore effettuare questa operazione, e qualsiasi bug di questo tipo verrà chiuso.

2.c. Mentori

Ogni nuovo sviluppatore deve avere un mentore, ovvero uno sviluppatore Gentoo esistente con la responsabilità di guidare un nuovo sviluppatore e di dargli una mano dopo che quest'ultimo sarà passato attraverso il processo di reclutamento.

Un mentore deve assistere il nuovo sviluppatore fornendogli aiuto e chiarimenti riguardo ad ogni quesito, come pure delineargli le sue responsabilità nei confronti di Gentoo, specialmente quelle in relazione ai suoi compiti iniziali.

Una volta che sviluppatore e mentore si sono accordati, il mentore deve inserire un bug e assegnarlo ad un reclutatore Gentoo - la pagina Reclutatori Gentoo (in inglese) spiega in dettaglio le informazioni necessarie da inserire.

2.d. Attesa

Ogni nuovo sviluppatore deve passare un periodo di attesa che dura almeno un mese, che dipende sia da quanto il mentore ritiene preparato lo sviluppatore sia dal feedback da parte di altri membri dello staff. Durante questo periodo, il nuovo sviluppatore deve completare un test che verrà controllato dal suo mentore ed dai Reclutatori Gentoo, per assicurarsi che lo sviluppatore sia "pronto". In alcuni casi speciali, il periodo di attesa è determinato dal capo dei Reclutatori Gentoo e/o da quello del Coordinamento Sviluppatori.

Vengono proposti due test : il test ebuild, e il test staff. Gli sviluppatori che vogliono lavorare solamente sull'infrastruttura, GLSA o qualsiasi altra area non-ebuild devono fare il test staff, ogni sviluppatore che avrà bisogno di fare cambiamenti al Portage tree deve fare il test ebuild.

Una volta che il nuovo sviluppatore ha completato il test, deve spedirlo al mentore che sarà responsabile di controllarlo assieme ai Reclutatori Gentoo. Se le risposte corrette del test sono sufficientemente adeguate allora il processo di reclutamento può proseguire. Altrimenti, il nuovo sviluppatore può rifare il test, sempre ammesso che venga terminato durante il periodo di attesa.

In più, un nuovo sviluppatore deve essere reattivo a qualsiasi interrogazione posta da qualsiasi membro dei reclutatori - ogni sviluppatore che non risponde immediatamente vedrà chiuso il suo bug "New developer", che potrà essere riaperto a discrezione dei reclutatori Gentoo.

2.e. Raggiungere l'obiettivo

Dopo che il quiz verrà controllato e ritenuto sufficientemente adeguato dal mentore e dai reclutatori Gentoo, bisogna inviare loro una chiave pubblica SSH2 DSA (esempio id_dsa.pub). Se i reclutatori riterranno che il test sia di un livello soddisfacente, abiliteranno i servizi necessari.

A questo punto, lo sviluppatore entra in un periodo di prova di 30 giorni durante i quali il relativo mentore è responsabile delle sue azioni - inoltre i reclutatori Gentoo possono rifiutarlo come nuovo sviluppatore a loro completa discrezione.

3. Cosa si ottiene

3.a. Introduzione

Gentoo fornisce agli sviluppatori tutti i servizi necessari per lo sviluppo. Qualora ci sia la necessità di ulteriori strumenti non esitare a contattare il team dell'infrastruttura!

Una volta che si diventa sviluppatori autorizzati, il proprio reclutatore dovrebbe organizzare i seguenti servizi. In caso di problemi con i servizi, contattare il proprio reclutatore od il team dello staff menzionato avente accesso ai servizi richiesti.

3.b. Bugzilla

Gli sviluppatori sono abilitati a cambiare ogni aspetto dei bug in Bugzilla. Se si possiede un account esistente, l'indirizzo email dovrà essere cambiato con quello Gentoo da un amministratore di Bugzilla.

3.c. CVS

Non tutti gli sviluppatori ricevono l'accesso al CVS - se c'è la necessità dell'accesso tramite Portage ai rami gentoo, gentoo-projects o gentoo-x86, chiedere a qualche membro del team dei reclutatori il quale effettuerà l'operazione. Bisogna comunque giustificare il motivo per il quale serve l'accesso.

3.d. IRC

Quando si diventa sviluppatori, si riceverà un cloack gentoo/developer/* che identifica il proprio status di sviluppatore. Se ciò non avviene si prega di contattare i reclutatori o chiedere nel canale #gentoo-groupcontacts. Tenere ben presente che i cloack di Freenode non possono contenere nè il carattere "underscore" (_) nè il punto (.) nell'ultima parte, pertanto bisogna scegliere o un nickname appropriato o un cloack differente.

Inoltre si riceverà lo stato di operatore su #gentoo-dev. In più, i capi dei vari team possono decidere di assegnare lo stato di operatore in canali specializzati, per esempio in #gentoo-hardened. Gli abusi dei poteri di operatore su #gentoo-dev possono causare la rimozione di questi permessi, o perfino la potenziale rimozione del proprio status di sviluppatore. Se sono stati dati determinati privilegi, si chiede di usarli costruttivamente per permettere a tutti di seguire la chat anche quando altri sviluppatori o utenti disturbano l'ordine dei canali.

Il canale IRC #gentoo non viene più controllato dal gruppo Relazioni tra Sviluppatori, ma dal progetto gentoo-ops. Lo status di op in #gentoo non significa assolutamente che quell'utente sia uno sviluppatore.

Canali Gentoo "speciali" come #gentoo-hardened e #gentoo-server sono assegnati a discrezione del rispettivo team - in questi casi, i team hardened e server.

I proprietari dei diversi canali IRC sono i relativi capi dei progetti, siano essi strategici o operazionali e i proprietari hanno la discrezione di dare la parola o toglierla ai membri del pubblico. Se si crede vi sia un abuso di questi privilegi o che essi vengano usati con considerazioni sbagliate, rivolgersi al Gruppo Relazioni tra Sviluppatori.

3.e. Forum [Opzionale]

Se necessario, chiedere ad un amministratore dei forum in #gentoo-forums o scrivendo a forum-mods@gentoo.org di aggiornare il proprio stato sui forum Gentoo. Gli account sui forum non sono obbligatori.

3.f. Planet [Opzionale]

Gli sviluppatori aventi un blog personale possono richiedere di essere aggiunti all'aggregatore del planet. Il software del planet crea un feed personalizzato di tutti i post dei blog degli sviluppatori, separati in due categorie: on-topic (Gentoo e contenuti relativi al mondo dei computer) su Planet Gentoo, e tutti i topic su Gentoo Universe.

Inoltre, se un utente non possiede ancora un blog, l'infrastruttura di Gentoo ospita il proprio software di blogging ed è possibile creare un account per lo sviluppatore.

Per maggiori dettagli si prega di leggere http://www.gentoo.org/proj/en/userrel/planet/index.xml.

3.g. Mail

Tutti gli sviluppatori sono provvisti di un indirizzo sviluppatore@gentoo.org da utilizzare per Gentoo.

Si prega di consultare l'indirizzo /proj/it/infrastructure/dev-email.xml per maggiori dettagli.

3.h. Mailing list

Tutti gli sviluppatori devono essere iscritti alle mailing list gentoo-core e gentoo-dev-announce. Tutti gli sviluppatori dovrebbero essere iscritti a gentoo-dev e gentoo-project, sebbene entrambi non siano requisiti per gli sviluppatori. Contattare qualcuno dei reclutatori per l'iscrizione alla mailing list per soli sviluppatori gentoo-core o per per qualsiasi problema.

gentoo-core è da usare per discussioni interne; le discussi tecniche dovrebbero essere discusse su gentoo-dev; discussioni non tecniche dovrebbero essere discusse su gentoo-project; mentre gentoo-dev-announce è solamente per gli annunci. Se si invia un messaggio su dev-announce, si dovrebbe effettuare un cross-post manualmente su una mailing list on-topic ed impostare il reply-to lì.

Se si è già iscritti ad una qualsiasi altra mailing list di Gentoo, bisogna disiscriversi e reiscriversi con il nuovo indirizzo.

3.i. Accesso alla shell

Attualmente gli sviluppatori ricevono un account di shell su dev.gentoo.org - questo permette l'archiviazione delle mail, ritrasmissione SMTP e anche un tunnel IRC per gli sviluppatori da usare per l'accesso a freenode.

Per garantirne la sicurezza, l'accesso è disponibile soltanto attraverso chiavi SSH, che il proprio mentore dovrà posizionare nell'account dello stesso sviluppatore per permettere la procedura il login: per maggiori dettagli sulle chiavi SSH consultare /proj/it/infrastructure/cvs-sshkeys.xml.

3.j. Regole per l'utilizzo dei servizi

I servizi forniti da Gentoo devono essere utilizzati solamente per il lavoro di sviluppo di Gentoo. L'infrastruttura ha il diritto di disabilitare qualsiasi account introduca potenziali rischi per la sicurezza, inclusi gli account inattivi che verranno sospesi da parte del gruppo per le infrastrutture, se riterranno il relativo utente occupato, come pure lo stato su #gentoo-dev che verrà passato a "voice".

Se un qualsiasi file trovato nell'account di uno sviluppatore viene ritenuto nocivo per gli altri sviluppatori o utenti della macchina, o pone a rischio il progetto di Gentoo (come file illegali .torrents), l'infrastruttura di Gentoo sospenderà l'account coinvolto che potrà essere sbloccato solo dopo l'investigazione da parte dei membri del gruppo Relazioni tra Sviluppatori Gentoo. Nella maggior parte dei casi le eventuali appartenenze ai team verranno sospese, se vengono trovati questi file. Le stesse regole vengono applicate al CVS di Gentoo e a qualsiasi altro servizio fornito da Gentoo e precedentemente messo a disposizione.

3.k. Politiche sull'attività

I responsabili del progetto Gentoo comprendono che come nella vita le cose cambiano cose, ciò può succedere anche rispetto alla disponibilità degli sviluppatori. Se si sa con certezza di risultare non disponibili per un lungo periodo di tempo (vacanze, grandi progetti in ambito lavorativo, necessità in famiglia, ecc.) si chiede rispettosamente di usare il sistema devaway.

on dev.gentoo.org
$ echo "Away until 2007-08-30, contact $dev1 in my absence" > ~/.away

on dev.gentoo.org
$ rm ~/.away

Con l'obbiettivo di mantenere il gruppo di sviluppatori aggiornato e le risorse sicure, il team Relazioni tra Sviluppatori revisiona periodicamente l'attività degli sviluppatori alla ricerca di sviluppatori inattivi. Uno sviluppatore è considerato inattivo se non ha dato nessun contributo dopo un periodo maggiore di 60 giorni. Non è facile tracciare le attività di ognuno, pertanto, Relazioni tra Sviluppatori richiede spesso dei riscontri da un responsabile del progetto o dai suoi membri a cui appartiene uno sviluppatore sospettato di essere inattivo.

Qualsiasi sviluppatore sospettato di inattività per un periodo che eccede i 60 giorni potrebbe essere soggetto al ritiro. In primo luogo Relazioni tra Sviluppatori effettuerà una ricerca e stima della situazione, cercando di contattare lo sviluppatore, o se i tentativi non hanno successo potrebbero scegliere di ritirare lo sviluppatore. Notare che se si è in devaway per più di 60 giorni, si è anche in questo caso considerati inattivi, tuttavia, le date di ritorno verranno prese in considerazione. Se uno sviluppatore è ritirato a causa di inattività e desidera tornare, deve solamente contattare i Reclutatori per iniziare nuovamente il processo di reclutamento.

4. Aiuto per i nuovi sviluppatori

4.a. Utilizzo del CVS

Introduzione

Questa guida non vuole essere un manuale sull'utilizzo di CVS, per il quale è preferibile consultare la relativa pagina info oppure /doc/it/cvs-tutorial.xml. Invece essa si focalizza in modo specifico sull'uso di CVS e di Repoman nell'ebuild tree di Gentoo.

Configurazione

Tipicamente, nel proprio ~/.cvsrc dovranno esserci delle voci simili a queste:

cvs -q -z0
diff -u -B
checkout -P
update -d -P

Infine, ad alcuni utilizzatori di CVS piace usare la compressione (-z#). Si chiede agli sviluppatori che non hanno una connessione dialup di usare -z0 - con il contenuto del repository CVS Gentoo ed il carico di lavoro sullo stesso, si noterà un effettivo incremento della velocità senza compressione.

Recuperare i moduli CVS/SVN

Ci sono alcuni moduli utili nel repository di CVS di Gentoo. Gli ebuild sono contenuti nel modulo gentoo-x86. gentoo contiene i file XML per il sito web, la documentazione, le cartelle e le immagini degli sviluppatori, e altro ancora. gentoo-projects contiene diversi progetti e generalmente rimpiazza il modulo cvs gentoo-src. gentoo-src viene mantetenuto per ragioni storiche, per cui se lo si sta ancora utilizzando si prega di migrare ad un modulo differente.

# cvs -d username@cvs.gentoo.org:/var/cvsroot co gentoo-x86

Ogni volta, prima di lavorare nella struttura, è sempre una buona idea eseguire un'aggiornamento per controllare i cambiamenti e prevenire eventuali conflitti. È possibile aggiornare ogni singola sottocartella dell'albero nel caso non si voglia attendere l'aggiornamento completo, però ogni tanto è buona prassi aggiornare tutta la struttura:

# cd gentoo-x86
# cvs update

Inoltre Gentoo offre servizi subversion per tutti coloro che preferiscono SVN rispetto a CVS. Diversi progetti fondamentali come portage e baselayout adesso sono ospitati lì.

# svn co svn+ssh://username@cvs.gentoo.org/var/svnroot/portage

Aggiornare Portage

Se si vuole usare CVS come albero primario per Portage, aggiungere le seguenti linee al proprio /etc/make.conf, rimpiazzando you con il proprio nome utente:

SYNC="cvs://you@cvs.gentoo.org:/var/cvsroot"
CVSROOT=":ext:you@cvs.gentoo.org:/var/cvsroot"

Sia che CVS venga utilizzato come albero primario di Portage, sia che non venga utilizzato, è importante che cvs sia incluso nella variabile FEATURES in /etc/make.conf. Ciò assicura che Portage scarichi tutti i file elencati in SRC_URI all'interno dell'ebuild nel momento in cui si effettua un digest.

Nelle architetture supportate, bisogna anche avere sandbox nella propria variabile FEATURES per assicurarsi che gli ebuild non modifichino direttamente il filesystem root.

Aggiungere/Rimuovere pacchetti

Si presume di essere pronti per aggiungere un nuovo pacchetto, foo, in app-misc:

(Sostituire CVSROOT con il percorso del proprio CVS tree recuperato.)
# cd $CVSROOT/app-misc
(Aggiornare sempre prima di lavorare in una parte dell'albero CVS!)
# cvs update
# mkdir foo
(A questo punto si aggiunge al repository CVS la directory per il pacchetto foo.)
# cvs add foo
# cd foo
(È meglio mantenere gli ebuild in lavorazione esternamente all'albero CVS.)
# cp /path/to/foo-1.0.ebuild ./
(Assicurarsi che PORTDIR_OVERLAY sia impostato alla directory di CVS durante la creazione dei manifest.)
# repoman manifest
# ${EDITOR} metadata.xml
 Non è più necessario avere una directory files
# cvs add foo-1.0.ebuild ChangeLog files
[Non dimenticarsi di creare un ChangeLog - guardare la pagina man per echangelog.]
# echangelog "New ebuild for foo. Ebuild written by me. Fixes bug#XXXXXX."

Guardare la sezione Gentoo Metadata per maggiori informazioni su metadata.xml.

A questo punto, è possibile effettuare il commit (guardare la successiva sezione Commit). Ma volendo rimuovere foo-1.0 nel momento in cui è disponibile foo-1.1?

# cd $CVSROOT/app-misc/foo
# cvs update
# cvs remove -f foo-1.0.ebuild

Ora è possibile effettuare il commit (guardare la successiva sezione Commit).

Commit

Usare sempre repoman commit piuttosto che cvs commit. Repoman è un'utilità di controllo della qualità (QA) che esegue controlli di base e crea i file Manifest. Se una qualsiasi parte dell'output di repoman non è chiara, consultare man repoman. In più, se si è stanchi di digitare la propria password ripetutamente, keychain (http://www.gentoo.org/doc/it/keychain-guide.xml) può essere d'aiuto.

[Assicurarsi che non ci siano file appartenenti a root prima di avviare repoman!]
("scan" percorre la directory corrente per gli scopi di QA. "full" è più completo.)
# repoman scan
("commit" esegue uno scan, poi esegue il commit, intanto aggiorna anche il Manifest.
Assicurarsi di aggiungere un utile e dettagliato messaggio al ChangeLog di CVS...)
# repoman commit

Velocizzare CVS up

Se si riscontra un'evidente latenza verso il server cvs, è possibile usare la configurazione master slave di ssh, dove ci si connette all'altro server ssh una volta sola e si fa in modo che esso esegua i comandi successivi su tale connessione. In questo modo si risparmia l'overhead dovuto all'handshake incrementando in toto le operazioni di checkout/commit di quasi 3 volte. Basta aggiungere il pezzo di codice seguente alla propria configurazione

Host cvs.gentoo.org
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p
ControlPersist 3600

4.b. Informazioni varie

Posizionare i file sui mirror

I distfile sono automaticamente prelevati dal sistema di Mirror di Gentoo. Bisogna solamente tenere sotto controllo i propri distfile per eventuali errori di scaricamento degli stessi. Leggere Distfiles Overview Guide per esaurienti istruzioni a riguardo.

Mail e Web

L'infrastruttura di Gentoo permette agli sviluppatori di gestire le proprie email. http://www.gentoo.org/proj/it/infrastructure/dev-email.xml contiene le istruzioni per la configurazione della propria email @gentoo.org.

Gli sviluppatori hanno accesso ad uno spazio web, http://dev.gentoo.org/~$PROPRIONOME. Per ulteriori dettagli leggere Configurazione dello spazio web su dev.gentoo.org.

5. Gerarchia degli sviluppatori

5.a. Introduzione

Questa sezione ha lo scopo di spiegare la gerarchia dello sviluppo di Gentoo e dare agli sviluppatori una visione su come sia strutturata la gestione dello sviluppo di Gento Linux.

5.b. Una breve storia della struttura di gestione di Gentoo

Il primo tentativo di una struttura di gestione per la risoluzione dei problemi relativi al coordinamento e alla comunicazione è stato fatto nel 2003 con la struttura descritta nel documento GLEP 4. Con la crescita di Gentoo nel tempo, sono stati scoperti alcuni problemi con quella struttura di gestione, per cui era necessaria una nuova versione per risolvere questi inconvenienti. GLEP 39 descrive entrambe le ragioni che stanno dietro a questa decisione così come il risultato della discussione.

5.c. Attuale struttura di gestione in base a GLEP 39

Un progetto è un gruppo di sviluppatori che lavorano per trovare una soluzione (o un gruppo di soluzioni).

• Un progetto esiste se ha una pagina web su www.gentoo.org/proj/en/<nome progetto> che viene mantenuta. ("Mantenuto" significa che le informazioni nella pagina sono effettivamente corrette e non sono obsolete.) Se la pagina web non è mantenuta, il progetto è da considerarsi morto.
• Deve avere uno o più responsabili, scelti tra i membri del progetto. La scelta deve essere fatta almeno una volta ogni dodici mesi, e può essere fatta in ogni momento.
• Può avere zero o più sotto progetti. Questi forniscono ulteriori strutture e la loro pagina web è in quella del progetto.
• Non c'è bisogno di un progetto per ogni cosa (o per ognuno).
• I progetti non devono essere per forza a lungo termine.
• Dei progetti potrebbero essere in conflitto con altri progetti. Ciò è normale.
• Qualsiasi sviluppatore può creare un progetto creando una nuova pagina (o meglio, directory e pagina) in gentoo/xml/htdocs/proj/en e annunciandolo nella mailing list gentoo-dev-announce.

I problemi globali saranno decisi da un Consiglio Gentoo eletto in precedenza.

• Verrà deciso un numero di membri di consiglio. (Per la prima elezione questo numero è impostato a 7 per acclamazione.)
• I membri del consiglio verranno scelti da un'elezione generale di tutti gli sviluppatori una volta all'anno.
• Il consiglio deve tenere un incontro aperto almeno una volta al mese.
• Le decisioni del consiglio spettano alla maggioranza dei voti dei presenti (o dei loro delegati).
• Se un membro del consiglio (o il suo delegato) non è presente per più di due incontri consecutivi, verrano marcati come 'slacker' (scansafatiche).
• Se un membro del consiglio è stato marcato come scansafatiche e manca ad uno qualsiasi dei successivi incontri (così come il suo delegato), perde la sua posizione e viene tenuta una nuova elezione per rimpiazzare questa persona. Il nuovo membro del consiglio eletto avrà un'elezione "ridotta" fino a quando ci sarà l'annuale elezione che elegge il nuovo gruppo completo.
• I membri del consiglio che sono già stati ripresi più volte per essere stati scansafatiche possono essere esclusi per le elezioni future, incluse le elezioni per il loro rimpiazzo. Devono comunque giustificare le proprie assenze e devono aspettarsi che ciò venga fatto loro notare, se non lo fanno di loro spontanea volontà.
• Il titolo di 'slacker' (scansafatiche) viene rimosso quando un membro viene eletto.
• Se un incontro ha una partecipazione di membri del consiglio minore del 50%, deve essere organizzata entro un mese una nuova elezione per tutti i posti. L''anno' ripartirà da quel punto.
• Le azioni disciplinari possono anche essere decise dal consiglio.
• Un delegato non può essere un membro esistente del consiglio, ed una singola persona non può essere delegata per più di un membro del consiglio ad ogni singolo incontro.

3.d. Conseguenze della struttura gestionale di Gentoo

Conseguentemente alla nuova struttura di gestione, le decisioni globali vengono prese dal consiglio eletto. Questo dà a Gentoo una direzione generale - decisioni più piccole che influenzano soltanto un progetto o due e sono decise all'interno dei progetti coinvolti, probabilmente con l'input di altri sviluppatori. Il consiglio dovrebbe rappresentare equamente la base di sviluppatori poiché ogni sviluppatore ha il diritto a votare, per questo motivo gli interessi devono essere rappresentati in modo giusto. Se il consiglio lavora male e la base degli sviluppatori non è contenta del suo operato, il consiglio può essere rivotato.

Le decisioni all'interno di un progetto possono essere prese all'interno del progetto stesso, ovviamente il coordinamento tra i progetti è necessario. I capi dei (sotto)progetti sono generalmente responsabili di questo aspetto.

La maggior parte dei progetti hanno un capo operativo e strategico, ma fondamentalmente sta al progetto decidere quali posizioni creare e la loro denominazione - ciò si applica anche ai sottoprogetti.

Alcuni progetti nominano una persona di riferimento per le comunicazioni con altri progetti, per esempio uno sviluppatore all'interno del progetto del forum è responsabile per la comunicazione con il progetto dell'infrastruttura.

Tutto sommato la struttura attuale non ha un chiaro elenco delle responsabilità che i capi dei progetti si presume debbano soddisfare. Essi sono scelti dai membri del progetto, la responsabilità pratica del capo è "qualsiasi cosa richiedano i membri", e se ciò non è rispettato, i membri possono scegliere un nuovo capo (se trovano qualcuno che si assuma l'incarico!).

6. Politica membri dello Staff

6.a. Politica per i Membri dello Staff di Gentoo

Introduzione

Far funzionare una distribuzione Linux implica diversi aspetti, e molti di questi non sono direttamente connessi alla programmazione del codice. Ogni distribuzione ha bisogno di persone che facciano funzionare i suoi server, aiutino la comunità, forniscano la documentazione, gestiscano le finanze del progetto e le questioni legali e seguano molti altri compiti, Questi contributi sono importanti tanto quanto i contributi sotto forma di codice. Questi sviluppatori all'interno di Gentoo vengono chiamati membri dello staff.

Tipologie di membri dello staff

L'elenco seguente contiene tutti i tipi di membri dello staff che attualmente vengono reclutati in Gentoo:

• Membri del progetto Infrastruttura di Gentoo
• Redattori e traduttori della Documentazione di Gentoo
• Redattori e traduttori della Newsletter Mensile di Gentoo
• Amministratori e moderatori globali dei Forum di Gentoo
• Membri del gruppo per le Relazioni con gli Sviluppatori Gentoo
• Membri del gruppo per le Relazioni con gli Utenti Gentoo
• Membri del gruppo per le Relazioni Pubbliche di Gentoo
• Coordinatori GLSA per la Sicurezza in Gentoo
• Sviluppatori di Gentoo Sunrise
• Fiduciari della Fondazione Gentoo

In che modo l'accesso dei membri dello staff differisce da quello degli sviluppatori di ebuild?

L'accesso viene assegnato in base alle responsabilità del Membro dello Staff. A tutti gli Sviluppatori Gentoo viene messo a disposizione un indirizzo mail gentoo.org, l'accesso ssh a dev.gentoo.org (per la shell, ldap, public_html, ecc.) insieme all'accesso cvs alle pagine web/di progetto di Gentoo. Come membro dello staff non si avrà accesso all'albero delle ebuild, a differenza degli sviluppatori delle ebuild, ma potrebbe essere garantito l'accesso ad altre aree in base alle proprie necessità e responsabilità.

Come si può diventare un membro dello staff di Gentoo?

Bisogna lavorare con i membri del progetto che si desidera aiutare. Si verrà invitati nel team quando il proprio livello di contributi ed esperienza giustificherà il passaggio a sviluppatore in tale progetto. Inizialmente ciò richiederà tempo e richiederà il passaggio attraverso procedure interne di reclutamento nel progetto. Quelle procedure esistono per assicurare che si sappia cosa implicano le proprie funzioni all'interno di Gentoo, e sono create e mantenute dal progetto stesso.

Quando si è pronti, bisogna cercarsi un mentore, dopodiché verrà aperto un bug per sviluppatori dopo che il proprio mentore avrà approvato le vostre risposte al quiz per lo staff. Una volta che al proprio bug di sviluppatore verrà assegnato un reclutatore, entrambi dovrete pianificare la revisione di tale quiz. Si prega di leggere la guida per l'addestramento (in inglese, NdT) per ulteriori informazioni.

Vorrei essere reclutato come membro dello staff ma anche pianificare la partecipazione futura ad altri progetti

Ogni sviluppatore Gentoo può unirsi a qualunque progetto esso/a desideri se gli sviluppatori del progetto sono d'accordo. Tuttavia prima di poter iniziare a contribuire all'albero delle ebuild, bisognerà affrontare il processo di reclutamento come sviluppatore di ebuild. Ciò significa che si avrà bisogno di un mentore, una storia di contributi tecnici (correzioni di bug, overlay, ecc.) ed un addestramento adeguato. A tal proposito si prega di contattare i reclutatori.

Come viene gestito il ritiro dei membri dello staff?

Bisogna o rimanere attivi all'interno del progetto a cui si sta partecipando o spostarsi in altri progetti. Se non ci sono progetti all'interno di Gentoo nei quali non si sta partecipando attivamente, si è soggetti alla procedura di ritiro tramite le procedure dei "Gentoo Undertakers" ("becchini di Gentoo", NdT).

B. Politiche

1. Politica per gli Ebuild

1.a. Linee guida generali

Queste sono alcune linee guida generali da seguire per lo sviluppo:

• Eseguire sempre l'inserimento (check in) dei cambiamenti con repoman; usare repoman commit al posto di cvs commit.
• Se un pacchetto è corrotto anche nella sua versione corrente o se ha un processo di compilazione/installazione veramente orribile, verificare come si comportano altre distribuzioni:
  • Debian
  • Mandriva
  • Fedora
• Il proprio pacchetto, nel momento in cui risulta completato e non mascherato, si suppone funzioni da subito per l'utente finale. La modifica del prodotto installato per farlo funzionare dovrebbe essere opzionale; per questo motivo bisogna installare il pacchetto con delle ragionevoli impostazioni predefinite.
• Non aver timore di consultare la documentazione in linea di Gentoo e di guardare come sono scritti e mantenuti gli ebuild creati da sviluppatori più esperti. Non farsi problemi a contattare direttamente sviluppatori più esperti per porre qualsiasi domanda di natura tecnica o di regolamento.
• Fare attenzione riguardo ai propri commit. Ricordarsi che i propri cambiamenti possono potenzialmente danneggiare migliaia di utenti. Se i propri cambiamenti causano qualsiasi tipo di malfunzionamento nel portage tree, devono essere corretti in modo tempestivo
• Ogni pacchetto deve essere accompagnato da un file metadata.xml il quale elenca, tra le diverse informazioni, quale herd /gruppo) (e/o quali mantenitori) sono incaricati del pacchetto.

1.b. Linee guida specifiche

fPIC

Su certe architetture, le librerie condivise devono essere compilate con -fPIC. Nell'architettura x86 ed in altre, le librerie condivise possono compilare senza -fPIC, ma è uno spreco e potenzialmente potrebbe causare una diminuzione di prestazioni. Se viene trovato un pacchetto che non compila le librerie condivise con -fPIC, correggere il Makefile per compilare solo le librerie condivise con -fPIC. Sono disponibili maggiori informazioni su PIC alla pagina http://www.gentoo.org/proj/en/hardened/pic-internals.xml (ndT: in inglese). Se non si è sicuri, chiedere aiuto in un forum pubblico di sviluppatori (come la mailing list gentoo-dev o sul canale irc #gentoo-dev).

Perl

I nuovi moduli Perl saranno aggiunti al portage solo quando una delle seguenti condizioni sarà verificata:

• I(l) modulo(i) soddisfa una dipendenza
• I(l) modulo(i) non può essere gestito da g-cpan
• I(l) modulo(i) aggiunge funzionalità agli ebuild esistenti
• I(l) modulo(i) fornisce strumenti, applicazioni o altre funzionalità (per esempio di più di quelle che offre il loro .PM)

Assicurarsi che almeno un membro dell'herd di perl approvi questo tipo di aggiunte.

1.c. Regole per l'Ebuild

Regole per il nome

Il nome del file dell'ebuild consiste in quattro sottosezioni logiche:

pkg-ver{_suf{#}}{-r#}.ebuild

La prima sottosezione, pkg, è il nome del pacchetto, il quale deve contenere soltanto caratteri minuscoli, i numeri 0-9, qualsiasi numero di trattini singoli (-), underscore (_) o caratteri più (+). Esempio: util-linux, sysklogd e gtk+. Ci sono alcuni pacchetti in Portage che non seguono queste regole, ma il proprio pacchetto le dovrà seguire.

La seconda sottosezione, ver, è la versione del pacchetto, che normalmente dovrebbe essere uguale alla versione del file archivio dei sorgenti principale. La versione è normalmente composta da due o tre (o più) numeri separati da punti, come 1.2 o 4.5.2, e potrebbero avere una singola lettera alla fine dell'ultima cifra; per esempio, 1.4b o 2.6h. La versione del pacchetto è unita al nome del pacchetto con un trattino. Esempio: foo-1.0, bar-2.4.6.

La terza sottosezione, {_suf{#}}, è opzionale è può contenere uno di questi suffissi predefiniti, elencati dal meno recente al più recente:

Qualsiasi di questi suffissi può essere immediatamente seguito da un numero positivo diverso da zero, per esempio, linux-2.4.0_pre10. Assumendo la parte della versione identica, il suffisso è ordinato come segue (più basso significa più vecchio): _alpha <_beta < _pre < _rc < (no suffix) < _p.

Quando si confrontano suffissi identici seguiti da un intero, quello con il numero più grande viene considerato il più recente. Esempio: foo-1.0_alpha4 è più recente di foo-1.0_alpha3.

La quarta sottosezione del nome del pacchetto è il numero specifico della revisione Gentoo Linux ({-r#}). Questa sottosezione, come il suffisso, è opzionale. # è un numero positivo diverso da 0 zero; esempio, pacchetto-4.5.3-r3.

Questo numero di revisione è indipendente dalla versione del relativo file archivio dei sorgenti, ed è usata per informare le persone della disponibilità di una nuova e migliorata versione di un particolare pacchetto per Gentoo Linux. Il rilascio iniziale degli ebuild non deve avere il numero della revisione, per esempio package-4.5.3 ed è considerata da Portage come se avesse un numero di revisione pari a zero. Questo significa che il conteggio viene fatto in questo modo: 1.0 (versione iniziale), 1.0-r1, 1.0-r2, ecc.

Incrementi di versione e revisione

Il numero della revisione di un pacchetto deve essere incrementata dagli sviluppatori di Gentoo Linux quando l'ebuild ha ricevuto delle modifiche che impongono agli utenti di effettuare un aggiornamento. Generalmente, questo è il caso in cui le correzioni vengono fatte su di un ebuild che influenza i file installati, ma l'ebuild usa lo stesso file archivio del precedente rilascio. Se viene fatto un cambiamento interno all'ebuild di tipo stilistico il quale non modifica nessun file installato, allora non è necessario incrementare il numero della revisione. Allo stesso modo, se nell'ebuild viene corretto un problema di compilazione che affliggeva alcuni utenti non è necessario incrementare il numero della revisione, in quanto per tutti quelli a cui il pacchetto funziona perfettamente non avranno benefici nell'installare una nuova revisione, e quelli che hanno avuto problemi di installazione non avranno il pacchetto installato (perché la compilazione è fallita) per cui non c'è bisogno di fare una nuova revisione per forzare un aggiornamento. La pubblicazione di una revisione non è inoltre necessaria se il problema è stato riscontrato da un numero minimo di utenti ed il pacchetto ha un tempo medio di compilazione non trascurabile; in queste circostanze usare il proprio giudizio nel miglior modo possibile.

Gli ebuild devono essere basati sulla versione precedente dell'ebuild per assicurare che i cambiamenti non vengano accidentalmente cancellati. Le correzioni devono includere dei commenti appropriati nell'ebuild che spiegano cosa fanno ed il perché sono necessarie. Se non si ha dimestichezza con le correzioni, o non si riesce a determinare se sono veramente necessarie, non si dovrebbe aggiornare l'ebuild.

Ambito

Ogni volta che un ebuild viene derivato, le funzioni e le variabili al suo interno vengono caricate in memoria dall'interprete dello script. Tuttavia, solo le variabili e le istruzioni che non sono parte di una funzione vengono interpretate: funzioni come src_compile() vengono eseguite da Portage solamente quando l'ebuild ha raggiunto la fase di compilazione.

Il codice contenuto in queste funzioni è considerato di "ambito locale" mentre tutto ciò che sta all'esterno delle funzioni è in "ambito globale", che comporta la loro esecuzione ogni volta che l'ebuild viene derivato.

Un'applicazione esterna (come grep, sed o awk) non dovrebbe mai essere chiamata nell'ambito globale per questioni di prestazioni, e invece dovrebbero essere usate delle alternative come l'uso sostitutivo di funzioni native di bash. Si possono trovare delle utili alternative nella Guida avanzata di scripting Bash (ndT: qui l'originale inglese).

In più, non si può garantire l'esistenza nel sistema delle eventuali applicazioni esterne richiamate nell'ambito globale. Se il comando viene messo in un ambito locale (per esempio, nella funzione pkg_setup()), è possibile garantirne la presenza aggiungendolo alla variabile ${DEPEND} dell'ebuild.

Politiche per i sorgenti da CVS

Ci sono due modi differenti di compilare un ebuild basato su sorgenti che provengono da un albero di sviluppo CVS. Il primo e tradizionale metodo è di creare un ebuild di tipo "CVS snapshot" (ndT: "fotografia" del CVS) creando un file archivio (tarball) personale dal repository CVS ufficiale, facendo un mirroring dei sorgenti nel repository ufficiale dei distfile di Gentoo, e scrivendo un ebuild per l'uso specifico di questo file archivio. In seguito si farà riferimento a questi tipi di ebuild CVS con il termine "ebuild per snapshot CVS".

L'altro metodo per la creazione di ebuild basati sul CVS è di usare cvs.eclass per creare un ebuild CVS "live". Questi tipi di ebuild recuperano il più recente codice sorgente in fase di sviluppo dal repository CVS durante la fase di scaricamento (fetch) dei sorgenti, assicurando che i sorgenti siano il più possibile aggiornati. In seguito si farà riferimento a questi tipi di ebuild CVS con il termine "ebuild 'live'" (ndT: "in diretta/dal vivo").

I seguenti paragrafi spiegano in dettaglio le regole riguardanti l'uso di ebuild basati su CVS. Tenere presente che esistono delle regole molto rigide riguardo all'aggiunta di questo tipo di ebuild al Portage tree.

Ebuild per snapshot CVS sono maggiormente preferiti rispetto ad ebuild "live" (che utilizzano cvs.eclass).

Gli ebuild per snapshot CVS sono autorizzati se uno snapshot del CVS contiene delle migliorie conosciute necessarie al regolare funzionamento di un pacchetto software, o si sa (o è stato provato) che la versione da CVS di un particolare pacchetto software semplicemente funziona meglio della normale versione rilasciata.

Ebuild "live" (basati su cvs.eclass) generalmente sono designati per la comodità degli sviluppatori e dovrebbero sempre essere mascherati con una keyword ~[arch]. È impossibile garantire la solidità di un ebuild "live" (basato su cvs.eclass) in quanto l'albero dei sorgenti CVS ufficiale può subire continue modifiche, e conseguentemente questo tipo di ebuild dovrebbero essere sempre mascherati.

Sia per gli ebuild CVS "live" sia per ebuild CVS "snapshot", il relativo sviluppatore ha la responsabilità di assicurare il loro corretto funzionamento; per ovvie ragioni questo è difficile da attuare per gli ebuild di tipo "live" CVS.

Se degli ebuild (di ogni tipo) non funzionano correttamente o risultano fallati, devono essere corretti o rimossi dal Portage tree. Se sono ebuild CVS "live", potrebbero essere mascherati tramite la keyword ~[arch] per tutto il loro ciclo di vita (questa speciale eccezione è spiegata in dettaglio qui sotto).

Se un utente o gli utenti chiedono specificatamente un ebuild CVS "live", è possibile aggiungerne uno per loro. Esso dovrà essere marcato come ~[arch] in modo che altri utenti non lo installino inavvertitamente.

In questo modo, gli utenti (tipo gli sviluppatori) che richiedono questo tipo di ebuild li possono installare ma gli altri utenti saranno protetti da una loro eventuale installazione accidentale. Si ricorda nuovamente che ciò è applicabile solamente a situazioni in cui un utente o degli utenti richiedono specificatamente un ebuild CVS "live" (basato su cvs.eclass). Gli ebuild per snapshot CVS dovrebbero essere aggiunti al Portage tree con l'obiettivo di renderli stabili e fornire un miglior funzionamento rispetto alla versione normale di tale software.

Ebuild sottoposti dagli utenti

Gli ebuild sottoposti dagli utenti non dovrebbero mai essere accettati così come sono e dovrebbero essere sempre ben testati e verificati prima di effettuarne il commit nel CVS. Se un ebuild sottoposto da un utente ha dei problemi, lo sviluppatore che lo ha ricevuto e gestito ne sarà ritenuto responsabile. Inviandolo al CVS, si attesta che l'ebuild soddisfa tutti gli standard di sviluppo per Gentoo Linux.

Assicurarsi che l'ebuild proposto dall'utente non contenga intestazioni personalizzate come la seguente:

# Ebuild updated by: me <me@me.com>

Questa informazione dovrebbe essere aggiunta al ChangeLog utilizzando in modo corretto la sintassi per i commenti del ChangeLog. Assicurarsi sempre che il ChangeLog contenga i crediti corretti per l'utente che ha sottoposto l'ebuild. Questa informazione deve apparire nella prima riga del ChangeLog.

Assicurarsi inoltre che tutti i nuovi ebuild di cui si effettua il commit contengano la riga seguente:

# $Header: $

Alcuni ebuild sottoposti dagli utenti sono basati su file recuperati tramite rsync, i quali possono contenere intestazione incorrette.

Incoraggiare gli utenti a sottoporre le differenze (diff) per gli ebuild esistenti se stanno sottoponendo un aggiornamento. Facendo questo, è più facile evitare la re-introduzione di bug già corretti nei propri ebuild "nuovi". Se non si sta lavorando su di un diff sottoposto da un utente ma su di un ebuild completo, allora usare il comando diff per vedere cosa è stato cambiato, tenendo attentamente d'occhio qualsiasi cosa che dal proprio ebuild corrente dovrebbe apparire nel nuovo ebuild, o qualsiasi cosa che dovrebbe essere corretta o rimossa nel nuovo ebuild.

Generalmente, lasciare che sia l'utente a fare il lavoro richiesto per aggiornare il proprio ebuild, a meno che non si voglia effettuare una pulizia dell'ebuild a suo vantaggio. Nondimeno il più delle volte è meglio lasciar fare il lavoro all'utente in modo da dargli la possibilità di imparare dai propri errori e inviare ebuild più precisi in futuro. Assicurarsi di essere riconoscenti per qualsiasi ebuild o patch sottoposta, anche se il lavoro non è molto buono. Comportarsi in modo educato ma onesto: se un ebuild non è usabile, l'utente può essere avvisato in un modo da non insultare la sue attuali abilità nello scrivere ebuild. Ricordarsi che l'utente che invia degli ebuild corrotti potrebbe essere in futuro un membro responsabile e produttivo del progetto Gentoo, e questo succederà se riceverà la giusta quantità di incoraggiamenti e supporto per continuare a migliorare le proprie abilità.

1.d. Politica per la QA (Quality assicurance - Garanzia di Qualità)

Politiche di rilascio per Portage / Baselayout

Solo i membri del team di Portage (che si sa chi sono) hanno l'autorità per rilasciare una nuova versione di Portage, nessun altro è abilitato a farlo.

Solo i membri del team del baselayout (che si sa chi sono) hanno l'autorità di rilasciare una nuova versione di baselayout, nessun altro è abilitato a farlo.

Pacchetti mascherati

/usr/portage/profiles/package.mask contiene una lista di pacchetti che non dovrebbero essere installati dagli utenti e i commenti che spiegano in modo dettagliato i motivi dello mascheramento. package.mask è usato per prevenire l'installazione di pacchetti malfunzionanti, che guastano qualcosa d'altro o necessitano di test intensivi prima di essere aggiunti nel ~ARCH KEYWORDS del Portage tree. Quando si aggiunge un pacchetto a package.mask, fare sempre prima il commit di questo file prima del commit dell'ebuild mascherato, in modo da prevenire che l'ebuild venga installato erroneamente dagli utenti, prima che il file package.mask aggiornato lo possa fare da sé.

Ogni volta che un pacchetto viene rimosso da package.mask bisogna fare molta attenzione, poiché c'è un motivo se un ebuild è elencato in questo file. Se non si ha effettuato personalmente il mascheramento dell'ebuild, contattare sempre lo sviluppatore elencato nei commenti di package.mask prima di intraprendere qualsiasi azione. Inoltre, se l'ebuild mascherato è un pacchetto di sistema, o una sua dipendenza, o se la rimozione del mascheramento potrebbe avere effetti dannosi, il cambiamento deve essere discusso internamente nella mailing list degli sviluppatori.

~ARCH in KEYWORDS

Lo scopo di ~arch è di testare nuovi pacchetti aggiunti a Portage.

C'è una differenza tra l'uso di package.mask e ~arch per gli ebuild. L'uso di ~arch denota il fatto che un ebuild ha bisogno di essere testato. L'uso di package.mask denota il fatto che l'applicazione o la libreria stessa è valutata come instabile. Per esempio, se gimp-1.2.0 è la versione stabile per gli sviluppatori di Gimp, ed è disponibile una nuova versione 1.2.1 contenente delle correzioni, uno sviluppatore dovrà marcare l'ebuild come ~arch per poterlo testare in portage perché il rilascio è valutato come stabile. In un altro caso, se Gimp decide di rilasciare una versione della serie instabile o di sviluppo marcata come 1.3.0, allora questi ebuild dovranno essere messi in package.mask perché il software in sé è di una qualità di sviluppo e gli sviluppatori non ne raccomandano la distribuzione.

Tutti i nuovi pacchetti che vengono inseriti in Portage devono essere marcati come ~arch per la(e) architettura(e) sulle quali si sa che quella versione del pacchetto funziona correttamente. Lo sviluppatore che fa il commit dell'ebuild deve verificare che esso funzioni correttamente e che le KEYWORDS siano corrette.

Spostamento delle versioni dei pacchetti da ~ARCH a ARCH

Quando una nuove versione di un pacchetto dimostra di essere stabile per un sufficiente periodo di tempo ed il mantenitore dei pacchetti di Gentoo è fiducioso nel fatto che l'aggiornamento non creerà problemi alla macchina Gentoo degli utenti, allora può essere spostato da ~ARCH a ARCH. Un'indicazione della stabilità del pacchetto può essere se non vengono verificati o non ci sono bug irrisolti per la versione del pacchetto dopo un mese dalla sua introduzione.

È compito del mantenitore del pacchetto reputare quali versioni sono stabili o se la versione di sviluppo dovrebbe essere in package.mask o lasciata come ~arch.

Bisogna inoltre assicurare che tutte le dipendenze di questa versione del pacchetto siano anch'esse in ARCH.

1.e. Variabili

Variabili necessarie

La politica di di Gentoo Linux richiede che tutti gli ebuild contengano le variabili KEYWORDS, LICENSE, e SLOT. Anche HOMEPAGE, SRC_URI e DESCRIPTION dovrebbero essere incluse eccetto per circostanze particolari. DEPEND (e se necessario, RDEPEND) dovrebbero essere incluse se il proprio pacchetto ha rispettivamente delle dipendenze in fase di compilazione o di esecuzione.

DEPEND e RDEPEND

Usare DEPEND per definire le dipendenze necessarie per la compilazione di un pacchetto particolare, ed impostare RDEPEND con le dipendenze richieste per eseguire un particolare pacchetto. RDEPEND dovrebbe essere impostato esplicitamente, anche se RDEPEND=${DEPEND}.

RDEPEND="${DEPEND}
         net-ftp/curl"

È anche importante notare che quando un pacchetto binario .tbz2 viene installato soltanto le dipendenze di RDEPEND vengono soddisfatte; usare questa informazione come aiuto nella scelta delle corrette dipendenze per RDEPEND.

Un pacchetto deve dipendere dalle versioni più vecchie che soddisfano le dipendenze. Se esso funziona con libfoo-1.2.x, non farlo dipendere da libfoo-2.x solo perché questa è la versione che si ha installato.

In generale, i pacchetti dovrebbero dipendere da =libfoo-1.2* invece che da >=libfoo-1.2. Altrimenti, le cose potrebbero cominciare a non funzionare più nel momento in cui viene introdotto libfoo-2.0.

La dipendenza da un pacchetto virtuale come virtual/foo funzionerà soltanto se i diversi pacchetti forniti da virtual/foo hanno delle interfacce uguali tra loro. Considerare virtual/jdk-1.3 come esempio: alcuni pacchetti non funzionano con ibm-jdk-1.3 mentre funzionano correttamente con sun-jdk-1.3. Per questa ragione, assicurarsi che il proprio pacchetto sia testato con tutti quelli forniti dal pacchetto virtuale, prima di rimuovere il mascheramento. Si potrebbe fare dipendere il pacchetto soltanto da una parte di quelli contenuti nel pacchetto virtuale piuttosto che dal pacchetto virtuale stesso.

2. Politica di Etiquette

2.a. Introduzione ed alcuni semplici suggerimenti

Questi suggerimenti sono pensati per essere una guida facile da seguire riguardo a quello che i membri del Coordinamento Sviluppatori si aspettano sia una buona regola di comportamento per gli sviluppatori. Tali suggerimenti dovrebbero coprire la maggior parte delle aree ed essere impiegati tutte le volte che risulta possibile.

Questo non significa pretendere che lo sviluppatore segua questa guida per filo e per segno e neppure pretendere che egli ne accetti i contenuti; tuttavia si esige che tutti gli sviluppatori mantengano degli standard ragionevoli riguardo al comportamento nei confronti della comunità di Gentoo, sia con altri sviluppatori che con gli utenti. In ogni caso, se non viene riscontrato uno standard ragionevole si può essere soggetti a sanzioni o sospensione.

Con standard ragionevoli non s'intende il non poter esprimere la propria opinione, piuttosto si reputa che il modo, il metodo ed la professionalità usata per esprimere la propria opinione stabiliscano se uno standard ragionevole viene soddisfatto, dato che, come sviluppatore, quello che viene detto si riflette globalmente su Gentoo ed i suoi progetti. Si richiede solamente di essere rispettosi nel medesimo modo sia nei confronti degli altri sviluppatori sia degli utenti, e valutare l'opinione di tutti, pur ritenendola totalmente sbagliata.

Cercare di usare una ortografia ed una grammatica corretta dovunque: sia in un messaggio di commit su CVS, sia in un Changelog, sia in IRC se si vuole essere veramente gentili. Comunque non ci si deve preoccupare riguardo a questo aspetto, in quanto ogni sviluppato viene lasciato libero di agire, però è utile tenere presente che impegnandosi a rendere le cose più chiare, il tempo necessario per leggere le proprie frasi sarà minore. Tuttavia allo stesso tempo è anche importante non perdere il filo del discorso scrivendo messaggi troppo lunghi che porterebbero via troppo tempo per essere letti.

2.b. Cosa non si dovrebbe fare

Cercare di non essere maleducati, offensivi o scortesi in ogni circostanza. Qualche volta, solo un commento sarcastico può far cambiare tono a chi sta leggendo. Se si pensa di poter essere stati fraintesi su un proprio commento, e se c'è veramente bisogno di dirlo, assicurarsi che la gente capisca che non si voleva essere offensivi.

È importante ricordarsi che si è rappresentanti ufficiali di Gentoo. Svolgendo tale funzione, si richiede di mantenere un certo livello di professionalità e cortesia nelle proprie relazioni giornaliere con gli utenti e gli altri sviluppatori.

2.c. Consigli

ChangeLog

• Rendere leggibili i propri Changelog per l'utente medio: cercare di mantenere le cose semplici e concise se possibile, ma fornire qualunque informazione critica se necessario. Ricordarsi che i Changelog devono essere scritti in un inglese piacevole e "corretto" anche se il loro contenuto è succinto. La punteggiatura è essenziale.
• Si prega di non usare linguaggi in dialetto "Gentoo", eccetto per i termini accettati come "ebuild" e "version bump". Se si è prolissi, usare i segni di punteggiatura e quotatura in modo corretto.

• Tutti i nomi di funzioni dovrebbero essere incapsulati tra virgolette o apici.
• Essere prolissi: "Version bump" va bene, anche se "Version bump; see bug #..." è sempre meglio. Questo non aiuta soltanto gli utenti, ma aiuta allo stesso modo altri sviluppatori.
• Non usare frasi come "Testato per mesi, dovrebbe funzionare." o "Credo che questo dovrebbe risolvere il problema." o altre frasi che non danno la certezza del funzionamento o meno di qualcosa. È molto più importante informare l'utente di testare il più possibile il pacchetto e di riportare qualsiasi bug.
• Quando si fa riferimento ad una sezione di un ebuild tipo la variabile homepage, usare "HOMEPAGE" ricordando di aggiungere le virgolette e di usare il carattere corretto. Questo rende le cose più precise, dicendo chiaramente all'utente che la variabile è stata modificata; piuttosto che l'homepage alla quale si collega il proprio pacchetto durante l'avvio, per esempio.
• Quando si usano degli acronimi, usare le lettere maiuscole/minuscole correttamente. Per esempio, "ALSA", non "alsa", "Win4Lin" non "win4lin".

Ebuild

• Rispettare le preferenze di codifica degli sviluppatori. Cambiamenti non necessari di sintassi ad un ebuild aumentano il carico di lavoro sul server CVS e possono causare complicazioni per altri. I cambiamenti di sintassi dovrebbero essere fatti soltanto se danno dei vantaggi reali, come una compilazione più veloce, informazioni migliori all'utente finale o se adempiono alle regole di Gentoo.

IRC

• Comportarsi in modo gentile e rispettoso nei confronti di tutti, anche se si stanno ricevendo moltissimi messaggi.
• Non abusare o discriminare gli utenti o gli sviluppatori, sia facendo scherzi o sarcasmi.
• Rispondere a qualsiasi domanda nel miglior modo possibile in base alle proprie conoscenze, tuttavia è meglio non rispondere su ciò che non si conosce per evitare di confondere l'interlocutore. Non ci sono regole per qualsiasi danno collaterale causato dagli sviluppatori agli utenti, ma: se lo sviluppatore contatta in qualsiasi modo un utente, per esempio connettendosi tramite SSH alla macchina di quest'ultimo, lo sviluppatore dovrà assumersi le responsabilità di qualsiasi azione. Generalmente tali azioni non sono raccomandabili.
• Se si è uno sviluppatore con poteri di operatore, non abusare del proprio potere: se si è in disaccordo con un utente, risolvere la questione pacificamente senza fare ricorso a kick o ban a meno che la situazione non sia davvero seria ed altri sviluppatori approvino tali misure critiche.
• #gentoo e #gentoo-dev sono canali dove si utilizza un linguaggio chiaro e pulito; altri canali #gentoo- hanno regole impostate dai rispettivi proprietari. Siccome la maggioranza del traffico su #gentoo-dev proviene dagli sviluppatori Gentoo, le persone percepiscono questo canale come quello ufficiale rappresentativo di Gentoo. Allo scopo di presentare Gentoo in modo professionale, viene richiesto agli sviluppatori di mantenere un 'linguaggio pulito' nel canale #gentoo-dev.

Forum

• Comportarsi in modo gentile e rispettoso nei confronti di tutti, anche se vengono poste le domande più impensabili. Dare la propria opinione in modo cortese o non darla proprio.
• Seguire le regole del forum e cercare di mantenere la discussione in tema, senza divagare.
• Cercare di essere attivi nello sviluppo. Se gli utenti chiedono perché qualcosa è stato aggiunto, si prega di spiegarglielo. Se gli utenti chiedono perché manca qualcosa, spiegarglielo. Usare la propria conoscenza e aiutare nel limite delle proprie possibilità. Allo stesso tempo, se non si conosce bene l'argomento, non creare confusione nella gente.

Mail

• Comportarsi in modo gentile e rispettoso nei confronti di tutti. Non rispondere ad attacchi personali con altri attacchi. Dare la propria opinione in modo cortese o non darla proprio.
• Non usare mail HTML, in quanto possono dare fastidio, si raccomanda inoltre di usare un client di posta che usa il ritorno a capo (word-wrapping) se vengono spediti messaggi di puro testo. Alcune persone bloccato i messaggi in formato HTML e ciò può creare problemi nella corrispondenza.
• Quando si risponde ad una mail di un utente o di uno sviluppatore, essere cortesi e non dire semplicemente all'utente di rivolgersi ad un altro sviluppatore: cercare di spiegare il perché della situazione, se possibile. Un esempio di una buona risposta da dare in questo caso è: "Fai riferimento a <inserire nome qui> in quanto <persona> ora è il manutentore del pacchetto. Perciò per ogni ulteriore problematica fai riferimento a <persona>. Chiedo scusa per eventuali inconvenienti."

I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.