Stress

Eigentlich ist man als Entwickler kostenloser OpenSource Software, der auch noch so blöd ist, dafür Support anzubieten, immer im Stress. Das gilt umso mehr, wenn man auch noch von der Entwicklung anderer abhängig ist, langsam die Lust an der Sache verliert und recht anfällig für emotionalen Stress ist.

Schon seit der Frühjahrstagung in Darmstadt weiß ich, dass LaTeX etwas an \InputIfFileExists ändern wird, was zu einer Warnung bei Verwendung von scrlfile führt. Noch auf der Tagung habe ich das Problem beseitigt, so dass da gar nicht erst Stress aufkommen kann. Auf derselben Tagung hat Frank latex-dev vorgestellt, das es Paketentwicklern ermöglicht, Neuerungen in LaTeX frühzeitig zu testen. Eine sehr gute Hilfe, um Stress bei den Entwicklern vorzubeugen. Es hat dann zwar noch etwas gedauert, bis das auf CTAN und in TeX Live verfügbar war, aber seither verwende ich es min. zur Erzeugung meiner Entwicklerversionen von KOMA-Script. Leider habe ich trotzdem übersehen, dass Ende August eine interne Anweisung in \InputIfFileExists noch einmal umbenannt und der Befehl selbst robust gemacht wurde. Also letztlich bin ich selbst schuld, wenn dadurch unmittelbar nach der Release von LaTeX 2019-10-01 Stress bei mir aufkam.

Schon seit mehreren Jahren biete ich einfache Möglichkeiten, Änderungen an KOMA-Script vorab zu testen. Der Aufwand, den ich dafür treibe, das sowohl für TeX-Live-Anwender als auch MiKTeX-Anwender ohne riesige Computerkenntnisse zu ermöglichen, ist recht hoch. Trotzdem ist es eine Maßnahme, um theoretisch Stress unmittelbar nach einer KOMA-Script-Release zu reduzieren, weil so viele Menschen im Vorfeld ohne Risiko testen können. Ohne Risiko deshalb, weil man einfach auch wieder auf die Release-Version zurück wechseln kann. Leider lohnt sich der Aufwand für diesen Zweck eher wenig. Bisher gibt es kaum Bug-Reports aufgrund der zur Verfügung gestellten Prereleases. Wenn, dann kommen frühe Bug-Meldungen eher von den sehr wenigen, die direkt mit der Entwicklerversion testen.

Wäre das der einzige Grund für die Prereleases würden diese also streng genommen mehr Stress verursachen als sie vermeiden. Derzeit steht diesbezüglich beispielsweise an, für TeX Live ab 2019 mehrere Revisionen zu unterstützen, was allerdings erhebliche Änderungen an den Perl-Scripten nach sich zieht, die ich für die Erstellung der immerhin vier Repositries (TDS-Archive, MiKTeX für Windows Installationspakete, TeX Live < 2016, TeX Live >= 2016) entwickelt habe. Ob dabei eventuell ein weiteres Repository für TeX Live > 2016 aber < 2019 benötigt wird, muss ich mir auch noch anschauen.

Glücklicherweise bieten die Prereleases aber auch die Möglichkeit, auf schwerwiegende Probleme recht schnell zu reagieren. So wurde beispielsweise kurz nach der Veröffentlichung von LaTeX 2019-10-01 nicht nur das oben genannte nicht schwerwiegende Problem in KOMA-Script beseitigt und per Prerelease eine korrigierte Version bereitgestellt. Es wurde auch ein weiterer Bug gemeldet, der weit schwerwiegender ist und nicht nur zu einer Warnung, sondern einem Fehler führte, für den es nur eher unschöne Hacks als Workaround gibt. Das Problem konnte aber schnell beseitigt und eine Prerelease veröffentlicht werden. Das bewahrte mich davor eine Release zu erzeugen, aus der künstlich unfertige Neuerungen entfernt wurden, die noch nicht fertig dokumentiert und getestet waren. Etwas, was immer sehr viel Stress bedeutet, weil die Release dafür von Hand erzeugt werden muss und ich nie sicher sein kann, dass ich nicht zusätzliche Bugs produziere. Die Prereleases helfen hier also ebenfalls Stress zu vermeiden.

Und natürlich ist nicht jeder damit zufrieden zu stellen, dass er sich zur Bugbeseitigung eine Prerelease installieren soll, zumal er damit das Risiko neuer Bugs eingeht und dann eben nicht einfach zur offiziellen Release zurück kann, weil er ja wegen des ursprünglichen Bugs auf die Prerelease angewiesen ist. Das bringt für mich den Stress, neue Bugs in Prereleases möglichst rasch zu beseitigen und eine neue Prerelease zu erstellen – wenn denn solche Bugs überhaupt an mich gemeldet werden. Wie oben erwähnt passiert das eher selten, so dass dieser Stress eher emotionaler (oder eingebildeter) Natur ist.

