Koha/Entwicklung

Aus Admin Kuhn GmbH
< Koha
Version vom 5. April 2018, 23:06 Uhr von Admin (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Die Entwicklung des Bibliothekssystems Koha als Open Source-Software wurde ursprünglich von einer neuseeländischen Stiftung (dem Horowhenua Library Trust) beauftragt und 1999 innert vier Monaten durch die Firma Katipo Communications, Ltd durchgeführt, sodass die erste Installation bereits am 2. Januar 2000 in Produktion gehen konnte.

Die Weiterentwicklung von Koha geht seither üblicherweise von den einsetzenden Bibliotheken selber aus: Sie wünschen eine neue Funktion oder die Behebung eines Fehlers - es muss also ein sogenannter "fix" entwickelt werden. Entweder tut die Bibliothek das selber, sie bittet die Koha Community darum oder sie beauftragt damit einen Programmierer. Der erstellte "fix" wird dann ans Koha-Projekt geschickt, wo er einen Test und eine Qualitätskontrolle durchläuft. Funktionierende Fehlerbehebungen werden dann üblicherweise in die aktuelle stabile Version aufgenommen, neue Funktionen mit der kommenden Version veröffentlicht. All das geschieht transparent in der Öffentlichkeit - ein vorhandener "fix" kann also bei Bedarf mit den notwendigen Kenntnissen jederzeit auch selber in die eigene Koha-Installation eingefügt werden. Der Programmcode und auch die Datenbankbeschreibung von Koha stehen jedermann zu jeder Zeit zur freien Verfügung.

Die Weiterentwicklung von Koha ist eine der Hauptaktivitäten der Koha-Gemeinschaft, die sich daneben aber auch mit vielen anderen Dingen beschäftzigt, etwa der Anfertigung von Dokumentationen und Übersetzungen, der Durchführung von Test und der Beantwortung von Anwenderfragen. Auch die Koha-Anwender selber können zur Verbesserung des Bibliothekssystems beitragen, indem sie die praktischen Fragen anderer Anwender beantworten, Fehler melden und neue Funktionen anregen, Vorschläge zur Verbesserung von Arbeitsabläufen machen oder ganz allgemein ihre eigenen Informationen mit anderen teilen (z. B. die MARC Frameworks oder Berichte).

Gegenwärtig wird Koha von einem grossen Entwicklerkreis (bisher insgesamt rund dreihundert Programmierer auf der ganzen Welt) aktiv weiterentwickelt und verbessert. Dabei findet unter den sponsernden Bibliotheken eine enge Zusammenarbeit statt. Die Firma Black Duck geht davon aus, dass in Koha rund 201 Mannjahre Entwicklungsarbeit stecken (Stand: Dezember 2016).

Ablauf der Entwicklung

Neuer Programmcode gelangt auf die folgende Weise in Koha hinein. Alle Entwickler halten sich dabei an dieselben Regeln.

Wer Beschreibung Bugzilla-Status
"bug reporter" Meldung eines Falles in Bugzilla (unter https://bugs.koha-community.org/bugzilla3/). Dabei muss es sich nicht zwingend um einen Programmfehler (engl. bug) handeln, sondern der Fall kann auch einen Verbesserungsvorschlag oder einen Wunsch nach Erweiterung (engl. enhancement) des Programms betreffen.
"patch writer" Ein Flick (engl. patch) wird in den Koha-Programmcode eingefügt. Needs sign-off
Release Manager Unter Umständen wird der Flick auf einen eigenen QA-Zweig (engl. branch) verschoben
"patch signer" Der Flick wird getestet und im Erfolgsfall absigniert (engl. sign off).

Der Test kann beispielsweise in einer "Sandbox" erfolgen.

Signed off
QA Manager Der Flick wird von einem Mitgglied des QA-Teams getestet. Passed QA
Release Manager Der Flick wird vom Release Manager getestet und im Erfolgsfall absigniert. Anschliessend wird er in den Entwicklungszweig "master" verschoben. Patch Pushed
Release Maintainer Unter Umständen entscheidet der Release Maintainer, dass der Flick auch in die stabile Version verschoben werden muss Pushed to stable.
"bug closer" Der Fall wird als gelöst gekennzeichnet. Resolved/Fixed
Der Fall wird erst dann tatsächlich geschlossen, wenn diejenige Koha-Version bzw. Koha-Revision offiziell veröffentlicht wird, welche den entsprechenden Flick enthält.

Organisation

Der gesamte Programmcode wird öffentlich durch eine Vielzahl von Personen auf der ganzen Welt entwickelt. Der Code wird dabei nach Funktionserweiterungen sowie der Behebung von Fehlern unterschieden. Erweiterungen werden alle sechs Monate jeweils im Mai und im November veröffentlicht - dabei handelt es sich um die x.x.0-Bezeichnungen (3.8.0, 3.10.0, 3.12.0 usw.). Jeden Monat werden zusätzlich Fehlerbehebungen (bugfixes) veröffentlicht, dabei handelt es sich um die Bezeichnungen 3.12.1, 3.12.2 usw.

Da die Entwicklung von Programmierern auf der ganzen Welt geleistet wird, muss ihre gemeinsame Arbeit gut organisiert sein. Dies wird durch eine klare Zuweisung von Rollen und der damit verbundenen Kompetenzen gewährleistet. Die Rollen werden in einem öffentlichen Wahlverfahren besetzt - dabei gibt es unter anderem die folgenden Rollen.

Rolle Person
(Koha 3.12)
Aufgabe
Release Manager Jared Camins-Esakov Koordination der jeweils kommenden Freigabe. Die Freigaben sind zeitgesteuert (time based) - es wird regelmässig alle sechs Monate eine Freigabe veröffentlicht, welche die verfügbaren und getesteten Erweiterungen enthält. Der Release Manager ist im Fall von Differenzen auch für die Klärung und Entscheidung verantwortlich.
Release Maintainer Chris Cormack (3.8, 3.10)
Liz Rea (3.6)
Pflege der letzten stabilen Version. Dazu werden ausgewählte Erweiterungen übernommen und Korrekturen in dieser Version eingepflegt.
Quality Assurance Manager Katrin Fischer Qualitätskontrolle des Programmcodes, der ins System aufgenommen wird - diese muss immer durch mindestens zwei Personen von zwei verschiedenen Firmen erfolgen. Unterstützung durch mehrere "QA Assistants".
Documentation Manager Nicole C. Engard Erstellung der englischsprachigen Originaldokumentation.
Translation Manager D. Ruth Bavousett Bereitstellung der Infrastruktur für Übersetzungen in andere Sprachen.
Packaging Manager Robin Sheat Erstellung der DEB-Softwarepakete, welche unter der Linux-Distribution Debian installiert werden können.

Die an der jeweils eingesetzten Version beteiligten Bibliotheken und Entwickler können über die Dienstoberfläche im Menü "Über Koha > Koha-Team" angezeigt werden.

Die Kommunikation der Entwickler untereinander erfolgt hauptsächlich über Mailinglisten, Chat, Wikis und Blogs. Jährlich findet ausserdem an weltweit wechselnden Orten der Koha-Kongress KohaCon statt. Dort und an den damit verbundenen "Hackfests" können sich die Entwickler auch persönlich kennenlernen. Die Teilnahme am Kongress war bisher jeweils kostenlos.

Als Fehlermeldesystem wird die Software Bugzilla verwendet. Dort können Fehler und Erweiterungswünsche gemeldet werden, ebenso ist eine Suche nach Sponsoren und Entwicklern möglich.

Als Versionskontrollsystem dient GIT, bei der Verwaltung der Übersetzungen kommt Pootle zum Einsatz. Für die Entwicklungsstatistik wird Ohloh verwendet.

Weblinks

Herausgeber Sprache Webseitentitel Anmerkungen
country NZ.gif Koha Community eng Gitwbm Software-Versionsverwaltung des Koha-Projekts
country NZ.gif Koha Community eng SchemaSpy Analysis of testsql_commentswbm Datenbankbeschreibung mit Hilfe der Open Source-Software SchemaSpy
country NZ.gif Koha Community eng Bugzillawbm Fehlermeldesystem
country NZ.gif Koha Community eng Koha Dashboardwbm Übersicht der aktuellen Entwicklung
country US.gif Youtube eng Koha Library Software History Visualizationwbm Eine mit Gource visualisierte Geschichte der Koha-Entwicklung von 1999-2010
country NZ.gif Koha Community eng Development workflowwbm Offizielles Wiki - Arbeitsablauf bei der Entwicklung
country NZ.gif Koha Community eng Release Schedulewbm Offizielle Webseite - Veröffentlichungsweise
country NZ.gif Koha Community eng Supportwbm Offizielle Webseite
country US.gif Koha Community eng Ohlohwbm Koha-Entwicklungsstatistik
country US.gif Black Duck Open Hub eng Koha library automation package : estimated costwbm