Notizen vom Grazer Plasmasprint

Vor ein paar Tagen bin ich von einem wunderbaren Plasma-Sprint in Graz, Österreich, nach Hause zurückgekehrt. Zwischen COVID-19 und dem Plasma-Sprint im letzten Jahr, der zugunsten des Goals-Megasprints ausfiel, war dies erst mein dritter Plasma-Sprint in Person! Daher war ich sehr gespannt auf die Teilnahme. Es gibt viel zu besprechen!
Eine Übersetzung.

Man sagt oft, dass es zwei Arten von Sprints gibt: "sprechende" Sprints, bei denen es hauptsächlich darum geht, große Themen zu besprechen, und "arbeitende" Sprints, bei denen die Leute viel Code schreiben. Dieser Sprint war ein bisschen von beidem - eine gute Mischung, denke ich.

Ich für meinen Teil wollte über einige wichtige Themen sprechen und sehen, ob wir sie aus der Blockade befreien können. Und das haben wir getan! Neben diesen Diskussionen gab es noch viele weitere, aber hier ist eine Zusammenfassung derjenigen, die ich geleitet habe:

Plasma LTS

Es ist kein Geheimnis, dass unser Plasma LTS ("Long-Term Support") Produkt nicht großartig ist. Es bedeutet eigentlich nur, dass wir Fehlerbehebungen länger als üblich zurückportieren - normalerweise ohne sie überhaupt zu testen, da kein Plasma-Entwickler gerne auf alten Zweigen lebt oder sie testet. Und es gibt kein entsprechendes LTS-Produkt für Frameworks oder Gear-Apps, was eine Menge Löcher im LTS-Schirm hinterlässt. Hinzu kommt, dass "LTS" für jeden etwas anderes bedeutet; viele haben eine weit gefasste Definition des Begriffs, die ihnen Erwartungen an die Stabilität vermittelt, die unmöglich zu erfüllen sind.

🎓 Wir sind zu dem Schluss gekommen, dass die recht begrenzte Natur des Produkts nicht den Erwartungen der Nutzer entspricht, und haben daher beschlossen, es nicht weiterzuführen. Stattdessen werden wir den effektiven Support-Zeitraum der normalen Plasma-Releases etwas verlängern, indem wir ein zusätzliches Bug-Fix-Release hinzufügen, wodurch wir von fünf auf sechs kommen.

Wir haben auch das Thema der Reduzierung von drei auf zwei Plasma-Feature-Releases pro Jahr wieder aufgegriffen, mit einem viel längeren Zeitplan für Bug-Fix-Releases. Das würde jede Plasma-Version zu einer Art Mini-LTS machen, und wir würden auch versuchen, sie mit den halbjährlichen Veröffentlichungsplänen von Kubuntu und Fedora in Einklang zu bringen.

Zum Hintergrund: Auf der letzten Akademy haben wir beschlossen, diese Zeitplanänderung zu verschieben, bis alle KDE-Probleme auf der Wiki-Seite Wayland known significant issues behoben sind. Während des Sprints sahen wir uns die Liste noch einmal an und stellten fest, dass sie viel kürzer war als im letzten Jahr, da die meisten verbleibenden Punkte in Arbeit waren oder kurz vor dem Abschluss standen! Also haben wir uns darauf geeinigt, das Thema bei der diesjährigen Akademy in etwa 4 Monaten wieder aufzugreifen (Erinnerung, einen Vortrag einzureichen!).

Ich hoffe, dass wir bis dahin entweder alles erledigt haben oder so weit sind, dass wir den neuen Zeitplan trotzdem einhalten können - letzteres wäre das, was wir für die Wayland-by-default-Einführung getan haben.

Das Konzept des "Langzeit-Supports" verschwindet jedoch nicht, nur weil wir keine unserer Software-Releases mehr mit diesem Label versehen. In Wirklichkeit war es sowieso immer ein Label, das von den Distros vergeben wurde - die Distros machen die harte Arbeit, ein LTS-Endprodukt aus unzähligen Software-Komponenten zu bauen, die selbst nie von ihren eigenen Entwicklern als LTS deklariert wurden. Das ist eine Menge Arbeit.

💡 Daher haben wir beschlossen, unsere Botschaft zu verstärken, dass Benutzer von KDE-Software auf LTS-Distributionen Probleme an ihre Distribution und nicht an KDE melden sollten. Ein LTS-Software-Stack ist komplex und erfordert viel technischen Aufwand, um ihn zu stabilisieren; die am besten geeigneten Personen, um Probleme bei LTS-Distributionen zu lösen, sind die Ingenieure, die sie zusammenstellen. Dies wird den KDE-Bug-Triagern und -Entwicklern Zeit geben, sich auf aktuelle Probleme zu konzentrieren, die sie reproduzieren und beheben können, anstatt Zeit mit Problemen zu verschwenden, die aufgrund eines sehr unterschiedlichen Software-Stacks nicht reproduziert werden können, oder die bereits vor Monaten oder Jahren behoben wurden, uns aber trotzdem gemeldet werden, da viele Benutzer mit den Zeitplänen für Software-Veröffentlichungen und dem Melden von Fehlern nicht vertraut sind.

