Protokoll des Arktur-Entwicklertreffens in Bonn 2004

(2966 Worte insgesamt im Text)
(9045 mal aufgerufen)  Druckerfreundliche Ansicht [1]

Protokoll des Entwicklertreffens in Bonn vom 10. bis zum 12.Dezember 2004

Vorwort

An der Tagung namen neben den derzeitigen Hauptentwicklern der drei derzeit verfügbaren Arktur-Versionen auch Axel Kossel und Erwin Flohr von der Zeitschrift 'ct sowie Michael Höllen und Michael Saghy von Schulen ans Netz teil.

Zusätzlich waren noch neun weitere Förderer und/oder Interessierte anwesend, die sich einerseits über den Werdegang der neuen Version(en) informieren und andererseits auch zusätzliche Ideen und Vorschläge einbringen wollten.

Die "offizielle Tagesordnung" entstammt einem Arbeitspapier von Erwin Flohr, welche aber nicht strikt eingehalten wurde. So wurde oft kontrovers diskutiert - wobei die Diskussionen verschiedene Themen der Tagesordnung berührten. Aus diesem Grund wurde für dieses Protokoll eine andere Form gewählt, welche die besprochenen Themen in den Vordergrund stellt und nicht die Einordnung dieser Themen in die vorhandene Tagesordnung.

Inhalt

  1. Vorstellungen und Wünsche für einen zukünftigen Arktur [2]
  2. Nachbesprechung des letzten offiziellen Arktur-Treffens am 15.11.2003 in Hannover [3]
  3. Kurzer Bericht zu Arktur 3.4 und 3.5 [4]
  4. Bericht zum Entwicklungsstand Arktur 4.0 [5]
  5. Vorstellung anderer Projekte und deren Strukturen [6]
  6. Zukünftige technische Strukturen [7]
  7. Ausblick [8]

1. Vorstellungen und Wünsche für einen zukünftigen Arktur

Neben der Kurzvorstellung der Teilnehmer (es gab keine Teilnehmerinnen) stellten diese jeweils Ihre Vorstellungen zur Veranstaltungen vor. Die folgenden konkreten Wünsche / Anregungen wurden dabei geäußert und diskutiert:

2. Nachbesprechung des letzten offiziellen Arktur-Treffens am 15.11.2003 in Hannover.

Bei der Nachbesprechung kamen folgende Probleme ans Licht:

3. Kurzer Bericht zu Arktur 3.4 und 3.5

Aktur 3.4 wurde im Alleingang von Helmut Hullen entwickelt. Er hat laut seiner Auskunft die Arktur-Oberfläche so weit isoliert, dass sie nunmehr auf verschiedenen Distributionen aufsetzen kann. Als Grunddistribution fär die 3.4 dient hierbei Slackware. Helmut Hullen hat seine Arktur-Version inzwischen als "Stabil" deklariert.

Bei Arktur 3.5 kam es laut Thomas Litsch zu massiven Verzögerungen, weil neben der Fehlerbeseitigung von den Entwicklern oft gleich noch zusätzliche Features in die Version eingebaut wurden und er als Maintainer nicht sofort dagegen intervenierte. Folge war, dass die neuen Funktionen wie z.B. der Virenscanner oder die Firewall oft selbst wiederum Fehler ins System brachten, die gefunden und behoben werden mussten.

Für Arktur 3.5 gibt es inzwischen aber einen "Feature Freeze", d.h. neue Funktionen werden nicht mehr aufgenommen und nur noch Fehler beseitigt, die in den schon vorhandenen Funktionen enthalten sind. Damit soll mit einjähriger Verspätung eine endgültige Release zur Cebit erreicht werden.

Arktur 3.5 setzt dabei im wesentlichen auf der Version 4.0Beta9 auf und ein Update von 3.5 auf eine spätere Version 4.0 ist fester Bestandteil der Planungen

4. Bericht zum Entwicklungsstand Arktur 4.0

Arktur 4.0 wird von Reiner Klapproth in Zusammenarbeit mit der Stadt Dresden und verschiedenen Firmen entwickelt.

Die Stadt Dresden ist hierbei insofern ein "Vorzeige-Projekt", da hier beschlossen wurde, dass alle Grund- und Mittelschulen mit Arktur als Server ausgerüstet werden.

Dazu hat eine Bietergemeinschaft, der vor allem Siemens und T-Systems angehören, Arktur eine zusätzliche "Oberfläche" verpasst und ihn um kommerzielle Pakete erweitert (z.B. REMBO, Arkeia, AntiVir,...). Siemens möchte diesen Weg (Arktur + Zusätze) später auch anderen Schulträgern anbieten. Daher gibt es gewisse Absprachen, in welche Richtung die Entwicklung gehen sollte.

Ziel ist aber weiterhin, _einen_ offiziellen Arktur 4.0 herauszugeben. Dabei soll die Verteilung von Updates über ein stadtweites Schulnetz erfolgen und auch Updates für die zusätzlich integrierten proprietären Softwareprodukte anderer Firmen soll so sichergestellt werden.

Reiner Klapproth demonstrierte an einem frisch installierten 4.0 die Fähigkeiten von LDAP [11]. Zusätzlich stellte er die bislang noch nicht realisierten Anforderungen fär die Version 4.0 vor: Arktur 4 hält fast sämtliche Daten im LDAP. LDAP scheint aber für viele anwesenden Teilnehmer noch sehr unbekannt. Während die vielfältigen Möglichkeiten, die sich durch den Einsatz von LDAP ergeben, durchaus erkannt und begrüßt werden, wird hier auch deutlich, dass neben einer gewissen Unsicherheit (wie bekomme ich Daten aus dem LDAP heraus und wieder hinein?) im Umgang vornehmlich das Problem im Raum steht, dass dann viele inzwischen für die älteren Versionen von Arktur erhältlichen Zusatztools (und auch viele der bisherigen Werkzeuge der Versionen 3.x) für ein Zusammenspiel mit LDAP komplett umgeschrieben werden müssen.

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 [12] 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.

