Archiv:Paketeinteilung arktur-5
|
Archiv: Dieser Artikel beschreibt nicht die Funktionalität des derzeit aktuellen delixs-Servers. Er beschreibt ältere Schulserver-Funktionen und dient dem Zweck der Archivierung. |
Ursprünglicher Text: Erwin Flohr, 19mrz07/22mrz07 . Ein Vorschlag zur Arbeitsorganisation Ich habe nun Kritik und Änderungswünsche in diesen Vorschlag eingearbeitet. (bin dabei;-)
Im Wesentlichen erhielt der Text seit seiner Vorstellung nur Zustimmung. Wir können also positivistisch davon ausgehen, dass die hier getroffenen Regelungen durch das Team vorläufig anerkannt werden. Es ist jederzeit möglich, Änderungen anzubringen, oder einen Gegenvorschlag zu präsentieren. Für diesen Fall bitte ich als ursprünglich verantwortlicher Autor um Benachrichtigung oder um eine Aufforderung zur Integration.
Separationsprinzipien bei der Entwicklung
Dieser Text beschreibt wie die Arbeit im Arktur-Team organisiert, dokumentiert und archviert wird. Das Ziel der Festlegungen ist es, Übersichtlichkeit zu schaffen, die eine Kooperation, sowie eine Einarbeitung erleichtert und die das Verständnis des ganzen Projektes zu verbessern hilft.
.
Theorie der Prozessatomisierung
Das Gesamtprojekt 'Arkturentwicklung' muss arbeitsteilig strukturiert werden, damit mehrere Menschen unabhängig und gleichzeitig daran werkeln können. Informatikern ist klar dass eine Aufgabe in Teilschritte zerlegt werden muss, stufenweise detaillierter werdend, bis eine kleinstmögliche Ablaufbeschreibung gefunden ist. Das dann vorliegende Strukturgramm braucht im Idealfall nur noch eins zu eins von der normal sprachlichen Form in die Programmiersprache umgesetzt zu werden.
Um die Aufgabenzerlegung für das Entwicklungsteam zu beschreiben darf nicht nicht ganz so weit gegangen werden. Der letzte Differenzierungsschritt ist in diesem Fall gröber. Er umfasst im Optimalfall genau die Abläufe welche zu einem einzelnen Feature gehören. Die Definition als 'feature' ist nicht sonderlich präzise. Was manchen Erbsenzählern als Problem erscheint ist freilich gerade der wesentliche Vorteil dieser Begrifflichkeit! Die Features sind äußerlich erkennbare, funktional scheinbar eigenständige Komponenten des Serversystems. Zum Beispiel der boot loader mit seinem Menü, oder der domain name service, incl. DNS-proxy. Wird stärker differenziert, so bestünde eine wesentliche Eigenschaft des Servers aus mehreren Teilaufgaben. Geht die Detaillierungsbemühung nicht so weit, so wären mehrere unterschiedliche Features in einer Aufgabenstellung gefasst, was im allgemeinen ebenso wenig Sinn macht.
Handliche Komponenteneinteilung
Dieser Grad an Zerlegung entspricht in etwa der bekannten Zusammenfassung in software-Paketen. Ich spreche jetzt nicht von den 'ODS'-Paketen des früheren Arktur, wo alles reichlich drunter und drüber ging, sondern von von der typischen Teilung die in jedem aktuellen Linux-Paketmanagement, zum Beispiel bei Debian oder SUSE, sichtbar wird. Diese Übereinstimmung ist kein Zufall. Die Abbildung in Paketen ist funktional und arbeitsorganisatorisch der kleinste gemeinsame Nenner. Genau deshalb wird diese 'Korngröße gewählt. Ich verwende also den Paketbegriff im Folgenden als die bestmögliche Metapher.
Die Teilung in Pakete verlangt nicht dass je Paket eine getrennte Betreuungsperson verfügbar ist. Erst recht bedeutet es nicht, dass je Paket nur eine Person die Bearbeitung machen dürfte. Zuständigkeit und Bearbeitung richten sich nach fachlichen und zeitlichen Gesichtspunkten, auch nach Qualifikation und nach Größe des jeweiligen Teilgebietes.
Die Teilung ist nicht nur notwendig um die Arbeitstätigkeit zu gliedern und um einen kooperativen Ablauf zu ermöglichen. Sie wird des weiteren benötigt um die Arbeit abbilden zu können. Abgebildet wird sie einerseits sehr konkret im repository unserer Entwicklungsdatenbank, zum anderen in der technischen Spezifikation. Beides wäre ohne die eingangs beschriebene Strukturierung nicht möglich. Die Dinge müssen benannt und differenziert werden. Da hilft der Paketname oftmals am besten weiter.
Materiallager (SVN)
Zu jedem Linux-Paket welches die als Unterbau gewählte Distribution mitbringt, existiert ein Pendant als Arktur-Paket, sofern für das erstgenannte Arktur-spezifische Ergänzungen oder Modifikationen bereitgestellt werden. Ausnahmen sind möglich, wo sie die Handhabung vereinfachen. Das Arktur-seitige Paket hat einen identischen Namen, entsprechend der Benennung des Paketes aus dem Unterbau. Dieser wird je nach Bedarf ergänzt, mindestens aber mit einem zusätzlichen Kürzel versehen, zum Beispiel "grub.ar.deb" oder "linux-image-generic.ar.deb". Arktur-Pakete die kein Gegenstück in der Basisdistribution haben, erhalten einen frei gewählten Namen, der einer für Linux-Pakete allgemein üblichen Namensgebung folgt.
Im repository befinden sich die Quellen für jedes Arktur-spezifische Paket in einem eigenen Verzeichnis das den gleichen Namen trägt, das aber ohne die Endung ".deb" bleibt. Alle diese Verzeichnisse liegen auf gleicher Ebene im Bereich ".../arktur/trunk/src". Sollte eine Gruppierung gewünscht sein, so erfolgt sie nur indirekt. Sie geschieht anhand von besonderen Ordnern, die zur Erfüllung ihrer Hauptaufgabe (die Aliasfunktion) eine link-Sammlung enthalten, welche auf die symbolisch zugeordneten, aber tatsächlich hierarchielos auf einer Ebene liegenden Paketverzeichnisse verweist. Nur in Ausnahmefällen wird davon abgewichen und es werden Paketverzeichnisse als Subverzeichnisse in einem Ordner unter "src" zusammengefasst.
Metadaten im Materialbereich
Neben den Teilen eines Arktur-Paketverzeichnisses die bei jedem build-Vorgang in ein Debian-Archivpaket gepackt werden (die aktiven Quellen also), ist es möglich dass die Paketverzeichnisse weitere Dokumente oder Ordner enthalten die dort nur als Hilfsmittel bereitstehen (make-, preare-, Doku-, Spec- und Info-Dokumente beispielsweise). Eine automatische, signifikante Unterscheidung muss für den build-Vorgang sichergestellt werden. Das ist an anderer Stelle genauer definiert.
Vor allem die technische Spezifikation wäre Pflichtbestandteil in jedem Paketverzeichis. Zusätzliche Dokumentation, die ein Teilprojekt im grösseren Rahmen beschreibt liegt an anderer Stelle (in .../arktur/trunk/dok). Zwischen diesen unterschiedlichen Lagerstellen von Spezifikationen wird (wann immer möglich) anhand von Verweisen eine Verbindung hergestellt. Dabei hilft eine besondere Indexdatei welche in jedem maßgeblichen Verzeichnis enthalten ist. Eine Detailbeschreibung befindet sich weiter unten.
Aufgabengebiete im Team
Ein Aufgabengebiet, verantwortlich betreut von genau einer Person, kann beliebig viele Arktur-Pakete umfassen. Die Zahl richtet sich nach der Größe und Komplexität des Gebietes. Auch hier gilt aber, dass ein Gebiet so klein sein soll wie möglich, soweit ein umzusetzendes Ziel dabei noch definierbar ist. Kleiner als der Umfang eines einzelnen Paketes geht es natürlich nicht.
Die Betreuung mehrer Aufgabengebiete durch eine Person ist kein Problem, allerdings sollte die Verantwortung dabei auch zu tragen sein und eine angemessen schnelle Erledigung sollte nicht durch zu viele Aufgaben erschwert werden. Besser ist die Betreuung weniger Gebiete und der Wechsel zu anderen Aufgaben, nachdem die ersten in möglichst kurzer Zeit restlos fertiggestellt wurden.
Aufgabengebiete verständlich machen
Zu jedem Aufgabengebiet existiert ein Expose welches die Ausgangsbedingungen, die Ziele und eine grobe Umsetzungsidee beschreibt. Es unterscheidet sich von der technischen Spezifikation, die präzise Vorgaben für die Programmierarbeit und für die späteren Eigenschaften macht. Das Expose hat die Aufgabe die jeweils nicht in dem Teilprojekt engagierten Team-Entwickler(innen) in einer Weise zu informieren, die nicht das volle technische Verständnis der Sache erfordert. So soll einer Konfliktbildung vorgebeugt werden. Bereichsgrenzen sollen deutlicher werden, die Notwendigkeit von Schnittstellen soll ggf. leichter erkennbar werden.
Ein Expose ist die Kurzfassung einer (geplanten) kreativen Arbeit der Begriff wird hier analog zu dem des literarischen oder wissenschaftlichen Exposes genutzt (vgl. "http://de.wikipedia.org/wiki/Expose). Das bedeutet: Es dient dazu die Idee verständlich zu machen und deren Umsetzung zu skizzieren. Die Arbeit auf die sich das Expose bezieht ist noch nicht vollendet, unter Umständen noch nicht einmal begonnen. Demnach zielt ein solcher Text auch auf die Verständigung, mit Auftraggebern, oder mit Projektbeteiligten.
Das Ziel ist _nicht_ die zusammenfassende Darstellung einer Aufgabenforderung oder eines Pflichtenkataloges. Es geht allein um die Wünsche und Vorstellungen des/der Programmierers/Autorin. Sollte ein Autor ein etwaiges Pflichtenheft nicht vollständig oder abweichend umsetzen wollen, so müsste er dies in geeigneter Weise vertreten, beziehungsweise es müsste ein Weg gefunden werden durch ein Co-Projekt oder durch eine Beteiligung die noch nicht abgedeckten Bereiche zu ergänzen. Im Expose und in der anschließenden Produktionsarbeit ist die Autorin jedoch frei, ihrer eigenen Intention zu folgen, so wie sie dies für richtig hält! Das Expose hat in sofern eine sehr wichtige Funktion. Es klärt die anderen Teammitglieder frühzeitig über die geplanten Methoden und die Zielabsichten auf.
Überblick ermöglichen
Damit die Gemeinschaft (vor allem neu hinzu kommende Entwickler) die für ihr Teilprojekt Einfluss nehmenden Informationen auf möglichst zuverlässige und einfache Weise finden können, wird die Verzeichnisstruktur an jeder wichtigen Stelle mit einem kommentierten Index versehen. Ein jeder Index besteht aus einer einfachen Liste in einer Textdatei. Er kann jedoch zusätzlich mit Hilfe eines eigens geschaffenen Dokumentationstools in HTML-Dokumente konvertiert und darin automatisch mit den benannten Indexeinträgen verlinkt werden. Weitere Informationen liefert das Manual für das Editor- und Konvertertool "mk00index.sh".
Besondere Projektverzeichnisse
Link-Liste im .../trunk/info-Verzeichnis