Lead: Fedora 45 enthält mehrere weitreichende Änderungen auf Systemebene, die über automatisierte Tests hinaus geprüft werden sollten. Die Fedora-Community organisiert deshalb fokussierte Testtage zu ausgewählten Komponenten wie GNOME 51, RPM 6.1, den neu erzeugten Boot- und Live-Images, OpenSSL 4.0 und der Umstellung auf kmscon. Dieser Artikel erklärt, welche Bereiche besonders Aufmerksamkeit brauchen, wie Sie teilnehmen und wo Sie Probleme melden.

Warum Community‑Tests wichtig sind

Automatisierte Testläufe und CI fangen viele Regressionen auf, doch sie können nicht alle realen Kombinationen von Hardware, Treibern und Nutzergewohnheiten abdecken. Probleme wie ein Boot‑Iso, das auf bestimmten Laptops nicht startet, oder ein verändertes RPM‑Verhalten, das einen etablierten Workflow stört, zeigen sich oft erst in der Praxis. Testtage bündeln die Aufmerksamkeit für einzelne Änderungen, Entwicklerinnen und Entwickler sind im Chat erreichbar, und Mitarbeitende der QA‑Gruppe begleiten die Abläufe.

Die Schwerpunkte von Fedora 45

Aus dem ChangeSet haben die Verantwortlichen mehrere Punkte identifiziert, die besonders getestet werden sollten:

• GNOME 51 – Desktop, Grafikstack, Peripherie und Kernanwendungen; erster Testtag ist auf GNOME 51 ausgerichtet.
• RPM 6.1 – Update auf Version 6.1 bringt u. a. erzwingende Signaturprüfung, Verlagerung von DNF‑Repo‑Konfigurationen nach /usr und Verbesserungen an rpmkeys. Da RPM Paketmanagement und Transaktionen steuert, betrifft das potenziell jeden Teil des Systems.
• OpenSSL 4.0 – Major‑Update der TLS‑Bibliothek. Änderungen an OpenSSL können praktisch jede Komponente mit Netzwerkanbindung beeinflussen.
• Neu erzeugte Boot- und Live‑Images – Images werden von Grund auf mit image‑builder neu gebaut. Das ändert die Produktionskette für Installations‑ und Live‑Medien, daher sind Boot‑ und Installtests auf unterschiedlicher Hardware und in VMs nötig.
• kmscon statt fbcon – KMS‑Konsole (kmscon) ersetzt die bisherige kernel‑Framebuffer‑Console (fbcon) als Default‑VT. Das kann Auswirkungen auf Textkonsole, Kernelmeldungen und frühes Boot‑Output haben.
• Weitere Updates – darunter Python 3.15, GRUB EFI für Confidential Computing, und Kernel‑/CoreOS‑Änderungen, die in einzelnen Testtagen geprüft werden sollen.

Geplante Testtage und Themen (Auswahl)

Die Testplanung entstand aus einem Quality‑Meeting und einem Forge‑Ticket, daraus resultieren mehrere thematische Veranstaltungen. Zu den bereits festgelegten Terminen beziehungsweise Themen gehören:

• GNOME 51 Desktop – erster Testtag, fokussiert auf Desktop‑Erlebnis, Grafik, Peripherie und Kernanwendungen.
• I18n Testwoche – Eingabemethoden, Locale‑Konfigurationen und Tastaturlayouts stehen hier im Vordergrund.
• RPM 6.1 – spezifische Prüfungen zu Signaturen, NSS‑Support für Nutzer/Gruppen‑Abfragen und Ausgaben von rpmkeys.
• Installations‑ und Live‑Media – Booten und Installieren der neu gebauten boot.iso und Live‑Images auf physischer Hardware und in VMs.
• KDE – wahrscheinlich Prüfungen rund um KDE 6.7.
• Cockpit – ein Testtag für die Web‑Adminoberfläche, da lange kein spezieller Test angeboten wurde.
• GRUB EFI / Confidential Computing – relevant für spezielle Hardware und bestimmte VM‑Setups.

