Wie können mehr Menschen an der Verbesserung von X.org für Ubuntu beteiligt werden? [geschlossen]

In Ubuntu ist X eines der kritischsten Elemente im Stapel. Als solche erhalten wir eine TONNE Fragen und Fehlerberichte darüber, wahrscheinlich ungefähr 100-mal so viele, wie wir mit Personal zu tun haben.

Canonical stellt zusätzliche Ingenieure ein, um an X zu arbeiten, was helfen wird. Dennoch gibt es viele Dinge, die außerhalb der Möglichkeiten von Canonical liegen. Ich halte es daher für sehr wichtig, dass eine starke Community an der Verbesserung von X in Ubuntu beteiligt ist, insbesondere Um all diese Unmengen an Fehlerberichten zu beantworten, zu testen und (hoffentlich) zu lösen.

Es ist jedoch schwierig, Leute zu finden, die an X arbeiten oder die Leute davon überzeugen, dass es sich für sie lohnt, ihre Zeit darin zu investieren. Wie würden Sie vorschlagen, Leute zu ermutigen, sich zu engagieren, die sonst vielleicht nicht daran denken, an X zu arbeiten?

Nun, wie alles, macht vieles es den Menschen leicht und zugänglich, sich darüber zu informieren. Nach dem, woran ich mich erinnere, kam ursprünglich nicht viel Hilfe von der Community. Dann, als einige Wiki-Seiten, die die regulären Prozesse beim Testen von Fehlern und einige Fehlertage erläuterten, viel mehr Community-Mitglieder involvierten. Auch wenn Sie eine regelmäßige Aktivität für die Community starten und denjenigen, die es versuchen, Hilfe anbieten können, werden Sie ein gewisses Interesse bekommen.

Wenn Sie Hilfe bei der Aktivität benötigen, können Sie mir eine E-Mail senden und mir bei der Organisation helfen.

Meine Antwort ist es, eine Wiki-Seite mit Fragen und Befehlen zu erstellen, um gute Informationen zur Fehlersuche zu erhalten und die Leute dazu zu bewegen, sich darauf einzulassen.

Für die Entwicklung ist es ein großes Problem. Für die meisten Funktionen zur Fehlerbehebung und -implementierung sind nur geringe Programmierkenntnisse von Xorg und Kernel erforderlich. Sie müssen also eine bestimmte Gruppe von Programmierern ansprechen und sie für sich interessieren. Ich habe hier keine Vorschläge, außer ein bisschen herumzufragen und zu sehen, wer in # ubuntu-x rumhängt, und sie zu fragen, ob sie helfen können.

Der Grund, warum X nicht viel Arbeit bekommt, ist, dass es eine enorme Menge an Wissen über die Funktionsweise von GPUs, Speicher usw. sowie über die Vertrautheit mit der X.org-Codebasis und zu einem gewissen Grad über die Kernel-Programmierung erfordert. Es ist keine triviale Sache, in die Community einzusteigen, und aus der Sicht der Community tun dies wahrscheinlich bereits diejenigen, die daran interessiert sind, an X- oder X-Treibern zu arbeiten. Es gibt derzeit keine Motivation für einen Entwickler, an Xorg zu arbeiten, abgesehen von persönlichem Interesse.

Das, was die Community hat, über das X.org-Entwickler nicht unbedingt verfügen müssen, ist der Zugriff auf eine große Auswahl an Hardware. Menschen, die bereit sind, die Zeit zu verbringen, um 'gute' Fehlerberichte zu schreiben und Treiber und Teile des Xorg-Stacks vor einer Veröffentlichung zu testen , werden den Ingenieuren wahrscheinlich mehr als alles andere helfen.

Derzeit gibt es ein Xorg Edgers Repo, mit dem ich Treiber auf meinem stabilen System teste. Es ist ziemlich einfach, ein einzelnes Paket zurückzusetzen, nachdem ich mit dem Testen fertig bin. Die einzige andere Möglichkeit, die wir testen können, besteht darin, entweder X selbst zu erstellen oder das Edgers-Repository zu installieren, das vom Upstream aus erstellt wird. Soweit ich das beurteilen kann, handelt es sich hierbei um einen X-Großhandelsersatz. Dies bedeutet, dass es ein Alles-oder-Nichts-Ansatz zum Testen von X ist.