Inhalte von Drittanbietern und Theming

Wir hatten einige Schwierigkeiten mit der UX, wie Benutzer Inhalte von Drittanbietern erhalten und was diese mit ihrem System machen, sobald sie sie erhalten haben. Viele werden sich an das Problem vom letzten Jahr erinnern, als ein defektes globales Theme eines Drittanbieters zu einem Datenverlust bei den Benutzern führte.
Das war Very Bad™.

Das Problem hier ist, dass QML-basiertes Theming von Natur aus gefährlich ist, weil QML Code ist; es gibt keine Möglichkeit, QML-Theming sicher zu machen, also arbeiten wir daran, davon wegzukommen. David Edmundson hat kürzlich auch darüber geschrieben.

Bisher haben wir bereits das QML-Theming aus dem Sperrbildschirm entfernt (eine Komponente, die sehr empfindlich auf Stabilität und Sicherheit reagiert!), und in diesem Sprint haben wir auch die OSDs in Angriff genommen. Wir haben auch geplant, das QML-Theming von Startbildschirmen und Anmeldebildschirmthemen zu entfernen, und stattdessen werden Sie einfach benutzerdefinierte Bilder auswählen können.

Einige Dinge werden jedoch immer QML-Code enthalten müssen, wie Widgets von Drittanbietern und Wallpaper-Plugins. Für diese haben wir einen Plan entwickelt, um sie in eine Sandbox zu packen, damit sie nicht die Welt in die Luft jagen können, wenn sie sich daneben benehmen. Dadurch werden auch Globale Themen sicher, da sie in Globale Themen eingebunden werden können. Ich war nicht in der Lage, alle Details des vorgeschlagenen Sandbox-Systems zu verfolgen, so dass andere die Lücken in ihren eigenen Blog-Beiträgen füllen müssen!

Schließlich sprachen wir über den Distributionskanal von https://store.kde.org, der über die Dialoge Get new [thing], die in den Systemeinstellungen und KDE-Anwendungen zu finden sind, zugänglich ist. Was einige vielleicht nicht wissen, ist, dass dieser Distributionskanal nicht wirklich KDE gehört; er ist einfach ein thematisches Frontend zu https://pling.com. Und das ist eines der Probleme: die Leute denken, dass dieser Kanal KDE gehört, aber das ist nicht der Fall! Einige andere Bedenken betrafen das Fehlen einer genehmigungspflichtigen Moderation für neue Inhalte mit Stabilitäts- oder Sicherheitsimplikationen; das Fehlen eines automatischen Lintings für Inhalte, um sicherzustellen, dass sie gültig sind; die Unfähigkeit, eine Mindestplasmaversion für QML-basierte Inhalte festzulegen; und die traurige Überflutung des Ortes mit KI-erstelltem Schrott mit geringem Aufwand. Wir haben auch über einige UX-Probleme in diesen Dialogen und in Discover gesprochen und wie wir sie angehen können.

Wir haben darüber nachgedacht, wie unser idealer Mechanismus für die Verbreitung von Inhalten von Drittanbietern aussehen würde, wenn wir ihn von Grund auf neu erstellen würden, und inwieweit unsere derzeitige Benutzeroberfläche diesem Ziel entspricht oder nicht. Ich werde mich mit den Leuten hinter Pling in Verbindung setzen, um zu sehen, ob wir dort an Verbesserungen arbeiten können, damit wir die Realität mehr mit unseren Wünschen in Einklang bringen können!

Activities

Aktivitäten befinden sich schon seit langem in einer seltsamen Situation. Es ist eine Funktion, die etwas schwierig in einem Elevator Pitch zu erklären ist, und mit einem begrenzteren Umfang als Sie vielleicht erwarten. Wir waren uns alle ziemlich einig, dass sie nicht ideal ist und nicht so nützlich wie sie sein könnte.

Also haben wir uns viele Alternativen überlegt und dabei das Feedback und die Erfahrungen der Teilnehmer des Sprints berücksichtigt, die Activities bereits nutzen oder es gerne nutzen würden, wenn es ihren Bedürfnissen entspräche.

Etwas, das immer wieder zur Sprache kam, war der Wunsch, bestimmte Anwendungen in verschiedenen Aktivitäten unterschiedlich zu nutzen. So könnte man zum Beispiel in der Aktivität "Privat" den E-Mail-Client so einrichten, dass er nur die privaten E-Mail-Konten anzeigt, während man in der Aktivität "Arbeit" die gleiche Anwendung nur für die beruflichen E-Mail-Konten oder für beide einrichten könnte. Aber es wäre in jeder Aktivität die gleiche E-Mail-Client-Anwendung, nur anders konfiguriert!

