Da glaubst du falsch, denn sonst hätte man das schon längst korrigiert.
Candidates sind nochmal eine spezielle Stufe und werden nicht zwingend Releases.
Es steht natürlich jedem frei, zu Testen was er möchte. Aber in produktivem Einsatz, nicht jammern wenn's knallt.
Wie auch immer, inzwischen gibt es 125b1
Thunderbird 128 beta wurde vor eine paar Wochen freigegeben, das Problem mit "IMAP folder corruption" besteht nach wie vor, jetzt schon für sechs Monate:
Mal sehen, was mit der Release-Version passiert. Zur Erinnerung: 102.0 war ziemlich kaputt und führte sogar zu Datenverlust. 115.0 hatte ein ziemlich kaputtes neues User Interface. Naja, und bei 128.0 könnte man wieder bei der "Datenkorruption" sein. Wie nett.
Was ich in dem Bug-Report nicht so recht verstehe: Reparieren des Index behebt das Problem, aber dennoch haben die Leute korrupte mbox-Dateien?
Hier ist was passiert: Für lokal-synchronisierte IMAP-Ordner (Offline-Benutzung) lädt TB alle Nachrichten vollständig runter und speichert sie lokal in einer mbox-Datei (es sei denn, maildir wird benutzt). Im Laufe der Benutzung, während Nachrichten angesehen werden und neue hinzukommen, geht die lokale Datei kaputt, d.h. einige Nachrichten werden als Krautsalat angezeigt. Keiner hat es bisher reproduzieren können, und, um es böse zu sagen, das TB-Team hat bisher entscheidendes Bemühen, dass Problem zu lösen, vermissen lassen. In den letzten sechs Monaten wäre dazu Zeit gewesen, jetzt schreibt der Entwickler, er sei bei der Brandbekämpfung, soweit leider ohne Erfolg. Wenn das so als 128.0 ausgeliefert wird, wird es einige unzufriedene Benutzer geben.
Abhilfe: Den Ordner reparieren. Das führt dazu, dass absolut alle Nachrichten neu runtergeladen werden, bei vielen Benutzern dürfte es sich um mehrere GB handeln. Das ist unter verschiedenen Aspekten nicht akzeptabel. Ich würde auch nicht meine Hand dafür ins Feuer legen, dass das das Problem immer löst, es wäre ja denkbar, dass während des Runterladens und gleichzeitiger Benutzung das Problem wieder auftritt.
Das heißt bei IMAP wird der Index nicht einfach anhand der vorhandenen mbox-Datei neu erstellt. Dies wäre ja ein zentraler Unterschied zu POP, wo (im Grunde zwingend) nur aus den mbox-Dateien der Index wiederhergestellt wird.
Genau. Bei IMAP wird sozusagen alles weggeschmissen und neu vom Server angefordert. Wusstest Du nicht? Mach doch mal einen Repair auf einem IMAP-Ordner und beobachte die Status-Zeile.
Der Fehler führt dazu, dass die mbox-Datei wirklich beschädigt ist. Es sieht so aus, als würde Nachricht Y in die Mitte von Nachricht X geschrieben. Kann man sehen, wenn man die mbox-Datei im Editor öffnet.
Ich überlege, ob ich die eben gebaute Betterbird-Beta-Version, die dasselbe Problem hat, mal als Versuchskaninchen in Produktion ausprobieren sollte. Da das Problem noch nicht analysiert ist, besteht eine Chance, dass auch POP betroffen ist, da werden ja auch mbox-Dateien geschrieben. In dem Falle würde der Fehler echten Datenverlust verursachen. Es gibt keine dahingehenden Berichte, aber ausschließen kann ich es nicht.
Noch ein Knaller: Die neue Ordner-Komprimierung braucht bis zu 5.5 Mal so lange, was vorher eine Minute gedauert hat, dauert jetzt 5m:30s. Da freut sich der Benutzer:
1904208 - Severe performance regression in Folder Compact (mozilla.org)
Deshalb benutze ich nun schon seit mehreren Jahren nur noch das maildir-Format und habe tatsächlich keinerlei dazugehörige Probleme.
Hmm, ja, ich kenne einen IMAP-"Großbenutzer", der auch mit maildir zufrieden ist. Aber ein Ordner mit 200.000 Nachrichten in einzelnen Dateien finde ich persönlich kein gutes Konzept.
Meines Erachtens sind die separaten Dateien bspw. für inkrementelle Backups gerade gut geeignet.
Nutze auch seit Jahren maildir und läuft ohne Probleme. Mailbox hat keine Zukunft.
Meines Erachtens sind die separaten Dateien bspw. für inkrementelle Backups gerade gut geeignet.
Hmm, mein inkrementeller Backup vergleicht schon ca. 200.000 Dateien. Mir maildir würden geschätzt noch 300.000 dazu kommen. Und Windows ist nicht schnell, viele kleine Dateien zu kopieren. 200.000 Mal 1 KB ist viiiiieeeeel laaaaangsaaaaamer als einmal 200 MB in einem Rutsch. Kann auf Linux besser sein.
Aber Umstellung aller Instanzen auf maildir ist nun auch nicht gerade *die* Lösung, wenn das weiterhin als im Beta-Status propagiert wird. Ich nutze es zwar hier und da durchaus auch und es hat mir schon aus immer wiederkehrenden Problemen mit mbox herausgeholfen, nur schaffe ich es rein zeitlich bestimmt nicht, in den nächsten paar Tagen um die 50 Thunderbird-Installationen mal eben auf maildir zu migrieren.
Tatsächlich habe ich jetzt erst mal angefangen, Updates via policy zu deaktivieren, um einigen betreuten Anwendern das drohende Ungemach zu ersparen. Allerdings muss ich dann zu gegebener Zeit alle Instanzen noch mal abklappern, um die Updatesperre wieder rauszunehmen. Das ist mehr als lästig und mal in Unterstützung in Form von Spenden übersetzt (einige meiner betreuten Nutzer spenden wirklich und regelmäßig, weil Thunderbird entsprechend wertgeschätzt wird), kontraproduktiv, wenn sie dann sehen, dass solche Verrenkungen vollzogen werden müssen.
Wie stellen sich die Entscheider für Prioritäten in Sachen Entwicklungsschritte, Features, Releasezyklus, Testing, .., eigentlich vor, dass das draußen beim Kunden ablaufen soll? Der Druck von irgendeiner Seite muss ja offenbar enorm sein, dass man den Nutzer-Feedbacks gegenüber so stoisch am Prozedere festhält und es auch nicht schafft, nach mehreren Jahren die Prozesse besser in den Griff zu bekommen.
Wie stellen sich die Entscheider für Prioritäten in Sachen Entwicklungsschritte, Features, Releasezyklus, Testing, .., eigentlich vor, dass das draußen beim Kunden ablaufen soll?
Diese Frage setzt voraus, dass es kompetente Entscheider gibt. Also: Wie Du weißt, lief TB bis Ende 2016 nur mit Freiwilligen, man war also auf deren guten Willen angewiesen. Ich war im November 2016 der erste Angestellte.
Trotz der mittlerweile mehr als 35 Angestellten, ist die Freiwilligen-Mentalität geblieben. Viele beruht auf dem guten Willen der Entwickler. Detailliert Planung gibt es nicht, und die Wirklichkeit hinkt den ab-und-zu publizierten sog. "roadmaps" Jahre hinterher. Nur eine kurze Liste der Dinge, die auch im Jahre 2024 noch fehlen oder noch kaputt sind.
1. Menü wieder oben, wo es hingehört. Seit Supernova kaputt.
2. Linux Movemail
3. Linux system tray und minimise to tray
4. Order manuell in der Reihenfolge verschieben (da gab's mal ein Add-on)
5. Dark mode in HTML-Inhalten
6. Globale Datenbank zur Unterstützung von Konversationen
7. Schnellsuche-Feedback seit Supernova kaputt
8. Account-Farben (nur teilweise und m.E. unzureichend implementiert).
Außer Punkt 6. ist in Betterbird alles enthalten(*).
In der derzeitigen 128 beta haben wir dann noch die Dateibeschädigung bei IMAP (Thema hier) und das neu geschriebene Komprimieren dauert bei großen Ordnern sechs mal so lange wie das alte, da ein Windows API benutzt wird, das bekanntermaßen sehr langsam ist.
Jetzt zu den Entscheidern. Hier ein paar Referenzen, mit denen Du Dir ein eigenes Bild machen kannst:
https://bugzilla.mozilla.org/show_bug.cgi?id=1625741#c87 vor zwei Jahren. Dort wurde von zwei Jahren das (bisher unerfüllte, s.o.) Versprechen ausgesprochen, Movemail wiederherzustellen.
Hier https://blog.thunderbird.net/2024/04/team-t…sked-questions/ schrieb man hinsichtlich der Globalen Datenbank (Zitat): Our goal is to have a new global message database in place by May 31.
Gemeint war Ende Mai 2024. Leider zeigt der entsprechende Bug seit November 2022 keine Aktivität (außer das hinzufügen von Kommentaren), so dass es dem Leser überlassen ist zu beurteilen, ob die Ankündigung aus Unwissenheit oder Vorsatz falsch gemacht wurde.
Nur zum Thema Beta- und ESR-Release: Geliefert wird einfach das, was am Stichtag fertig ist. Punkt. Da ist es ganz egal, ob Daten der Benutzer unwiederbringlich verloren gehen, wie es z.B. in 102.0 passiert ist. Zur Auffrischung des Gedächtnisses empfehle ich:
[wsa='159'][/wsa]
Das Problem wurde dort m.E. recht vorsichtig beschrieben (Zitat): ... was für POP-Konten und das sogenannte "Lokale Konto" (oder auch "Lokale Ordner") bleibenden Datenverlust bedeuten kann.
Dass 115 "Supernova" mit verschiedenen Fehlern in der Benutzeroberfläche, die einige Benutzer verzweifeln ließen, ausgeliefert wurde, dürfte noch im Gedächtnis sein. Einige Benutzer sahen nur einen weißen Bildschirm, da der neue UI-Code nicht mit ihren Daten klarkam. Es wurde dann ca. drei Monate lang nachgebessert, einige Schäden (Punkt 1. und 7.) sind immer noch vorhanden, und die Möglichkeit, mehrere Ordner zu selektieren, wurde jetzt erst in 128 wiederhergestellt.
---
(*) Für Punkt 1 benutzt Betterbird übrigens einen Patch, der von einem Thunderbird-Freiwilligen and das TB-Team geliefert wurde. Die dortigen Entscheider haben ihn jedoch mit einem m.E. nicht stichhaltigen Argument zurückgewiesen, so das zurzeit nur BB davon profitiert. Für Punkt 4 benutzt BB auch einen Patch eines TB-Freiwilligen mit einigen wichtigen Änderungen. Der Freiwillige wartet immer noch darauf, dass sich die Entscheider der Sache annehmen. Nachzulesen hier.
Hallo zusammen,
meine konkrete Befürchtung ist: es wird wieder eine Katastrophe werden!
Wahrscheinlich wird sich wieder nicht (oder nicht ganz) an den überlappenden ESR-/Release-Zyklus mit mindestens zwei weiteren 115er-Versionen parallel zur 128er-Version gehalten (was übrigens beim viel gescholtenen Firefox sehr gut funktioniert und durchgehalten wird).
Nehmen wir 115.12.2 als letzte an, dann müsste es parallel zur 128.0 eine 115.13 geben. Danach parallel zur 128.1 eine 115.14 und parallel zur 128.2 eine 115.15 (115 damit dann EOL).
Und man sollte zur Sicherheit der Nutzergemeinde frühestens erst mit 128.3 automatische Updates freigeben, wenn überhaupt.
Aber wahrscheinlich wird es wieder ablaufen, wie bei der 102 und der 115. 'Ist der Ruf erst ruiniert, lebt es sich völlig ungeniert ...'
Ich habe, um es klar zu sagen, nach den letzten Versionssprüngen (manches lief ja schon in früheren Versionswechseln vor dem Versionssprung zu 102 unrund, um es vorsichtig zu formulieren) sehr viel Vertrauen verloren.
Gruß
Feuerdrache
Hmm, also, als Katastrophe würde ich es nach derzeitigem Kenntnisstand nicht bezeichnen. ESR-Versionen haben immer überlappt, in diesem Falle 115 und 128. FF pflegt 115 bis 115.2, danach werden die Benutzer auf 128.3 gebracht, siehe: https://whattrainisitnow.com/calendar/
Welche Experimente die Entscheider bei TB machen, um Leute von 115 auf 128 zu bringen, ist unbekannt. Und es ist auch unbekannt, in welchem Zustand 128 dann sein wird. Mann kann nur hoffen, dass die Fehler von 102 nicht wiederholt werden.
Die IMAP-Ordner-Beschädigung kann repariert werden, aber schlimmstenfalls muss der verdutzte Benutzer eben massive Datenmengen neu vom IMAP-Server runterladen. Von dem angesprochenen Problem beim Komprimieren sind "nur" Windows-Benutzer mit mbox betroffen, was allerdings die Mehrheit sein dürfte.
Abwarten und Tee trinken, insbesondere beim Komprimieren 
... Von dem angesprochenen Problem beim Komprimieren sind "nur" Windows-Benutzer mit mbox betroffen, was allerdings die Mehrheit sein dürfte.
Abwarten und Tee trinken, insbesondere beim Komprimieren
Dann bin ich ja beruhigt, da ich zur Gemeinde der Linux-Nutzer gehöre. 
Letzteres sowieso. Nur nicht aus der Ruhe bringen lassen!
Noch ein Knaller: Die neue Ordner-Komprimierung braucht bis zu 5.5 Mal so lange, was vorher eine Minute gedauert hat, dauert jetzt 5m:30s.
Entwarnung, obige Behauptung war falsch. Nach längerem Testen stellte sich heraus, dass Komprimierung in 115 und 128 ungefähr gleich lange dauert und dass es Umstände gibt, wo sie sowohl in 115 als auch 128 viel länger dauert. Das hängt damit zusammen, wie die Ansicht sortiert war, denn die Ansicht wird nach der Komprimierung wiederhergestellt, was lange dauern kann.
Der einzige mir bekannte Fehler in 128 ist nach wie vor die IMAP-Ordner-Beschädigung.
