Unsere Team-Einteilung wird wie beim BSD-Projekt sein. Hier ein Zitat aus dem Artikel "Hintergrundwissen zu BSD" von Greg Lehey:
4.2. Wie erfolgt die Weiterentwicklung von BSD?
BSD-Kernel werden nach dem Open Source-Modell weiterentwickelt.
Jedes Projekt unterhält einen öffentlich zugänglichen
Quellcode-Baum, der mit dem Concurrent Versions System (CVS)
verwaltet wird, und alle Quellen des Projekts, die Dokumentation
und andere notwendige Dateien enthält. CVS erlaubt es Anwendern,
jede gewünschte Version des Systems "auszuchecken'' (mit anderen
Worten, eine Kopie des System zu erhalten).
Eine Vielzahl von Entwicklern trägt weltweit zur Verbesserung von
BSD bei. Dabei werden drei Typen unterschieden:
* Ein Contributor schreibt Code oder Dokumentationen. Ihm ist es
nicht gestattet, seinen Beitrag direkt in den Quellbaum
einfliessen zu lassen. Bevor dieser Code in das System
eingebracht wird, muss er von einem registrierten Entwickler,
dem Committer geprüft werden.
* Committer können Code in den Quellbaum einbringen, das heisst
sie besitzen Schreibrechte für den Quellcode-Baum. Um ein
Committer zu werden, muss man zuerst seine Fähigkeiten im
gewünschten Gebiet unter Beweis stellen.
Es liegt im Ermessen des Committers, ob er die Allgemeinheit
befragt, bevor er Ãnderungen am Quellbaum vornimmt. In der
Regel wird ein erfahrener Committer korrekte Ãnderungen
einfügen, ohne sich mit anderen abzustimmen. Ein Committer
des Documentation Projects könnte etwa typografische oder
grammatikalische Korrekturen ohne lange Diskussion
durchführen. Auf der anderen Seite sollten Ãnderungen mit
weitreichenden Konsequenzen vor dem Commit zur Begutachtung
bereitgestellt werden. Im Extremfall kann ein Mitglied des
Core Teams, das als Principal Architect fungiert, sogar die
Entfernung der Ãnderung aus dem Quellcodebaum veranlassen.
Dieser Vorgang wird als backing out bezeichnet. Alle Committer
werden durch eine E-Mail über die erfolgte A:nderung
informiert. Es ist daher nicht möglich, heimlich eine
Ãnderung durchzufu:hren.
* Das Core Team. Sowohl FreeBSD als auch NetBSD besitzen ein
Core Team zur Betreuung des jeweiligen Projekts. Da die Core
Teams erst im Projektverlauf entstanden, ist ihre Rolle nicht
genau definiert. Um ein Mitglied des Core Teams zu sein, muss
man kein Entwickler sein, obwohl dies die Regel ist. Die
Regeln der Core Teams unterscheiden sich von Projekt zu
Projekt, generell gilt aber, das dessen Mitglieder mehr
Einfluss auf die Richtung des Projekts haben als
Nichtmitglieder.
Diese Konstellation unterscheidet sich von Linux in einigen
Punkten:
1. Es sind stets mehrere Personen für das System verantwortlich.
In der Praxis ist dieser Unterschied aber nicht gravierend, da
zum einen der Principal Architect verlangen kann, dass
Ãnderungen zurückgenommen werden, und zum anderen auch beim
Linux-Projekt mehrere Personen das Recht haben, Ãnderungen
vorzunehmen.
2. Es existiert ein zentraler Aufbewahrungsort (Repository), in
dem die kompletten Betriebssystemquellen zu finden sind,
einschliesslich aller älteren Versionen.
3. BSD-Projekte pflegen das komplette "Betriebssystem'', nicht
nur den Kernel. Dieser Unterschied ist aber marginal, da weder
BSD noch Linux ohne Anwendungsprogramme sinnvoll einsetzbar
sind. Die unter BSD eingesetzten Applikationen sind oft
identisch mit denen von Linux.
4. Da beim BSD-Projekt nur ein CVS-Quellbaum gepflegt werden
muss, ist die Entwicklung übersichtlicher, und es ist
möglich, auf jede beliebige Version einer Datei zuzugreifen.
CVS ermöglicht auch inkrementelle Updates: Das
FreeBSD-Repository wird beispielsweise etwa 100 Mal pro Tag
verändert. Viele dieser Ãnderungen betreffen aber nur einen
relativen kleinen Bereich von FreeBSD.