Comment impliquer davantage de personnes dans l'amélioration de X.org pour Ubuntu? [fermé]


18

Dans Ubuntu, X est l'une des pièces les plus critiques de la pile. En tant que tel, nous recevons une tonne de questions et de rapports de bogues à ce sujet, probablement environ 100 fois plus que nous avons de main-d'œuvre à gérer.

Canonical recrute des ingénieurs supplémentaires pour travailler sur X, ce qui aidera, mais il y a encore beaucoup de choses qui sortent du cadre de ce que Canonical peut faire, donc je pense qu'il est vraiment important d'avoir une communauté forte impliquée dans l'amélioration de X dans Ubuntu, en particulier autour de l'obtention de toutes ces quantités massives de rapports de bugs, triés et (espérons-le) résolus

Cependant, il est difficile de trouver des gens pour travailler sur X ou de convaincre les gens qu'il vaut la peine d'y investir leur temps. Comment proposeriez-vous d'encourager les gens à s'impliquer, qui ne penseraient pas autrement à travailler sur X?


3
Je suggérerais d'en faire une entrée Wiki communautaire.
Marco Ceppi

Où les gens qui veulent commencer peuvent-ils avoir une entrée facile pour aider?
txwikinger

Au moins, vous ne demandez pas comment impliquer plus de personnes avec XFree86;)
Stefan Lasiewski

1
Nous avons un tas de documents sur wiki.ubuntu.com/X pour aider les gens qui veulent aider sur X. Couvre les problèmes de base de X, décrit certains des processus de gestion des bogues X, etc. C'est un wiki alors n'hésitez pas à y ajouter aussi.
Bryce

Réponses:


7

Eh bien, comme beaucoup de choses, il est facile et accessible aux gens de le découvrir. Donc, d'après ce dont je me souviens avec le triage des bogues à l'origine, il n'y avait pas beaucoup d'aide venant de la communauté. Puis, lorsque certaines pages wiki expliquant les processus réguliers de tri des bogues et certains jours de bogue ont impliqué beaucoup plus de membres de la communauté. De plus, si vous pouvez commencer une activité régulière pour la communauté et offrir de l'aide à ceux qui l'essaient, vous obtiendrez un certain intérêt.

Si vous avez besoin d'aide pour l'activité, vous pouvez m'envoyer un e-mail et de l'aide pour l'organiser.

Donc, ma réponse est de créer une page wiki avec des questions et des commandes pour obtenir de bonnes informations de triage des bogues pour impliquer les gens dans cela.

Pour le développement, c'est un gros problème. Les trucs Xorg et Kernel nécessitent des compétences de programmation de bas niveau pour la plupart des fonctionnalités de correction de bogues et d'implémentation. Vous devez donc cibler un groupe spécifique de programmeurs et les intéresser. Je n'ai pas de suggestions ici, sauf demander un peu et voir qui traîne dans # ubuntu-x et leur demander s'ils peuvent aider.


N'est-il pas prévu d'implémenter Wayland à l'avenir? Ne serait-il donc pas préférable de faire travailler les gens là-dessus?
Ingo

12

La raison pour laquelle X ne reçoit pas beaucoup de travail est qu'il nécessite une énorme quantité de connaissances sur le fonctionnement des GPU, de la mémoire, etc., ainsi qu'une familiarité avec la base de code X.org et dans une certaine mesure la programmation du noyau. Ce n'est pas une chose triviale d'entrer dans une perspective communautaire et ceux qui sont intéressés à travailler sur des pilotes X ou X le font probablement déjà. Il n'y a actuellement aucune motivation pour qu'un développeur travaille sur Xorg en dehors de son intérêt personnel.

Ce que la communauté possède, que les développeurs de X.org n'ont pas nécessairement, c'est l'accès à une grande variété de matériel. Avoir des gens qui sont prêts à passer du temps à écrire de «bons» rapports de bogues et à tester des pilotes et des parties de la pile Xorg avant une version va probablement aider les ingénieurs plus que tout.

Il existe actuellement un repo Xorg edgers que j'utilise pour tester les pilotes sur mon système stable. Il est assez facile de restaurer un seul package une fois les tests terminés. Cependant, la seule autre façon dont nous pouvons tester est de construire X vous-même ou d'installer le référentiel edgers qui se construit à partir de l'amont. Cela fait un remplacement en gros de X pour autant que je sache. Cela signifie que c'est une approche tout ou rien pour tester X.

Avoir un moyen d'avoir 2 versions de X (et de choisir assez facilement) celle que vous souhaitez utiliser permettrait aux testeurs non seulement de tester X, mais de revenir ensuite à un Xorg fonctionnel afin de pouvoir soumettre le rapport de bogue.


