On 23 Jan 2022 08:07, Peter Koerber wrote:
> Danke vielmals Jörg, Du bist offenbar der Erste hier in dieser NG,
> welcher den Problemen nachgeht und dann auch Lösungen findet! Super! Du
> bist Spitze!
Hallo Peter und alle Anderen,
ich poste da mal in einen neuen Thread, damit es nicht in einem
vielleicht ignorierten Thread landet. Es ist eine Antwort auf
<ssiuqs$8d9l$
1...@gwaiyur.mb-net.net>.
Peter spricht in seinem Artikel, wenn auch nicht mit der freundlichsten
Wortwahl (siehe "Programmier-Idioten", zu denen ich ja auch einst
gehörte), die großen Probleme der Thunderbird-Entwicklung an.
Hier die Probleme, wie ich sie sehe.
Thunderbird hat sich aus der Netscape-Suite entwickelt und basiert zum
Teil auf Code, der 20 Jahre und älter ist. Es gibt z.T. Code, den keiner
mehr versteht und den keiner anfassen will. Bei meiner letzten Zählung
im August 2021 gab es ca. 14.000 (vierzehn Tausend) offene Tickets, was
nicht heißen soll, dass 14.000 Dinge nicht funktionieren. Viele dieser
Tickets sind überholt, nicht reproduzierbar, etc.
Peter schreibt: "ganze existierende Bugliste abzuarbeiten". Das ist ein
Ding der Unmöglichkeit, es wäre aber andererseits möglich, die Tickets
zu sichten, irrelevante zu schließen, und alte und nervige Bugs zu
priorisieren und zu reparieren. So einen Prozess gibt es bei TB aber nicht.
Peter schreibt: "bitte eine Bugreport eröffnen". Sicher ist ein
Bug-Report die einzige Möglichkeit einen Bug repariert zu bekommen.
Darüber, dass es für den Normal-Benutzer schwierig ist, einen Bug zu
melden, hat Peter berichtet. Das weit größte Problem ist aber, dass es
bei TB keinen Prozess gibt, der garantiert, dass ein neuer Bug-Report
überhaupt zur Kenntnis genommen wird, geschweige denn bearbeitet wird.
Eine bessere Chance hat man, wenn man den zuständigen Entwickler im
Bug-Report direkt anspricht, aber dazu braucht man Insider-Knowledge.
Ein offizielles System der sog. Bug-Triage, wo jeder neue Bug angeguckt
und klassifiziert wird, existiert nicht.
Was macht also das zurzeit ca. 15-köpfige TB-Team mit den angesprochenen
Spendengeldern, die sich pro Jahr um 2-3 Millionen US-$ belaufen
(
https://stats.thunderbird.net/#financials)?
Dazu muss ich etwas ausholen: TB basiert auf der sog. Mozilla-Plattform,
d.h. Code, der auch von Firefox benutzt wird. Diese Mozilla-Plattform
ändert sich täglich, so dass sehr viel Arbeit investiert werden muss, TB
entsprechend anzupassen. Dabei gehen unweigerlich auch Dinge kaputt,
siehe dazu der nächste Absatz. Als Zweites "renoviert" das Team, den
Code, das wird auch refactoring[0] genannt. Dabei sollte die Funktion
100% erhalten bleiben, aber natürlich schleichen sich Fehler ein, siehe
dazu der nächste Absatz. Ab und zu werden auch Funktionen entfernt,
siehe z.B. movemail für Linux. Als Drittes baut das Team an neuen
Funktionen und neuen User-Interface (UI), was nicht immer auf Gegenliebe
der Benutzer stößt, siehe z.B, die Zeilenschaltung. Und an allerletzter
Stelle steht die Reparatur von alten und nervigen Bugs, sofern sie nicht
beim refactoring oder der Entfernung von defekten Funktionen (zufällig)
repariert oder erledigt wurden. Soweit so gut?
Bei den vier genannten Aktivitäten, 1) Anpassungen an die
Mozilla-Plattform 2) refactoring 3) neue Funktionen 4) alte Bugs,
passieren natürlich neue Fehler, bei denen entweder bestehende
Funktionen beschädigt werden, d.h. Regressionen eingeführt werden, oder
die neue Funktion selbst noch nicht richtig funktioniert. Hier wäre es
jetzt die Aufgabe der QA-Abteilung (quality assurance) Fehler zu finden,
zu melden und deren Behebung zu verfolgen, so dass der Produkt
weitgehend ohne *neue* Fehler, d.h. Regressionen, geliefert wird. Denn
nichts ist ärgerlicher als etwas, was in der alten Version noch
funktionierte, jetzt aber nicht mehr. Und jetzt die Überraschung: TB hat
nicht nur keine systematische Bug-Triage (s.o.), es gibt auch keine
QA-Abteilung (kein Witz). Das Testen wird den Entwicklern überlassen und
eine paar Freiwilligen, die jeden Release testen und denen zwangsläufig
viele Fehler entgehen. Und so nimmt die Zahl der ausgelieferten
Regressionen ständig zu, da ja auch immer mehr Entwickler am Produkt
arbeiten. Eine Zählung findet Ihr hier [1].
Jetzt noch ein Wort in eigener Sache: Wie Ihr in dem zitierten Artikel
lesen könnt, habe ich von 2015 bis 2019 bei TB gearbeitet und auch
Versionen 52 bis 68 betreut. Dabei war mein Fokus immer auf Qualität und
der Reparatur alter Bugs[2] (4. Aktivität, s.o.) und die Unterstützung
der Benutzer durch Lesen und Beantworten (so gut es ging) aller neuen
Bug-Reports. Aufgrund der oben geschilderten Probleme war ich immer
heftiger Kritiker des Managements, aber "kill the messenger" war
einfachere Lösung. Jetzt setze ich meine Arbeit in Betterbird fort, wo
ich Probleme und Regressionen behebe, so gut es eben geht. Auf jeden
Fall funktioniert Betterbird für mich selbst besser, und hoffentlich
auch für Andere.
Danke, dass Ihr bis zum Ende gelesen habt. Jörg.
P.S.: Beweise/Belege/Beispiele reiche ich gerne nach. Beispiel einer
Regression: In TB 91.3.2 konnte man den Kalender nicht drucken.
[0]
https://en.wikipedia.org/wiki/Code_refactoring
[1]
https://linuxnews.de/2021/12/thunderbirds-bruder-betterbird/
[2] Total veraltet, aber noch relevant:
http://www.jorgk.com/misc/Mozilla-work.pdf