6. Zukünftige technische Strukturen

Erwin Flohr wird sich primär um die Dokumentation und deren rechtliche Absicherung kümmern. Er dient hierbei als "Lektor" und wird die Beiträge externer Autoren entgegen nehmen, redigieren und die rechtliche Seite mit diesen Autoren abklären.

Axel Kossel übernimmt weiterhin den Support auf Seiten von Heise und wird sich mit der Möglichkeit befassen, wie man die CD(-Images) der von 'ct unterstützten Arktur-Version bereitstellen kann. Derzeitiger Status: Heise kann ISO-Downloads der CD-Versionen anbieten (jedoch keinen Server, auf dem z.B. jedes Update-Paket oder Nightly-build ISO's angeboten wird). Hier müssen noch Lösungsmöglichkeiten diskutiert und entworfen werden, da das für ältere Arktur-Versionen entworfene System für die automatische Erstellung von CDs nicht mehr den aktuellen Ansprüchen gerecht wird.

Andreas Seidel nimmt sich der Koordination der Entwicklerdokumentation an. Um Erfahrungen für zukünftige Versionen zu sammeln, soll schon für die 3.5 eine Entwicklerdokumentation entstehen. Frank Meier wird ihm hierbei beratend zur Seite stehen.

Das Arktur-Portal unter http://arktur.schul-netz.de/ [13] soll als zentrales Portal ausgebaut werden und zukünftig als primäre Anlaufstelle genutzt werden.

Alexander Dubielczyk wird sich mit dem installierten CVS beschäftigen und in Zusammenarbeit mit Phillip Flesch Subversion (den designierten Nachfolger von CVS) auf der Plattform installieren. Dort soll dann Endversion der 3.5 eingepflegt werden, so dass die nächste Version aufgrund der damit gemachten Erfahrungen leichter einzupflegen sein wird.

Das installierte Mantis soll zunehmend stärker (z.B. auch in der Entwickler-Mailingliste) beworben werden, damit hier rechtzeitig ein entsprechendes Know-How aufgebaut wird.

Alle Arktur betreffenden Änderungen am System und zusätzlichen Features sollen künftig vom darunter liegenden System getrennt werden. Hier sind abhängig von der eingesetzten Version Pakete des entsprechenden Paketmanagers zu erstellen.

7. Ausblick

Primäres Ziel ist auch dieses Jahr wieder die Fertigstellung der Version 3.5, welche zur Cebit ausgeliefert werden soll.

Die gesamte Dokumentation muss überprüft und für die jeweilige Arktur-Version angepasst werden. Derzeitige Lösung: für die 3.5 soll eine "Kurzanleitung" für die Installation und Anbindung ans Internet auf der CD enthalten sein und diese evtl. auch als "Handout" gedruckt werden. Die vollständige Dokumentation soll dann im Portal verfügbar sein, da sie so immer auf einem aktuellen Stand gehalten werden kann.

Weiteres Ziel war (ist) bis zum Sommer die V4.0 soweit fertig zu machen, dass Heise sich ihrer annehmen und sie vielleicht sogar im Herbst diesen Jahres herausbringen kann.

Parallel dazu muss die entgültige Entscheidung für das Basissystem des zukünftigen Arktur 5 fallen - oder die Entscheidung, welches andere Projekt statt dessen zukünftig die Unterstützung der Arktur-Gemeinde finden soll.

Diese Entscheidung hat laut Aussagen von Erwin Flohr und Axel Kossel aber keine Priorität: zunächst sollen die vorhandenen Arktur-Versionen stabilisiert werden und Hauptaugenmerk auf die (Entwickler-) Dokumentation und die benötigten technischen Strukturen gelegt werden.

--

So - Feierabend, Freunde!

Dieses Dokument wurde mit recyclebaren Elektronen erstellt und entspringt den geistigen Wirren von Lars Rupp. Es darf als solches frei weiterverbreitet und weitergegeben werden. Ich gebe jedoch zu bedenken, dass die hier gemachten Äußerungen rein subjektiver Natur sind und stelle es jedem Anwesenden frei, Ergänzungen und/ oder Komentare hierzu an mich zu senden, damit ich sie wiederum in dieses Dokument einbauen kann.


  

[ zurück zu Arktur 4.0 [14] | Index [15] ]

Kommentare

Einen Kommentar hinzufügen


Links
  [1] http://www.linux-schulserver.de/index.php?name=Sections&req=viewarticle&artid=30&allpages=1&theme=Printer
  [2] http://www.linux-schulserver.de/Sections-article30-p3.phtml
  [3] http://www.linux-schulserver.de/Sections-article30-p4.phtml
  [4] http://www.linux-schulserver.de/Sections-article30-p5.phtml
  [5] http://www.linux-schulserver.de/Sections-article30-p6.phtml
  [6] http://www.linux-schulserver.de/Sections-article30-p7.phtml
  [7] http://www.linux-schulserver.de/Sections-article30-p8.phtml
  [8] http://www.linux-schulserver.de/Sections-article30-p9.phtml
  [9] http://arktur.schul-netz.de/
  [10] http://arktur.schul-netz.de/hannover_151103.php
  [11] http://de.wikipedia.org/wiki/LDAP
  [12] http://www.novell.com/linux/suse/
  [13] http://arktur.schul-netz.de/
  [14] http://www.linux-schulserver.de/index.php?name=Sections&req=listarticles&secid=11
  [15] http://www.linux-schulserver.de/index.php?name=Sections