Die Liste ist nicht endgültig. Weitere Punkte wie OpenSSL 4.0, CoreOS‑Änderungen und Kernel 7.2 werden weiterhin geprüft und gegebenenfalls mit eigenen Testtagen versehen. Aktuelle Termine und Beschreibungen finden Sie auf testdays.fedoraproject.org.

Welche Tests sind besonders hilfreich?

Testerinnen und Tester sollten sich nach Möglichkeit an realen Arbeitsabläufen orientieren. Empfehlenswerte Prüfungen sind:

• Upgrade‑Versuch von bestehenden Fedora‑Installationen auf die neuesten Pakete.
• Booten der neuen boot.iso und Live‑Images auf unterschiedlicher Hardware (Laptops, Desktops, Server) sowie in VMs.
• Alltagsfunktionen testen: Suspend/Resume, Wi‑Fi, Bluetooth, externe Monitore, Drucker und Audio.
• Grafiktests mit NVIDIA/AMD/Intel‑Treibern — insbesondere bei proprietären Treibern sind Regressionsrisiken höher.
• Workflows prüfen, die RPM‑Signaturen oder Repository‑Konfigurationen nutzen, um mögliche Konflikte mit RPM 6.1 aufzuspüren.
• Netzwerk‑ und TLS‑abhängige Applikationen testen, um mögliche Auswirkungen durch OpenSSL 4.0 zu erkennen.

Mitmachen: Schritt für Schritt

1. Erstellen Sie ein Fedora‑Konto, falls noch nicht vorhanden; das ist nötig, um Testergebnisse zu melden.
2. Suchen Sie einen passenden Testtag auf der Testday‑Website und lesen Sie die zugehörige Wiki‑Seite mit konkreten Testfällen.
3. Führen Sie die vorgesehenen Tests aus — viele Tasks lassen sich in einer VM erledigen, Hardware‑spezifische Checks benötigen ein echtes Gerät.
4. Melden Sie Ergebnisse über die Testday‑App bzw. das dort verlinkte Formular. Bei Problemen sollten Sie so viel Kontext wie möglich angeben: Hardwaremodell, Kernel‑Version, Logauszüge und reproduzierbare Schritte.
5. Bei Bedarf treten Sie dem Matrix‑Channel #test-day:fedoraproject.org bei, um mit Entwicklern und QA‑Leuten in Echtzeit zu kommunizieren.

Die Testday‑Webanwendung ist Open Source und auf Forge als quality/testdays-web verfügbar; Verbesserungswünsche oder Fehlerberichte sind willkommen.

Selber Testtage vorschlagen

Wenn Sie Pakete betreuen oder im ChangeSet eine Änderung sehen, die aus Ihrer Sicht breitere Tests braucht, können Sie eigenständig einen Testtag anstoßen. Erstellen Sie dafür ein Ticket im Forge (Pfad: forge.fedoraproject.org/quality/tickets), taggen Sie es mit „test days“ und beschreiben Sie kurz, was geprüft werden soll. Die QA‑Teammitglieder unterstützen beim Formulieren von Testfällen und der Organisation.

Weitere Hilfsmittel

Abgesehen von den offiziellen Testtagen ist tägliches Testing erwünscht. Das Projekt bietet das Kommandozeilenwerkzeug fedora-easy-karma, das bereits installierte Updates erkennt und das Einsenden von Karma‑Votes an Bodhi vom Terminal aus ermöglicht. Auch dieses Tool ist auf Forge gehostet und offen für Beiträge.

Fazit

Fedora 45 bringt einige substantielle Änderungen, die praktische Tests auf unterschiedlichen Systemen erfordern. Community‑Testtage sind ein effizienter Weg, um Fehler frühzeitig zu finden und das Release robuster zu machen. Bei Interesse genügt ein Fedora‑Konto, die Teilnahme an einem Testtag und die Bereitschaft, Ergebnisse strukturiert zu melden. Entwickler und QA‑Teams stehen in den vorgesehenen Chats zur Unterstützung bereit.