3
En fait, ce dont nous avons besoin n'est pas vraiment plus de rapports de bogues (nous avons des TONNES), mais plutôt des personnes pour parcourir tous les rapports que les gens ont envoyés à Ubuntu, trier les bons des mauvais et aider les utilisateurs dans la mesure du possible. Nous avons en fait assez peu de mal à faire tester beaucoup de gens; beaucoup d'entre eux ne savent pas comment rédiger de «bons» rapports de bogues, mais avec un certain travail de tri, ils peuvent être améliorés (et transmis en amont pour d'autres travaux). C'est
Bryce

1
Peut-être que nous devrions faire une journée de résolution de bugs pour x-server?
txwikinger

12

Parlant en tant que développeur intéressé par X avec désinvolture, voici mes problèmes:

  1. Je n'ai accès qu'à une poignée de cartes graphiques et je soupçonne que la plupart des gens n'ont accès qu'à une seule. Je ne peux donc pas faire grand-chose pour la grande majorité des bugs, qui seront toujours sur "une autre carte".

  2. Contrairement à la plupart des packages, je ne peux pas créer trivialement un environnement de test pour une nouvelle version de pilote; les machines virtuelles ont leurs propres pilotes X.

  3. Je ne peux pas facilement mettre à jour le dernier pilote, le tester, puis revenir en arrière. Cela décourage l'expérimentation (parce que si quelque chose ne va pas, je pourrais aussi bien être maçonné); cela entrave également les tests de régression.

  4. La dernière fois que j'ai regardé, appliquer un correctif avec succès, compiler et exécuter X était difficile à faire, j'ai parcouru le gestionnaire de paquets, exigé que les modules du noyau soient également corrigés et était à peu près une étape irréversible.

  5. De nos jours, les pilotes X divisent leur code entre les pilotes du noyau, Mesa, udev (pour les paramètres et les valeurs par défaut) et les pilotes utilisateur. Ce qui signifie que les patchs sont également divisés ...

Donc, je suppose que la réponse est de faire en sorte que les changements appliqués et annulés soient gérés par le gestionnaire de paquets et faciles à récupérer lorsqu'ils cassent votre système.

En outre, un système comme DKMS doit être examiné pour les pilotes X; si je pouvais facilement patcher / compiler / tester / désinstaller, disons, le pilote d'entrée de mon écran tactile sans avoir à reconstruire l'ensemble de l'engin monolithique (avec sa menace de rendre X complètement inutilisable), vous obtiendriez une contribution plus décontractée et me motiveriez à regardez les bogues de tri et les correctifs de test relatifs à ce morceau de matériel.


Je pense que vous avez raison, ce sont toutes des questions qu'un volontaire potentiel pourrait considérer comme des raisons pour lesquelles il ne pourrait pas travailler sur X. Cependant, il y a beaucoup de choses qui ne nécessitent pas "d'ouvrir le capot" qu'une personne pourrait faire pour aider beaucoup - le tri des bogues, la réponse aux questions des utilisateurs, la recherche de bons correctifs à inclure dans Ubuntu. Des trucs qui ne font pas vraiment face à ces problèmes particuliers.
Bryce

1
J'ai plus peur de X que du noyau. Je peux facilement démarrer un noyau plus ancien.
maco

1
Je n'ai jamais peur: o Vous pouvez facilement configurer un environnement à double démarrage où vous pouvez tester les correctifs du noyau ainsi que les serveurs Xorg instables. Il n'a même pas besoin d'être aussi gros car vous n'avez pas besoin de la plupart des outils GUI pour faire simple, et pendant la compilation, vous pouvez être dans votre environnement normal et vous connecter au système instable.
LassePoulsen

4

Pour compléter ce que jbowtie a dit, j'ajouterais qu'en tant que trieur de bogues, je trouve que les bogues X sont très difficiles à gérer, tout simplement parce que X est une bête très complexe. Cela se reflète dans la complexité de la page wiki de dépannage . Ce qui aiderait certainement, c'est une sorte de programme de mentorat pour les membres de BugSquad afin d'apprendre à mieux gérer les bogues X. Peut-être faire une journée de câlins autour de lui? Ou une session de formation pratique dans # ubuntu-class?


Un programme de mentorat est en fait une très bonne idée. Nous avons discuté de quelques idées à ce sujet, mais le défi jusqu'à présent a été de trouver des gens prêts à l'essayer.
Bryce

J'ai fait deux jours de bugs pour X jusqu'à présent. Presque personne ne s'est présenté pour faire du tri, et nous n'avons pas gagné de nouveaux membres.
Bryce

1

Il est difficile d'améliorer X.org lorsque de nombreux utilisateurs utilisent des pilotes propriétaires qui remplacent des parties de la pile graphique, puis se tournent vers l'équipe X.org lorsqu'une mise à niveau du noyau / X.org interrompt l'installation de leur pilote.

Une grande partie de la discussion sur "Je n'ai pas toutes les cartes disponibles" est également valable.

La programmation graphique est assez difficile si vous n'êtes pas un bon programmeur. Le débogage peut être une vraie douleur, surtout si vous ne pouvez pas voir ce qui se passe.


Je suis d'accord avec vous sur la douleur des pilotes propriétaires du point de vue du développeur. Mais au niveau de la distribution ubuntu, nous nous intéressons principalement au packaging des pilotes, qui est open source et pourrait bénéficier de l'implication de la communauté pour l'améliorer.
Bryce

Avoir une variété de cartes graphiques semble être important, mais d'après mon expérience, c'est utile mais pas critique. Ce que je trouve le plus utile, c'est d'avoir 2 ordinateurs - un pour votre utilisation quotidienne régulière qui est maintenu stable, et un second que vous pouvez casser X, déboguer, ssh, etc.
Bryce
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.