Verteilte Zusammenarbeit in Open-Source Projekten
Erfahrungen mit Debian
OpenExpo 2006, Zürich-Oerlikon, Schweiz
20 September 2006
Übersicht
- Versionskontrollmethoden
- Kurzeinführung in die Debian Paketverwaltung
- Was machen die anderen?
- Vorsichtiger Blick in die Zukunft
Übersicht
- Versionskontrollmethoden
- Aufgaben
- Atomare, zentrale und verteilte Systeme
- Vor- und Nachteile
- Die Entwicklung von Versionskontrollsystemen
- Kurzeinführung in die Debian Paketverwaltung
- Was machen die anderen?
- Vorsichtiger Blick in die Zukunft
Versionskontrollsysteme
- Zwei Hauptaufgaben:
- Buchführung von Änderungen über längere Zeitabschnitte:
- wann wurde eine bestimmte Änderung vorgenommen?
- wie sah das Projekt zu einem bestimmten Zeitpunkt genau aus?
- Koordination von mehreren Mitwirkenden
- gleichzeitiges Bearbeiten einer Datei.
Atomare Versionskontrolle
CVS erstellt unabhängige "Schnappschüsse" einzelner Dateien
Gefahr von Inkonsistenz des Archivs
Atomare VCS verwenden Transaktionen: ganz oder gar nicht
Alle modernen VCS sind atomar. Beispiel SVN:
lapse:~> svn commit -mtest
Sending eine-datei
Sending zweite-datei
svn: Commit failed (details follow):
svn: Out of date: 'eine-datei' in transaction '3-1'
Zentrale Versionskontrolle
- Zentrale Server-Instanz verwaltet Metadaten und Verlauf
- Entwickler arbeiten an lokalen "Checkouts"
- Beiträge werden ausschliesslich via der Server-Instanz ausgetauscht
- Mitwirkende benötigen eine Verbindung zum Server; wenn dieser ausfällt,
hängt die Entwicklung.
- Ausnahme: svk
Verteilte Versionskontrolle
- Jedes "Checkout" ist ein vollständiges und unabhängiges Archiv.
- Der Austausch von Beiträgen passiert in Form von "Patches".
- Das Versionskontrollsystem führt genauestens Buch über welche "Patches"
bereits lokal eingespielt wurden und verhindert ein doppeltes Einspielen.
- Verbesserte Algorithmen vereinfachen das Einspielen von "Patches".
- Das Fehlen einer zentralen Instanz setzt verstärkte Kommunikation zwischen
und Koordination der Mitwirkenden voraus.
Zentrale und verteilte Systeme im Vergleich
- Zentrale Systeme sind intuitiv und daher einfach(er) zu bedienen.
- Zentrale Systeme entsprechen nicht mehr den heutigen Anforderungen
verteilter Zusammenarbeit (offline, zeitversetzt).
- Verteilte Systeme sind sehr flexibel und nicht zuletzt deshalb kompliziert
und verwirrend; auch weniger intuitiv.
- Verteilte Systeme setzen in der Regel verbesserte Algorithmen zur
Zusammenführung von Änderungen ein.
- Viele Projekte setzen noch auf zentrale Systeme, da sie einfacher sind.
- Verteilte Systeme können eigentlich immer auch zentral eingesetzt werden.
Entwicklung von Versionskontrollsystemen
Übersicht
- Kurzeinführung in die Debian-Paketverwaltung
- Der Verwaltungszyklus
- Einsatz von Versionskontrollsystemen
- Probleme
- Was machen die anderen?
- Vorsichtiger Blick in die Zukunft
Debian — kurz und bündig
- Projekt das u.a. das Debian GNU/Linux Betriebssystem entwickelt:
- Frei
- Universell (11-12 Architekturen, 10'000 Softwarepakete)
- hohe Qualität, Stabilität, Flexibilität
- Eines der grössten Open-Source Projekte
- ca. 1'100 Entwickler, 2'000 Mitwirkende
- Über 100 Derivate: Knoppix, Ubuntu, Linspire, Kanotix, Libranet, …)
Debian-Paketverwaltung
- Historisch war bei Debian immer ein Verwalter pro Paket zuständig.
- Keine Richtlinien wie die Verwaltung geschehen sollte.
- Erschwerte Zusammenarbeit, vor allem mit Derivaten.
- Komplexität der Software führte zur Gruppenarbeit und Einsatz eines
Versionskontrollsystems.
- Jeder erfand das Rad neu.
- Heute haben wir dutzende von Rädern, was es nicht gerade einfacher gemacht
hat.
Grundlagen der Debian-Paketverwaltung
- Der Paketverwalter pflegt die Unterschiede zwischen Originalsoftware und
Debian Paket.
- Neue Originalsoftware oder Debian-spezifische Änderungen resultieren in
einem neuen Paket.
- Das Debian-Archiv speichert neben den Binärpaketen auch die Quellen
sämtlicher Pakete.
- Maximal fünf Versionen; das Archiv kann als Versionskontrollsystem
aufgefasst werden, wenn auch ein suboptimales.
Verwaltung der Differenzen
- Software, die ausserhalb von Debian entsteht, wird "debianisiert", in dem
man zumindest das ./debian/ Verzeichnis mit den Steuerdateien hinzufügt.
- Änderungen am eigentlichen Programm sind zum Teil von Nöten, um z.B. ein
Programm den Debian-Richtlinien anzupassen.
- Drei Ansätze zur Verwaltung sind häufig im Einsatz:
- Debian-Archiv als VCS, die letzte sich im Archiv befindliche Version dient
als Basis für Änderungen. "Patches" werden v.a. per Email und dem Bug
Tracking System ausgetauscht.
- Import der Originalsoftware in ein VCS-Archiv, Pflege der Differenzen,
halbautomatische Resynchronisierung mit neuen Ausgaben der Software.
- Pflege des ./debian/ Verzeichnisses mit VCS, Anpassung an neue
Ausgaben der Originalsoftware.
Eingesetzte Systeme
- Die meisten Pakete bei Debian werden, wenn überhaupt mit VCS, dann mit SVN
verwaltet.
- CVS ist am Aussterben.
- Verteilte Systeme, wie z.B. tla/baz, bzr, darcs oder
git werden hauptsächlich zentralisiert eingesetzt.
- Für die meisten VCS gibt es *-buildpackage Pakete, die viele Aspekte der
Verwaltung automatisieren, wobei fast jedes seinen eigenen Weg geht.
Probleme
- Erstellung des Quellpakets aus dem VCS-Archiv.
- Koppelung von Bug Tracking System, changelog-Datei und Kommentaren im
VCS; Redundanz.
- Improvisierter Einsatz von VCS bzw. Kombination mit anderen Hilfsmitteln,
die Funktionalität z.T. schlechter ersetzen: z.B. dpatch, quilt.
- Kein einheitlicher Ansatz, Entwickler lieben die Freiheit die sie bei Debian
geniessen.
Übersicht
- Versionskontrollmethoden
- Kurzeinführung in die Debian-Paketverwaltung
- Was machen die anderen?
- Vorsichtiger Blick in die Zukunft
Blick über den Tellerrand: BSD
- Einheitliche, zentrale Versionskontrolle
- Verpackte Software ist zum grössten Teil aus eigener Entwicklung
- *BSD Systeme werden daher oft als geschlossene Entwicklungsprojekte
gehandelt.
- Viel kleinere Entwicklergruppen.
- Frühe Festlegung von Entwicklungsrichtlinien und -techniken.
Blick über den Tellerrand: Zope/Plone
- Vollständige Entwicklung mit SVN (anfangs CVS)
- kleine, vollständige Projekte, daher sehr agil.
- Respektierte, autoritative Kerngruppe.
Blick über den Tellerrand: Ubuntu/Fedora/Gentoo
- Andere Linux-Projekte kämpfen mit ähnlichen Problemen wie Debian.
- Jüngere Projekte haben viel von Debian gelernt.
- Unterschiede in der Projektleitung, den Philosophien, des Alters und der
Grösse.
- Grössere Agilität, aber auch weniger Bedarf nach Universalität.
Beispiel: Abschaffung von Quellpaketen
- Ubuntu und Fedora wollen beide Pakete direkt aus dem VCS bauen.
- Beide setzen das bzr als VCS voraus.
- Andere VCS werden in ein zentrales bzr-Archiv importiert.
- Debian spielt schon lange mit diesem Gedanken, hat aber noch keine Lösung
parat: Entwickler wollen Flexibilität, nicht nur ein VCS.
- Zentrales Archiv notwendig um die Integrität zu gewährleisten
- fast unmöglich bei Debian's Grösse
- Debian arbeitet lieber mit den Autoren der Originalsoftware, als mit
Schnappschüssen der Software.
Die Zukunft
- Ubuntu/Fedora werden Quellpakete durch spezifische Lösungen ersetzen.
- Distributionsgrenzen werden überschritten.
- Meine zwei Szenarien bei Debian: entweder
- der Ubuntu/Fedora-Ansatz setzt sich durch und wird adoptiert.
- oder ein Hilfsmittel wird entwickelt, welches die Abstraktion zwischen
Entwicklungsmodell und zugrundeliegendem VCS herstellt.
- Bei Erfolg werden die Debian-Derivate nachziehen.
- Debians Interpretation von Universalität bezieht auch andere Distributionen
mit ein.
- Eigentlich eine typische Entwicklung in der Debian Geschichte; Allegorie zum
Hundespaziergang.
Dankeschön
Vielen Dank für Ihre Aufmerksamkeit!
Fragen?
