Protokoll des Arktur-Entwicklertreffens in Bonn 2004

Seite: 7/9
(2966 Worte insgesamt im Text)
(9053 mal aufgerufen)  Druckerfreundliche Ansicht

5. Vorstellung anderer Projekte und deren Strukturen

Frank Meier (fli4l, eisfair) erläutert das Vorgehen zur straffen Organisation der beiden Projekte fli4l und eisfair. Er erläutert, dass sich die Zusammenarbeit von vielen Entwicklern an einem Projekt nur dann zur Zufriedenheit aller Teilnehmer entwickelt, wenn es klare Richtlinien gibt, auf deren Einhaltung auch geachtet und deren Pflege und Weiterentwicklung ähnliche Priorität genießt wie das eigentliche Projekt selbst.

So gibt es bei eisfair nicht nur eine Anwenderdokumentation (die im übrigen genauso im CVS gepflegt wird wie das eigentliche Projekt) sondern auch eine klare Entwicklerdokumentation und verschiedene Maintainer, die bei der Abgabe neue Pakete über die Einhaltung der Richtlinien wachen und diese ggf. an die Entwickler zurückreichen.

Lars Rupp berichtet über seine Erfahrung mit dem Entwicklungsteam des GEE-Servers. Hier sei es in erster Linie die Offenheit der Hauptentwickler, die andere zur Mitarbeit bewegt. Aus dem Wünschen der Anwender werden klare Ziele formuliert und diese als "Projekte" oder "ToDo-Liste" veröffentlicht.

Mitentwickler können sich an eines dieser Projekte setzen (wobei ihnen hier ein weitgehender Handlungsspielraum gelassen wird) und reichen Ihre Arbeit anschließend bei den Hauptentwicklern ein, die die Ergebnisse dann in die offiziellen Updates einfließen lassen.

Zusätzlich demonstriert er kurz den Einsatz von BugZilla in der Firma SUSE und dessen Bedeutung innerhalb des Entwicklungsprozesses. So werden hier nicht nur Fehlermeldungen entgegen genommen und anhand der Datenbank gleich dem richtigen Maintainer zugeordnet, sondern auch der komplette Weg von der Einkreisung des Problems über die Speicherung von ersten Patches und Fixes und deren Erprobung bis hin zur endgültigen Lösung und der daraus folgenden Erstellung eines Update-Paketes wird hier dokumentiert.

So ist auch noch nach Jahren zusätzlich zu dem im Changelog des Paketmanagers verfügbaren Informationen nachlesbar, welcher Fehler mit einem bestimmten Patch beseitigt wurde.

Sowohl Frank Meier wie auch Lars Rupp wiesen auf den ungeheuren Vorteil einer zielgerichteten und weitgehend automatisierten Prozesskette hin. Dies reicht von der Aufnahme neuer Pakete über die Meldung von Fehlern und deren nachvollziehbaren Beseitigung bis hin zum automatischen Erstellen neuer Pakete anhand der ins CVS eingecheckten Patches.

Soweit möglich sollten solche Prozesse automatisiert werden - wobei aber gleichzeitig darauf geachtet werden sollte, dass alle Mitwirkenden sich an die diesen Prozessen zugrunde liegenden Richtlinien halten.

Eine besondere Form nehmen dabei Richtlinien für eine "korrekte" Dokumentation oder "korrekten" Code ein. Hier sollten an die Entwickler klare Richtlinien ausgegeben werden, wie Programmcode, Patches o.ä. auszusehen haben. Dies erleichtert später nicht nur anderen Entwicklern die Arbeit, wenn diese in einem fremden Paket Fehler suchen müssen, sondern kommt auch der Automatisierung zu gute.


Kommentare

Einen Kommentar hinzufügen



 Suchen:


 Umfrage

(Nur für angemeldete Benutzer)

Was wird hier am meisten vermisst?

[ Ergebnis | Umfragen ]

Stimmen: 621
Kommentare: 0

 Zitate

Wechselstaben verbuchtelt?

-- anonymous