(Software-)Entwicklung im Debian-Projekt
Das Debian-Projekt
- Gegründet 1993, um Freie Distribution zu entwickeln
- Freiheit steht im Vordergrund
- Inzwischen ca. 1000 Entwickler (+200 New-Maintainer)
- Plus unzählige Tester und Helfer
- Aus allen Teilen der Erde
- Bereitstellung der Distribution
- Dabei auch Software-Entwicklung
Organisation im Debian-Projekt
- Hauptsächlich flach
- Drei Gruppen:
- Projekt-Leiter
- Paket-Betreuer
- Anwender
- Teams für wichtige Aufgaben:
- Security, listmaster, admin, webmaster, ftpmaster, buildd
- policy, vote, ctte, release, cd, installer
- Sub-Projekte
- IPv6, Jr., Med, Edu, Desktop, Lex, Usability Research
Koordination im Debian-Projekt
- Keine Weisungs-Hierarchie
- Kein Chaos
- Ausführliche interne Dokumentation:
- Debian Free Software Guidelines
- Policy Manual
- Developers' Reference
- New Maintainers' Guide
- Constitution
- Ausführliches Framework:
- Bug Tracking System
- Package Tracking System
- Lintian und Linda
- Build Daemon
- CVS und Alioth
Katie - Archiv-Verwaltung - buildd
Community-orientiertes Arbeiten
- Eine Gruppe gleichgesinnter
- Möglichkeiten zur Meinungsäusserung
- Möglichkeiten zur Partizipation
- Aufgaben selbst zuteilen
- Möglichkeiten zum Verstehen
- Möglichkeiten zum Kontakt mit Autoren
- Quellcode liegt vor
- Patches generieren
Arbeiten im Debian-Projekt
- Häufig Paket-Betreuung
- http://packages.debian.org/
- Reziproke Beziehung Betreuer/Pakete
- Offene Entwicklung: unstable bzw. sid
- Häufig auch übergeordnete Aufgaben
- CVS mit Web- und pserver-Zugang
- Mailing-Listen, IRC
Entwicklung im Debian-Projekt
- Offene Entwicklung
- Eigene Interessen umsetzen
- Für fremde Pakete: sid
- Für eigene Programme: öffentliches CVS/SVN-Archiv
- Bug Tracking System
- Mailing-Listen
- Internet Relay Chat
- Debian Conference
Design-Entscheidungen im Projekt
- Betreffen mehr als eigene Umgebung
- Müssen mit anderen abgestimmt werden
- Koordination zwischen Paketen
- Zuerst Möglichkeiten und Auswirkungen diskutieren
- Langwierig auf Mailing-Listen
- Kürzer im Internet Relay Chat
- Entscheidungen lassen sich nur mit Konsens durchführen
Fallbeispiel Paketverwaltung
- Jeder kann paketieren (jedoch nicht hochladen)
- Anleitungen zum Paketiern
- Mailing-Listen, IRC
- Entwickler per Mail erreichbar
- Bug Tracking System (mit Archiv)
- Strenge Regeln: Policy (+ Lintian / Linda)
- Patches
- Eigene Paket-Archive
Fallbeispiel boot-floppies / debian-installer
- Extrem wichtig für Anwender
- Komplexes System
- 11 Architekturen
- Unterschiedliche Boot-Mechanismen
- Unterschiedliche Partitionen
- Teilweise modular aufgebaut
- Programme und Dokumentation
- Nicht nur Programmierer benötigt
- Quellcode im CVS
- Jeder kann mitarbeiten
Fallbeispiel IPv6
- Viele Pakete waren noch nicht "IPv6-aware"
- Mehrere Entwickler haben sich zusammengeschlossen
- Koordination über Mailing-Liste und IRC
- Entwicklung von Patches
- Separates Archiv von Paketen
- Todo-Liste
- Integration ins Hauptarchiv nach und nach
Fallbeispiel Webseiten
- Verfügbar in 28 Sprachen
- Content-Negotiation für die Auswahl
- Geringer Wartungs-Overhead
- Kernteam übernimmt Programmierung
- Kernteam übernimmt Fehlerkorrektur
- Content-Providing durch rund 100 Personen
- Auch offline und remote
- Im Original und übersetzt
- Infrastruktur:
- Versionsverwaltung (CVS)
- Mailing-Liste + cvslog
- Automatisches Compilieren (wml, make)
- Aktualitätsprüfungen
- Verlinkung
Alioth
- Sourceforge- bzw. GForge-Klon
- Für Software-Entwicklungen von Debian
- Versionsverwaltung: CVS, Subversion
- Mailing-Listen
- Request Tracker (Bug Tracking)
- Zusätzliche Mitarbeiter
Zusammenfassung
- Flache Struktur im Projekt
- Entwicklung ist öffentlich
- Partizipation möglich
- Fortlaufendes Testen
- Strenge Richtlinien / Rahmenvorgaben
- Offene Diskussionen
- Konsens ist wichtig für Akzeptanz
- Non-intrusive Veränderungen
- Lieber richtig und langwierig als kurzsichtig und schnell