---

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:

• Vermarktung / Marketing von Arktur soll/muss optimiert werden. Arktur selbst ist zwar als Projekt der 'ct entstanden und wurde damals auch von dieser beworben und wird noch heute unterstützt, in der breiten Öffentlichkeit ist allerdings kaum noch Information darüber vorhanden, was dieses vor 10 Jahren entstandene Projekt heute noch leistet.
• Weiterentwicklung des Kommunikationsservers Arktur hin zu einem "umfassenden Schulserver". War die ursprüngliche Konzeption von Arktur als "Kommunikationsserver" die Anbinden von Clients an das Internet, so stellt diese Konzeption zwar auch heute noch die Basisfunktionaltät von Arktur dar, allerdings sind die Wünsche der Anwender und die Möglichkeiten der Software im Laufe der Jahre gewachsen.
  Verschiedene andere Projekte stellen diese Basisfunktionalität von Arktur inzwischen ebenso gut zur Verfügung und könnten diesen insofern ablösen, so dass Arktur sich nun stärker an die zusätzlichen Anforderungen von Schulen orientieren sollte.
• Zur Optimierung der Qualität ist dringend ein Verfahren zur Qualitätssicherung erforderlich. Das auf dem Arktur-Portal [9] installierte Mantis stellt hierbei schon einen guten Schritt in diese Richtung dar, müsste allerdings sowohl von Entwicklern wie auch ambitionierten Testern und Anwendern stärker genutzt werden. So kann schon in der Entwicklungsphase eine bessere Transparenz erreicht werden und Außenstehende Helfer, die nicht die Mailingliste abonniert haben, können sich in die Entwicklung einbringen.
  
  Zusätzliche Möglichkeiten zur Qualitätssicherung wurden aufgezählt:
  • Sicherheit für jene Server, welche die ISO-Images und Updates für Arktur bereitstellen. Hier muss einerseits eine sichere Möglichkeit für die Entwickler geschaffen werden, ihre Patches und Updates einzupflegen und andererseits müssen diese Server trotzdem sicher vor Angriffen aus dem Internet sein.
    Hier bietet sich Erwin Flohr an, ein Verfahren zu etablieren, bei welchem die Entwickler ihre signierten Pakete zunächst verschlüsselt an ihn übermitteln und er diese dann nach einer Gegenprüfung auf einem FTP-Server der 'ct zur Verfügung stellt.
  • Transparente Entwicklung, d.h. für frisch ins Projekt eingestiegene Entwickler muss es Richtlinien und Anleitungen geben, wie an Arktur mitentwickelt werden kann.
  • Rechtliche Absicherung: vor der Ãœbernahme von Patches, kompletten Paketen oder Anleitungen muss sichergestellt sein, dass diese nicht gegen geltendes Recht verstoßen, indem sie z.B. Urheberrechte berühren.
    Insbesondere für die Dokumentation übernimmt Erwin Flohr die Aufgabe, hier die rechtliche Seite zu überwachen und nur Beiträge in die offizielle Arktur-Dokumentation aufzunehmen, bei welchen die rechtliche Situation geklärt ist.
  • Automatische Updates. Bei Sicherheitslücken sollten die entsprechenden Patches möglichst schnell für alle eingesetzten Arktur-Versionen verfügbar sein. Gerade bei automatischen Updates zeigt sich aber eine Schwierigkeit: die Pakete müssten vor ihrer Veröffentlichung möglichst intensiv und auf verschiedenen Plattformen getestet werden, um evtl. Probleme beim automatischen Update schon im Vorfeld zu eliminieren. Außerdem stellt ein Server, welcher solche Updates zur Verfügung stellt, natürlich ein zentrales Ziel für evtl. Angriffe dar und muss entsprechend geschützt und gewartet werden.
  • Zentrales Portal: für Endnutzer müssen die derzeit im Internet verstreuten Informationen über Arktur möglichst an einer zentralen Stelle gesammelt und aktuell zur Verfügung gestellt werden. Die Dokumentation muss angepasst und immer aktuell gehalten werden. Für Entwickler sollte ebenso an zentraler Stelle entsprechende Dokumentation vorliegen. Hier bietet sich das von Philip Flesch und Michael Vistein betreute Arktur-Portal an, welches in naher Zukunft auf ein CMS umgestellt werden soll und damit verschiedene Möglichkeiten zur Mitarbeit bietet.
  • Einsatz eines Versions-Kontroll-Systems (CMS). Hier sollten sämtliche an den Arktur-Paketen vorgenommenen Änderungen nachvollziehbar und übersichtlich präsentiert sein. Ansonsten ist sowohl die Einarbeitung neuer Entwickle sehr schwer als auch die Ãœberprüfung, warum in einer bestimmten Version Änderungen an bestimmten Skripten vorgenommen wurden.
    Das ebenso auf dem Schul-Netz-Server installierte und ebenso von Philip Flesch und Michael Vistein betreute CVS wurde zwar schon von allen Entwicklern ausprobiert - allerdings sind andere Entwickler noch nicht in der Lage, anhand der dort enthaltenen Inhalte sämtliche Änderungen nachzuvollziehen, da z.B. die Compileroptionen von speziell für Arktur kompilierte Software nicht verfügbar sind. Zur 3.5 am Sonntag wurde festgelegt: Alexander Dubielczyk pflegt die Endversion der 3.5 ins CVS ein.
  • "Nighly Build System". Optimalerweise wird ein automatisches Build-System genutzt, welches über Nacht aus den im CVS eingecheckten Quelltexten und evtl. zusätzlich von anderen Distributionen adaptierten Paketen in regelmäßigen Abständen installationsfähige Entwicklerversionen von Arktur-CDs erzeugt und auch Updatepakete zur Verfügung stellt. Auf diese Art und Weise würden die Entwickler wesentlich entlastet, da die Erstellung von Arktur-CDs bislang noch in Handarbeit erfolgt. Lars Rupp bietet hier seine Hilfe an.
