Enlightenment: Von zwölf Jahren zu drei Monaten Entwicklungzyklus

Linuxtag 2014

Bis zur Veröffentlichung von Enlightenment 17 vergingen zwölf Jahre. Durch viel Automatisierung und bessere Organisation sei nun aber ein Erscheinungszyklus von etwa drei Monaten möglich, versichert Stefan Schmidt von Samsung.

Artikel veröffentlicht am 8. Mai 2014, 17:47 Uhr, Sebastian Grüner

Die Enlightenment-Bibliotheken erscheinen inzwischen alle drei Monate. (Bild: Enlightenment)

Die Arbeiten an Enlightenment 17 begannen im Jahr 2000 und sollten bis 2012 dauern. In diesen zwölf Jahren lag die Entwicklung teilweise komplett brach. Durch viel Aufwand und Umstrukturierungen gelang die Veröffentlichung schließlich doch noch und erfolgt derzeit im Drei-Monats-Rhythmus. Was das Team dafür alles umkrempelte, erklärt Samsung-Mitarbeiter und Enlightenment-Entwickler Stefan Schmidt auf dem diesjährigen Linuxtag.

Dabei spart er soziale Faktoren fast vollständig aus und konzentriert sich auf technische Erklärungen. Doch letztlich helfe dem Team eine funktionierende und vor allem verlässliche Infrastruktur enorm, sagt er. Die Arbeitsweise der Community passe sich den neuen Gegebenheiten meist an, was sich dann gegenseitig positiv beeinflusse.

Multifunktionswerkzeug Git

Während der Entwicklung von E17 arbeitete das Team oft unkoordiniert und der Code ließ sich teilweise monatelang nicht kompilieren, etwa weil sehr große Änderungen direkt in den Hauptzweig eingepflegt wurden. Die Umstellung auf die Versionskontrolle Git vereinfachte die Code-Pflege erheblich.

Veränderungen werden nun in vielen kleinen Beiträgen eingepflegt und die Release-Manager fordern ausführliche Erklärungen. Code, der sehr viel verändert, kann nun zudem in einzelnen Zweigen besser gepflegt werden.

Aufräumen und Testen

Im Lauf der Jahre wurde dem Code eine Vielzahl an Konfigurationsoptionen hinzugefügt, die teilweise sogar für die Entwickler nicht mehr überschaubar waren. Zur einfachen Pflege hat das Team die Anzahl an Optionen schlicht reduziert.

Idealerweise sollten für sämtliche dieser Einstellungen Tests zur Verfügung stehen. Doch so weit ist das Team noch nicht. Bisher werden lediglich knapp 30 Prozent des Codes abgedeckt, was in Zukunft aber ausgebaut werden soll, ebenso wie das automatische Durchführen dieser Tests.

Bauen, Bauen, Bauen

Doch die wohl wichtigste Neuerung ist die Einführung des Continous Integration Werkzeugs Jenkins gewesen. Damit baut das Team den Hauptentwicklungszweig für jeden Beitrag in eben diesen. Dabei werden verschiedene Compiler verwendet und der Code wird für mehrere Architekturen kompiliert - wodurch viele Fehler überhaupt erst bemerkt werden.

Darüber hinaus experimentierte das Team mit unterschiedlichen statischen Code-Analysen und setzt etwa auf die Werkzeuge von Coverity. Durch die nun unmittelbar per IRC oder E-Mail ankommenden Fehlerbenachrichtigungen würden Probleme auch wesentlich schneller behoben, da dies einen gewissen sozialen Druck auf die Entwickler ausübe.

Letzteres ist dann auch einer der wenigen Kommentare zu sozialen Einflüssen auf die Community. Gegen Ende des Vortrags resümiert Schmidt, dass es lediglich einer Person bedürfe, die die notwendige Arbeit übernehme. Der Rest der Beteiligten werde sich in den meisten Fällen einfach anpassen.