Für Anwender bringt die Verwendung einer Prerelease übrigens ebenfalls eine Stressverminderung. Da ich bei neuen Bugs in Prereleases eher rasch Abhilfe in Form einer neuen Prerelease schaffe, dagegen bei Bugs in einer Release bis zur Veröffentlichung der nächsten Release schon einmal mehrere Wochen vergehen können, reduziert sich das Risiko bei Updates sogar. Außerdem sind meist mehrere Prereleases als TDS-Archiv und als MiKTeX-Installatonspaket verfügbar, so dass für etwas versiertere Anwender sogar die Wahl zwischen unterschiedlichen Entwicklungsständen besteht. Das setzt natürlich auch voraus, dass ein Bug gemeldet wird. Leider betrachten es vielen LaTeX-Anwender und selbst einige Prerelease-Anwender als ausreichend, wenn sie ein Problem in irgend einem Forum in der ihnen genehmen Sprache ansprechen und dort einen Workaround serviert zu bekommen, statt den Bug in Englisch oder Deutsch an mich zu melden. Auf diesem Weg bleiben nicht nur viele Bugs unentdeckt, ich werde sogar dafür angepflaumt, dass ich meine Zeit nicht auch noch dafür investiere, ständig das Internet nach nicht erfolgten Bug-Reports scanne. Das sind dann diese Stresserlebnisse, bei denen ich gerne den Computer abschalte und wahlweise in den Garten gehe oder mich auf mein Rad schwinge.

Leider bin ich selbst offenbar auch ein eher wenig gründlicher Arbeiter. Regelmäßig geschieht es, dass Stunden bis Tage nach einer Release trotz aller Gegenmaßnahmen Bugs – teilweise auf abenteuerlichen Umwegen – an mich gemeldet werden. Wenn Releases von KOMA-Script mit LaTeX-Releases oder Releases von grundlegenden Paketen nahezu zeitgleich erfolgen, steigt die Wahrscheinlichkeit und der Aufwand für die Bearbeitung dafür noch an. Wenn ich lange angekündigte Änderungen bezüglich der Beseitigung von üblen Hacks und ähnlichen Missfeatures oder längst obsoleten Dingen, nachdem ich das lange aufgeschoben habe, endlich durchführe, weil ihre Wartung schlicht nicht mehr zumutbar ist, dann steigt das Risiko für eine Flut von (nur teilweise) verständlichen Beschwerden natürlich. Da ich mich bemühe, alle noch so absurde Klagen höflich zu beantworten, steigt auch der Stress nach einer solchen Release enorm – nicht nur aufgrund der Erwartung solcher Ereignisse, sondern auch wegen ihrer realen Bearbeitung. Die Lust auf eine neue Release sinkt entsprechend schon im Vorfeld, was ebenfalls dazu beiträgt, dass ich irgendwann dann doch unter Zeitdruck gerate. Selbst gemachter Stress kommt also noch hinzu.

Auch bei der aktuellen Release von KOMA-Script 3.27 war das wieder so. Sowohl im Vorfeld der Release als auch jetzt, unmittelbar danach steigt der Stresslevel wieder einmal derart an, dass ich versucht wäre, den Computer auszuschalten. Aber natürlich würde das in diesem Fall nichts nützen. Die neuen Bugs müssen so oder so beseitigt werden. Je eher ich das mache, desto schneller verschwindet der Stress. Glücklicherweise gibt es sehr engagierte Menschen, die mithelfen, dass ich einmal dokumentierte Probleme nicht in diversen Foren mehrfach lösen helfen muss. Glücklicherweise gibt es auch Menschen, die in der Lage sind, Probleme kurz und prägnant auf den Punkt zu bringen und mir so helfen, einen Großteil der Lösungssuche bereits im Vorfeld zu erledigen. Glücklicherweise gibt es einen netten Menschen, der mir zumindest einen Aspekt einer neue (Bugfix-)Release abnimmt – es bleibt trotzdem genügend Arbeit.

So gelang es nicht nur, nach einem ¾ Jahr endlich KOMA-Script 3.27 mit vielen Erweiterungen und Detailverbesserungen zu veröffentlichen. Es ist zu erwarten, dass auch die darin enthaltenen neuen und alten Bugs gefunden und – soweit sie gemeldet werden – beseitigt werden. Dazu wird es dann je nach Dringlichkeit auch Workarounds, Prereleases und eine neue Release geben – trotz allen Stresses.

Bis demnächst
Markus