• Arktur zielt mit den aktuellen und zukünftigen Versionen auf folgende Zielgruppen:
  • Lehrkräfte, die einen Schulserver installieren wollen/sollen
  • Professionelle Partner/Firmen, die für Schulen eine solide Basis suchen
  • Schulprojekte
• Es wurde folgende Dokumentation gefordert:
  • Lehrkräfte / User
  • Admins
  • Technikanbieter
  • Entwicklerdoku
  
  Es soll also Anwender-, Installations- und Benutzer-Handbücher in diversen Formaten (html, pdf, xml u.a.) geben. Ein ausreichendes Qualitätsmanagement ist auch hier wichtig.
• Definition von Schnittstellen (z.B. durch eine Entwicklerdoku) für eine Zusammenarbeit und Gewinnung neuer Mitstreiter an dem "Gesamtprojekt Arktur" sind gewünscht und erforderlich.
• Eine professionelle Entwicklungsumgebung wird für eine Weiterentwicklung des Servers gefordert (CVS / Mantis / Bugzilla). Auch hier muss aber wieder die Wartung und Pflege der eingesetzten Systeme sichergestellt sein.

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

Bei der Nachbesprechung kamen folgende Probleme ans Licht:

• Arktur ist nicht mehr allein auf dem "Schulserver-Markt". Andere Projekte bieten inzwischen mehr oder weniger echte Alternativen zu Arktur an. Hier steht immer die Frage im Raum, ob man (insbesondere bei der derzeit vorhandenen Aufsplitterung innerhalb des "Arktur-Teams") weiter an Arktur festhalten oder evtl. über eine "Ablösung von Arktur" durch die anderen Projekte nachdenken sollte. Hier wäre dann über das ob und wie der Zusammen- und Mitarbeit mit diesen Projekten nachzudenken.
• _Einen_einzigen_ "Arktur" gibt es derzeit nicht.
  • Reiner Klaproth entwickelt derzeit für die Stadt Dresden an Arktur 4. Dieser soll nach Abschluß der Arbeiten wieder ein c't-Projekt werden. Derzeit stellt er die freien Ergebnisse seiner Arbeit der Community für ausgiebige Tests zur Verfügung.
  • Helmut Hullen hat zwar mit seiner Trennung der Arktur-Spezifischen Anteile vom Grundsystem einen wesentlichen Beitrag für eine zukünftige Version 5 gelegt, verfolgt derzeit aber mit seiner eigenen Version 3.4 anscheinend eigene Wege.
  • Thomas Litsch als gewählter Maintainer der Version 3.5 arbeitet zwar eng mit Reiner Klapproth zusammen und wird von der Enwicklergemeinde als Maintainer akzeptiert, hat aber auch angekündigt, dass er sich nicht wieder als Maintainer einer neuen Version zur Verfügung stellen möchte.
