Se stai lavorando direttamente sul tuo codice o su codice che è
già stabilito essere di tua responsabilità, allora
c'è probabilmente poca necessità di confrontarsi con altri
committer prima di effettuare un commit. Se vedi un bug in un'area del
sistema che è chiaramente orfana (e ce n'è qualcuna di
queste aree, per nostra vergogna), agisci allo stesso modo. Se, tuttavia,
stai per modificare qualcosa che è chiaramente mantenuto
attivamente da qualcun'altro (ed è solo guardando la mailing list
cvs-committers
che puoi veramente sapere cosa è
e cosa non è) allora invia le modifiche a lui, come avresti
fatto prima di diventare committer. Per i port, dovresti contattare il
MAINTAINER
specificato nel
Makefile
. Per altre parti del repository, se non sei
sicuro di chi possa essere il maintainer attivo, potrebbe essere utile
scorrere l'output di cvs log
per vedere chi ha
effettuato delle modifiche in passato. Bill Fenner ha scritto un utile
script di shell che può aiutare a determinare chi sia il
maintainer attivo. Questo elenca ogni persona che ha effettuato commit
su un file specifico con il numero di commit che ha fatto. Può
essere trovato su freefall
in
~fenner/bin/whodid
. Se alle tue richieste non
corrisponde una risposta o se il committer in altro modo dimostra uno
scarso interesse nell'area oggetto della modifica, vai avanti ed effettua
il commit tu stesso.
Se non sei sicuro di un commit per qualunque motivo, fallo revisionare
da -hackers
prima di effettuare il commit. Meglio
che sia criticato lì piuttosto che quando è parte del
repository CVS. Se ti capita di effettuare un commit che provoca
controversie, potresti voler considerare l'annullamento delle modifiche
finché il problema sia chiarito. Ricorda - con CVS possiamo
sempre tornare indietro.
Non mettere in dubbio le intenzioni di qualcuno che non è d'accordo con te. Se vedono una soluzione differente dalla tua per un problema, o anche un problema diverso, non è perché sono stupidi, perché hanno una dubbia origine, o perché stanno cercando di distruggere il tuo duro lavoro, la tua immagine personale, o FreeBSD, ma semplicemente perché hanno una visione differente del mondo. La diversità è una buona cosa.
Dissenti onestamente. Argomenta la tua posizione con i suoi meriti, sii onesto sui difetti che può avere, e sii disponibile a guardare le loro soluzioni, o anche le loro visioni del problema, con mente aperta.
Accetta le correzioni. Possiamo tutti sbagliare. Se hai fatto un errore, scusati e vai avanti con la tua vita. Non picchiarti, e sicuramente non picchiare gli altri per il tuo sbaglio. Non sprecare tempo imbarazzandoti o recriminando, risolvi solo il problema e vai avanti.
Chiedi aiuto. Cerca (e dai) revisioni dagli altri. Uno delle cose in cui dovrebbe eccellere il software open source è il numero di occhi che lo scrutano; questo non è vero se nessuno revisionerà il codice.
Questo, ed altri documenti, possono essere scaricati da ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Per domande su FreeBSD, leggi la
documentazione prima di contattare
<questions@FreeBSD.org>.
Per domande su questa documentazione, invia una e-mail a
<doc@FreeBSD.org>.