Diese Funktionalität muss derzeit von jeder App bereitgestellt werden, die ihre eigenen "Profile" oder "Sitzungen" implementiert - und natürlich tun das die meisten nicht. Daher hatten wir die Idee, daraus einen Systemdienst zu machen, der im Grunde die Funktionalität mehrerer Profile/Sessions in jede App einbauen kann. Dies wäre am einfachsten für containerisierte Anwendungen, die bereits über einen eigenen Speicherort für Konfigurationsdaten verfügen, daher werden wir hier beginnen. Aber es ist möglich, dass wir es auch für nicht containerisierte, traditionell verpackte Anwendungen öffnen können, indem wir Firejail oder eine ähnliche Technologie verwenden.

Wir sind der Meinung, dass diese Funktion auch außerhalb von Activities nützlich sein könnte, daher haben wir sie erst entwickelt! Nachdem sie in Produktion ist und die Probleme beseitigt wurden, würde sie dann die Grundlage für den neuen Bereich des Activities-Systems bilden: "Konfigurieren und verwenden Sie Ihre Anwendungen und virtuellen Desktops in jeder Aktivität anders".

Für all dies gibt es noch keine Zeitvorgaben; es befindet sich noch in der Phase, in der aus einer Diskussion ein Plan wird.

Telemetrie

Es herrschte weitgehende Einigkeit darüber, dass der Status quo nicht ideal ist: Wir sammeln nur sehr wenige Daten von Personen, die sich angemeldet haben (weil die Option standardmäßig deaktiviert ist), und wir haben keine Möglichkeit, die Daten zu ändern, die wir als Reaktion auf neu entdeckte Fragen, die wir gerne beantwortet hätten, sammeln.

Nehmen wir zum Beispiel an, wir wollen einen sehr nischenhaften KWin-Effekt entfernen, von dem wir glauben, dass ihn niemand nutzt. Im Moment haben wir keine Möglichkeit herauszufinden, wie viele Leute diesen Effekt aktiviert haben und wie viele von ihnen ihn tatsächlich nutzen - ganz zu schweigen davon, sie nach dem Grund zu fragen! Wir müssen uns also bei dieser Entscheidung auf unser Bauchgefühl verlassen, oder wir lassen es bleiben und machen es gar nicht erst.

Daher haben wir beschlossen, die Art und Weise, wie wir Telemetriedaten sammeln, zu ändern, damit sie mehr der üblichen und erfolgreichen Steam Hardware-Umfrage ähnelt. Unsere Telemetrie-UX wird dieselbe sein: Die Leute werden ein Dialogfenster sehen, in dem sie aufgefordert werden, an der Umfrage teilzunehmen, und darin werden sie sehen, welche Daten gesammelt werden. Sie haben die Möglichkeit, Ja oder Nein zu sagen oder die Umfrage für immer zu deaktivieren. Und bei jeder Umfrage können wir die gesammelten Daten auf das abstimmen, was wir wirklich wissen wollen! So könnten wir Informationen über den KWin-Effekt sammeln und die Benutzer sogar auffordern, einen kleinen Text zu schreiben, der erklärt, warum.

Wir haben auch darüber gesprochen, dass der derzeitige Ort, an dem die gesammelten Daten angezeigt werden, nicht ideal ist. Im Moment gibt es eine grafische Benutzeroberfläche, die ein wenig kaputt ist, und eine Webseite, in die man rohe SQL-Abfragen eingeben muss, um etwas anderes als die Standardvisualisierungen zu sehen. Nicht ideal! Wir haben ein Brainstorming über eine bessere Web-UX durchgeführt, damit wir die Daten, die wir derzeit sammeln, besser nutzen können. Wir waren uns auch einig, dass wir die gesammelten Daten öffentlich machen wollen, so wie Valve es mit den Ergebnissen der Steam Hardware Survey macht.

Und mehr

Außerdem konnte ich zwischen den Diskussionsrunden viel Zeit zum Hacken nutzen, was sehr nützlich war. Dadurch, dass ich mich mit anderen Leuten zusammensetzen konnte, wurden einige Blockaden gelöst, sowohl bei mir als auch bei ihnen, als Ergebnis einiger produktiver Gespräche von Angesicht zu Angesicht! Außerdem konnte ich viele alte Freunde wiedersehen und einige zum ersten Mal persönlich treffen. Auch die Stadt Graz war wunderschön - ein so vernünftiger und menschlicher Ort.

Vielen Dank an die TU Graz, die uns zu diesem Sprint eingeladen hat, an Techpaladin Software für die Übernahme meiner Reise- und Unterkunftskosten und an Harald Sitter für die Organisation!

Ein Serice von s3n🧩net