• Bemängelt wurde die "Nicht-Einhaltung" der auf dem Treffen gefällten Entscheidungen.
  • Insbesondere der Zeitplan, welcher auch unter der URL: http://arktur.schul-netz.de/hannover_151103.php [10] nachzulesen ist, wurde nicht eingehalten. So wurde die Version 3.5 nicht wie angekündigt und von allen erwartet auf der Cebit im April 2004 verteilt - sondern aufgrund von vielen "Bugbeseitigungen" (die noch verschmerzbar wären) und nachträglich hinzugefügten "Zusatzfeatures", die wiederum Fehler nach sich zogen, ist bis Januar 2005 von Thomas Litsch noch keine Version als endgültiger Release 3.5 freigegeben worden.
  • Die von Philipp Flesch bereitgestellte Unterstützungen in Form von CVS-System, Mantis, Speicherplatz für die ISO-Images und Portal fanden nur zögernd Zuspruch und wurden zumindest für die 3.5 und 4.0 nicht ausreichend genutzt, um auch anderen Entwicklern die Möglichkeit zur Mitarbeit zu geben.
  • Auch die Bedenken, ob die Arktur-Dokumentation einer freien Lizenz unterliegt und somit zusammen mit den CDs verbreitet werden kann, wurden noch nicht endgültig geklärt.

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:

• Web-Oberfläche fär die raumweise Freischaltung, die ihre Daten aus dem LDAP nimmt.
• Web-Oberfläche fär die Projektverwaltung (ausschließlich Manipulation im LDAP).
• Web-Oberfläche zur Gruppenverwaltung für den Admin: Er soll neue Gruppen erzeugen können (und wieder löschen), Mitglieder ein- und austragen, ...
• Komplette überarbeitung der Dokumentation:
  1. Installationshandbuch ( an Firma gerichtet ): beschreibt Voraussetzungen (Hardware), Installation und Ersteinrichtung, Einbindung Internet-Zugang, Einrichtung E-Mail, Einbindung einer USV o.ä., sowie die Anbindung der Clients.
  2. Administrationshandbuch: Schüler anlegen und löschen, Projekte anlegen und verwalten, Möglichkeiten in Admin2-Umgebung, Filterlisten bearbeiten u.ä.
  3. Nutzerhandbuch: Beschreibung der "online"-Oberfläche und von "admin".
  4. Systemhandbuch: Grundlagen wie Filerechte, IP-Adressen, eigene Cronjobs, ...
  5. Extras und FAQ: z.B. Einwahl von außen, ...
  
  Die Dokumentation sollte - um in möglichst vielen Formaten verfügbar gemacht werden zu können, in XML erstellt werden. Hier müssen noch entsprechende Richtlinien für die Erstellung von XML verfasst werden.
• Verwaltung der Nutzer im RCS rausnehmen!
• Sollte das AntiVirensystem der 3.5 übernommen werden? Es werden mehrere Scanner angeboten, die in den Mailweg kommen. Als Scanner wird clamav (www.clamav.net) eingebunden. (Update-Script?)
• Qualitätsmanagement muss eingerichtet werden. Dazu sind Richtlinien zu erarbeiten!
• Automatische Updates : Es wird ein Verzeichnis ( eventuell unter heise.de ) eingerichtet, das Updates verteilt. Alle Update-Pakete werden mit einer Signatur versehen, welche die Echtheit und Korrektheit der Pakete sicherstellt. Es werden Möglichkeiten zu automatischen Updates und Updates auf Anforderung vorgesehen.
• Fehlersicherung bei der Installation: (Was wirft der Paketmanager wirklich ab?) Wenn ein Paket bei der Installation einen Fehler meldet, sollte dieser für den Einrichter deutlich werden.
• Rechte an der Dokumentation klären.

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.

---