.. This document is © Martin F. Krafft It is available under the terms of the Creative Commons Attribution-NonCommercial-ShareAlike Licence 2.5 ========================================================================== Verteilte Zusammenarbeit in Open-Source Projekten ========================================================================== Erfahrungen mit Debian -------------------------------------------------------------------------- .. |event| replace:: OpenExpo 2006, Zürich-Oerlikon, Schweiz .. |talkdate| replace:: 20 September 2006 .. |author| replace:: Martin F. Krafft .. |authoremail| replace:: madduck@debian.org .. |footer| replace:: |event| |bull| |talkdate| .. container:: author |author| <|authoremail|> * Entwickler in den `Debian`_, `Zope`_ und `Plone`_ Projekten * `Doktorand`_, `Lero`_, `CSIS`_, `University of Limerick`_, Ireland * Autor des Buches `Das Debian System — Konzepte und Methoden`_ .. _Debian: http://debian.org/ .. _Zope: http://zope.org/ .. _Plone: http:/plone.org/ .. _Doktorand: http://martin-krafft.net/phd/ .. _Lero: http://lero.ie/ .. _CSIS: http://www.csis.ul.ie/ .. _University of Limerick: http://ul.ie/ .. _Das Debian System — Konzepte und Methoden: http://debiansystem.info/ .. container:: event |event| |talkdate| Übersicht ========= * Versionskontrollmethoden * Kurzeinführung in die Debian Paketverwaltung * Was machen die anderen? * Vorsichtiger Blick in die Zukunft Übersicht ========= .. class:: current * 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 ========================== .. image:: zentrale-vcs.png :class: floatright * 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 =========================== .. image:: verteilte-vcs.png :class: floatright * 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 ======================================== .. container:: center .. image:: vcs.png Übersicht ========= * Versionskontrollmethoden .. class:: current * Kurzeinführung in die Debian-Paketverwaltung * Der Verwaltungszyklus * Einsatz von Versionskontrollsystemen * Probleme .. * Was machen die anderen? * Vorsichtiger Blick in die Zukunft Debian |mdash| 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, |hellip|) 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 ===================================== .. container:: center .. image:: maintainer-cycle.png * 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 .. class:: current * 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? .. container:: author |author| <|authoremail|> * http://people.debian.org/~madduck/ * http://martin-krafft.net/phd/ .. include:: licence.de.rst .. include:: common.inc .. footer:: |footer|