Koha/Entwicklung: Unterschied zwischen den Versionen

Aus Admin Kuhn GmbH
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
(37 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
Die <b>Entwicklung</b> des Bibliothekssystems [[Koha]] wurde ursprünglich von einer neuseeländischen Stiftung (dem <span class="plainlink">[http://www.library.org.nz/ Horowhenua Library Trust]</span>) beauftragt und 1999 innert vier Monaten durch die Firma <span class="plainlink">[http://katipo.co.nz/ Katipo Communications, Ltd]</span> durchgeführt, sodass die erste Installation bereits am 2. Januar 2000 in Produktion gehen konnte.
{{TOCright}}
Die <b>Entwicklung</b> des Bibliothekssystems [[Koha]] als [[Open Source]]-Software wurde ursprünglich von einer neuseeländischen Stiftung (dem <span class="plainlink">[http://www.library.org.nz/ Horowhenua Library Trust]</span>) beauftragt und 1999 innert vier Monaten durch die Firma <span class="plainlink">[http://katipo.co.nz/ Katipo Communications, Ltd]</span> 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-Gemeinschaft darum oder sie beauftragt damit einen Programmierer. Der erstellte "fix" wird dann ans Koha-Projekt geschickt und durchläuft dort einen Test und eine Qualitätskontrolle. Fehlerbehebungen werden ü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 notewendigen Kenntnissen jederzeit auch selber in die eigene Koha-Installation eingefügt werden.
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.
<!-- http://www.koha-community.org/support -->


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).
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 (rund hundert Programmierer auf der ganzen Welt) aktiv weiterentwickelt und verbessert. Dabei findet unter den sponsernden Bibliotheken eine enge Zusammenarbeit statt.
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 <span class="plainlinks">[https://www.openhub.net/p/koha/estimated_cost Black Duck]</span> 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.
 
{| class=wiki width=100%
! width=15% | Wer !! Beschreibung !! width=15% | Bugzilla-Status
|-
| "bug reporter" || Meldung eines Falles in [[Bugzilla]] (unter https://bugs.koha-community.org/bugzilla3/). Dabei muss es sich nicht zwingend um einen [https://de.wikipedia.org/wiki/Programmfehler Programmfehler] (engl. bug) handeln, sondern der Fall kann auch einen Verbesserungsvorschlag oder einen Wunsch nach Erweiterung (engl. enhancement) des Programms betreffen.
* siehe dazu die [https://wiki.koha-community.org/wiki/Bug_Reporting_Guidelines Bug reporting guidelines]
|
|-
| "patch writer" || Ein Flick (engl. patch) wird in den Koha-Programmcode eingefügt.
* siehe dazu [https://wiki.koha-community.org/wiki/SubmitingAPatch Submitting a patch]
| 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).
* siehe dazu [https://wiki.koha-community.org/wiki/Sign_off_on_patches Sign off on patches]
 
Der Test kann beispielsweise in einer "[https://de.wikipedia.org/wiki/Sandbox Sandbox]" erfolgen.
* siehe dazu [https://wiki.koha-community.org/wiki/Sandboxes Sandboxes]
| 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.
* siehe dazu [https://wiki.koha-community.org/wiki/How_the_RM_push How the RM push]
| 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 ==
== 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.
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.
Zeile 19: Zeile 59:
! Release Manager
! Release Manager
| Jared Camins-Esakov
| Jared Camins-Esakov
| Koordination der jeweils kommenden Freigabe. Die Freigabeversionen sind zeitgesteuert (time based) - es wird also 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.
| 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
! Release Maintainer
| Chris Cormack
| <span class="plainlink">[http://wiki.koha-community.org/wiki/Chris_Cormack Chris Cormack]</span> (3.8, 3.10)<br>Liz Rea (3.6)
| Pflege der letzten stabilen Version. Dazu werden ausgewählte Erweiterungen übernommen und Korrekturen in dieser Version eingepflegt.
| Pflege der letzten stabilen Version. Dazu werden ausgewählte Erweiterungen übernommen und Korrekturen in dieser Version eingepflegt.
|-
|-
Zeile 42: Zeile 82:
|}
|}


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 <span class="plainlink">[http://koha-community.org/kohacon/ KohaCon]</span> statt. Dort und an den damit verbundenen "Hackfests" können sich die Entwickler auch persönlich kennenlernen. Die Teilnahme am Kongress ist kostenlos.
Die an der jeweils eingesetzten Version beteiligten Bibliotheken und Entwickler können über die Dienstoberfläche im Menü "Über Koha > Koha-Team" angezeigt werden.
 
<!-- {| class=wiki width=200 align=right framed
| <small>
* 2006 Paris (Frankreich)
* 2009 Plano (USA)
* 2010 Oceania (Neuseeland)
* 2011 Mumbai (Indien)
* 2012 Edinburgh (Grossbritannien)
* 2013 Reno (USA)
* 2014 Cordoba (Argentinien)
</small>
|} -->
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 [http://koha-community.org/kohacon/ 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 <span class="plainlinks">[http://de.wikipedia.org/wiki/Bugzilla Bugzilla]</span> verwendet. Dort können Fehler und Erweiterungswünsche gemeldet werden, ebenso ist eine Suche nach Sponsoren und Entwicklern möglich.
Als [http://bugs.koha-community.org/ Fehlermeldesystem] wird die Software [http://de.wikipedia.org/wiki/Bugzilla Bugzilla] verwendet. Dort können Fehler und Erweiterungswünsche gemeldet werden, ebenso ist eine Suche nach Sponsoren und Entwicklern möglich.
<!-- Schweregrad der gemeldeten Fehler / http://stackoverflow.com/questions/2469178/how-do-you-define-the-severity-critical-high-low-etc-of-bugs -->


Als Versionskontrollsystem dient <span class="plainlinks">[http://de.wikipedia.org/wiki/GIT GIT]</span>, bei der Verwaltung der Übersetzungen kommt <span class="plainlinks">[http://de.wikipedia.org/wiki/Pootle Pootle]</span> zum Einsatz.
Als Versionskontrollsystem dient [http://de.wikipedia.org/wiki/GIT GIT], bei der Verwaltung der Übersetzungen kommt [http://de.wikipedia.org/wiki/Pootle Pootle] zum Einsatz. Für die Entwicklungsstatistik wird [http://de.wikipedia.org/wiki/Ohloh Ohloh] verwendet.
<!--
<!--
TODO
TODO
Zeile 53: Zeile 107:
http://www.koha-support.ch/index.php?id=166
http://www.koha-support.ch/index.php?id=166
-->
-->
==


== Weblinks ==
== Weblinks ==


{{Weblinks}}
{{Weblinks}}
{{url|NZ|Koha Community|eng|http://wiki.koha-community.org/wiki/Roles_for_3.12|Roles for 3.12|Die Rollenverteilung für Koha 3.12}}
{{url|NZ|Koha Community|eng|http://git.koha-community.org/|Git|Software-Versionsverwaltung des Koha-Projekts|icon=http://www.google.com/s2/favicons?domain=git.koha-community.org}}
{{url|NZ|Koha Community|eng|http://wiki.koha-community.org/wiki/Roles_for_3.14|Roles for 3.14|Die Rollenverteilung für Koha 3.14}}
{{url|NZ|Koha Community|eng|http://schema.koha-community.org/|SchemaSpy Analysis of testsql_comments|Datenbankbeschreibung mit Hilfe der Open Source-Software SchemaSpy|icon=http://www.google.com/s2/favicons?domain=schema.koha-community.org}}
{{url|NZ|Koha Community|eng|http://bugs.koha-community.org/|Bugzilla|Fehlermeldesystem|icon=http://www.google.com/s2/favicons?domain=bugs.koha-community.org}}
{{url|NZ|Koha Community|eng|http://dashboard.koha-community.org/|Koha Dashboard|Übersicht der aktuellen Entwicklung|icon=http://www.google.com/s2/favicons?domain=koha-community.org}}
{{url|US|Youtube|eng|http://www.youtube.com/watch?v{{=}}Tl1a2VN_pec|Koha Library Software History Visualization|Eine mit Gource visualisierte Geschichte der Koha-Entwicklung von 1999-2010}}
{{url_wikikohacommunity|Development_workflow|Development workflow| - Arbeitsablauf bei der Entwicklung}}
{{url_kohacommunity|about/release-schedule|Release Schedule| - Veröffentlichungsweise}}
{{url_kohacommunity|support|Support|sublink=<ul>
<li>[http://koha-community.org/support/paid-support/ Paid support]</li>
</ul>|icon=http://www.google.com/s2/favicons?domain=koha-community.org}}
{{url|US|Koha Community|eng|http://www.ohloh.net/p/koha|Ohloh|Koha-Entwicklungsstatistik|icon=http://www.google.com/s2/favicons?domain=www.openhub.net}}
{{url|US|Black Duck Open Hub|eng|https://www.openhub.net/p/koha/estimated_cost|Koha library automation package : estimated cost|}}
{{Fuss}}
{{Fuss}}
{{Kat|Koha}}
{{Kat|Koha}}

Aktuelle Version vom 5. April 2018, 22:06 Uhr

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
Koha Community eng Gitwbm Software-Versionsverwaltung des Koha-Projekts
Koha Community eng SchemaSpy Analysis of testsql_commentswbm Datenbankbeschreibung mit Hilfe der Open Source-Software SchemaSpy
Koha Community eng Bugzillawbm Fehlermeldesystem
Koha Community eng Koha Dashboardwbm Übersicht der aktuellen Entwicklung
Youtube eng Koha Library Software History Visualizationwbm Eine mit Gource visualisierte Geschichte der Koha-Entwicklung von 1999-2010
Koha Community eng Development workflowwbm Offizielles Wiki - Arbeitsablauf bei der Entwicklung
Koha Community eng Release Schedulewbm Offizielle Webseite - Veröffentlichungsweise
Koha Community eng Supportwbm Offizielle Webseite
Koha Community eng Ohlohwbm Koha-Entwicklungsstatistik
Black Duck Open Hub eng Koha library automation package : estimated costwbm
Von «https://adminkuhn.ch/adminkuhn/index.php?title=Koha/Entwicklung&oldid=4484»