Wenn Sie die Möglichkeit haben, 2 Versionen von X zu haben (und relativ einfach auswählen können), welche Sie verwenden möchten, können Tester nicht nur X testen, sondern anschließend zu einem funktionierenden Xorg zurückkehren, damit sie den Fehlerbericht einreichen können.

Als Entwickler, der sich nebenbei für X interessiert, habe ich folgende Probleme:

1. Ich habe nur Zugang zu einer Handvoll Grafikkarten und ich vermute, die meisten Leute haben nur Zugang zu einer. Daher kann ich nicht viel für die große Mehrheit der Bugs tun, die sich immer auf "irgendeiner anderen Karte" befinden.

2. Im Gegensatz zu den meisten Paketen kann ich keine einfache Testumgebung für eine neue Treiberversion erstellen. Virtuelle Maschinen haben ihre eigenen X-Treiber.

3. Ich kann nicht einfach auf den neuesten Treiber aktualisieren, ihn testen und dann zurücksetzen. Dies rät vom Experimentieren ab (denn wenn etwas schief geht, könnte ich genauso gut gemauert werden); es behindert auch Regressionstests.

4. Das letzte Mal, als ich nachgesehen habe, war es schwierig, einen Patch erfolgreich anzuwenden, X zu kompilieren und auszuführen, den gesamten Paket-Manager zu durchlaufen, auch Kernel-Module zu patchen und es war so ziemlich ein irreversibler Schritt.

5. Heutzutage teilen X-Treiber ihren Code zwischen Kernel, Mesa, udev (für Einstellungen und Standardeinstellungen) und Userland-Treibern auf. Was bedeutet, dass Patches ebenfalls aufgeteilt werden ...

Ich denke, die Antwort ist, das Anwenden und Zurücksetzen von Änderungen so zu gestalten, dass sie vom Paketmanager gehandhabt und einfach wiederhergestellt werden können, wenn Ihr System kaputt geht.

Ein System wie DKMS sollte auch für X-Treiber in Betracht gezogen werden. Wenn ich den Eingabetreiber für meinen Touchscreen problemlos patchen / kompilieren / testen / deinstallieren könnte, ohne die gesamte monolithische Apparatur neu erstellen zu müssen (mit der Gefahr, X vollständig unbrauchbar zu machen), würden Sie eher Gelegenheitsarbeit leisten und mich dazu motivieren Schauen Sie sich Testfehler an und testen Sie Patches, die sich auf dieses Hardwarebit beziehen.

Um das zu ergänzen, was jbowtie gesagt hat, möchte ich hinzufügen, dass es für mich als Bugtriager sehr schwierig ist, mit X Bugs umzugehen, einfach weil X ein sehr komplexes Biest ist. Dies spiegelt sich in der Komplexität der Wiki-Seite zur Fehlerbehebung wider . Was definitiv helfen würde, ist eine Art Mentoring-Programm für BugSquad-Mitglieder, um zu lernen, wie man besser mit X-Bugs umgeht. Vielleicht macht ein Bug Hug Tag darum herum? Oder eine praktische Schulung im # Ubuntu-Klassenzimmer?

Es ist schwierig, X.org zu verbessern, wenn viele Benutzer proprietäre Treiber verwenden, die Teile des Grafikstapels ersetzen, und sich dann an das X.org-Team wenden, wenn ein Kernel-Upgrade / X.org-Upgrade die Treiberinstallation unterbricht.

Ein Großteil der Rede über "Ich habe nicht alle Karten zur Verfügung" ist auch gültig.

Grafikprogrammierung ist ziemlich schwierig, wenn Sie kein guter Programmierer sind. Das Debuggen kann sehr schmerzhaft sein, insbesondere wenn Sie nicht sehen können, was gerade passiert.