Posté par Faya .
Évalué à 10 (+11/-2).
Dernière modification le 08 juin 2025 à 22:32.
Alors en fouillant un peu il semblerait que le monsieur soumette des patchs qui cassent plein de trucs et qu'il trouve ça normal. Du coup on lui a effectivement demandé d'aller jouer ailleurs :
Posté par Misc (site web personnel) .
Évalué à 10 (+8/-1).
Dernière modification le 08 juin 2025 à 22:42.
Au passage, dans son message sur une liste de FDO, il parle de "talking to a journalist whose name must not be spoken in many other Redhat/IBM tax evasion outlets, like GNOME (they're also banning honorable long time contributors for just mentioning that name)", et sans surprise, il parle de Brian Lunduke cf la vidéo d'il y a 3 jours.
Je ne suis pas convaincu pour l'instant. Sur le plan technique, sur les deux liens fournis:
sur le premier lien, on lui reproche grosso-modo de casser l'ABI du code présent dans la branch main, parce que des gens utilisent directement cette branche, faute de nouvelle version de Xorg depuis 3 ans. Alors si on ne peut pas modifier l'ABI dans cette branche, on le fait où ?
sur le deuxième lien, la première réponse à ce commentaire est, je cite:
This is a totally unfounded accusation. I say this as the user who reported the bug.
J'ai l'impression que ça défrise un peu les dinosaures que quelqu'un cherche activement à faire bouger la bête…
Ensuite s'il arrive à faire avancer son fork, tant mieux, mais je pense que maintenant c'est un peu tard et tout le monde a tourné la page, de gré ou de force, donc il aura du mal à fédérer autour de son projet. Et puis ses opinions complotistes ne donnent pas trop envie de s'attacher au personnage.
Ce qui est vraiment repproché c'est que l'ABI a été cassée sans necessité et que ses patchs se contentent de bouger du code avec d'énormes diff, sans corriger de bug ni apporter de nouvelles fonctionnalités. Son code est également peu ou pas testé.
Pour couronner le tout c'est un adepte des théories du complot.
Il fait une première grosse étape de nettoyage/refactoring pour préparer le terrain pour de nouvelles fonctionnalités. Donc, oui, il y a du boulot, et ça n'apporte rien de concret et ça comporte des risques de régression.
Il fait tourner les tests sur sa branche comportant tous ses changements en cours, pas seulement ceux de la MR. Là il y a clairement un problème de méthodo. Mais il est également réactif lorsqu'on lui signale un problème, et me semble bien moins agressif dans ses réponses que les autres "devs" de xorg.
Au final des quelques échanges que j'ai lu, j'ai l'impression que tout est fait pour que xorg soit abandonné:
pas de nouvelle version, donc la branche "main" devient critique, mais il n'y a aucun autre process pour intégrer des changement un peu ambitieux
tout cleanup est finalement vu comme une perte de temps car ça n'apporte rien [aux devs historiques démotivés]
la moindre erreur et c'est le pilori
Je remarque que le dernier commentaire du deuxième lien se termine (venant d'un dev xorg) par
So it would be reasonable to retract the accusation :-)
Bien sûr, rien de tel n'a été fait. Je trouve cet environnement de dev assez toxique en fait, et il a bien fait de plier bagages.
Note qu’il est possible de faire du ménage sans rien casser. Enfin j’essaie chez moi 😅
j'ai l'impression que tout est fait pour que xorg soit abandonné
Ben… oui, c’est un projet abandonné, de fait. Pourquoi les gens s’étonnent encore ? Il n’y a que Enrico qui y met autant d’entrain, quand tous les devs sont passés à Wayland (je compte XWayland dedans). À la limite des CVE sont corrigées, de temps en temps. Xorg est en mode de maintenance minimale.
Cela ne veut pas dire que tous les utilisateurs·trices sont passées sous Wayland, bien sûr. Mais geler un projet obsolète pour se concentrer sur la techno actuelle, ça me paraît une utilisation très sensée des ressources (limitées). Il y a encore beaucoup de boulot sur Wayland, cependant les progrès ont été plus rapides ces derniers 12 mois.
Je n’entrerais pas dans le débat Wayland vs. X11. Wayland n’est pas la panacée. Aucune techno ne l’est.
Mais les faits sont là : X est une techno reconnue obsolète par ses propres développeurs. Cf. l’excellente vidéo de Daniel Stone à ce sujet : “The Real Story Behind Wayland and X” (assez amusante en plus).
Je trouve cet environnement de dev assez toxique en fait
Ce n’est pas mon impression en lisant les liens. J’y note surtout une énorme lassitude sur le manque de rigueur des contributions et le déni de l’abandon de X par certains contributeurs.
et il a bien fait de plier bagages.
Je pense aussi, les points de vue des intéressé·e·s sont irréconciliables. Mais cela ne va pas être facile. Je lui souhaite bon courage pour remplacer la fondation XOrg et prendre en charge le développement du monstre. Il est très courageux et motivé, alors pourquoi pas ? Ce sera l’occasion de voir à quel point X suscite encore de l’intérêt et, qui sait, contredire la direction qu’ont la grande majorité des environnements de bureau et des distributions Linux.
Posté par Misc (site web personnel) .
Évalué à 8 (+5/-0).
Dernière modification le 09 juin 2025 à 19:13.
Alors, de ce que je sais suite à une discussion avec un admin de FDO, ce qu'on lui reproche, c'est surtout de ne pas écouter quand on lui dit "fait pas ça, ça casse tout". On lui reproche de faire ça pour le code, mais aussi pour l'infra, ce qui impacte d'autres personnes quand la CI est surchargé.
Ensuite, libre à lui de croire qu'il est persécuté par un vaste complot voulant imposer Wayland (vu que visiblement, le plan en 3 étapes, c'est "Wayland -> ???? -> Profit", exactement le même que pour Systemd, avec "Systemd -> ???? -> Profit").
sur le premier lien, on lui reproche grosso-modo de casser l'ABI du code présent dans la branch main, parce que des gens utilisent directement cette branche, faute de nouvelle version de Xorg depuis 3 ans. Alors si on ne peut pas modifier l'ABI dans cette branche, on le fait où ?
Au hasard dans une branche dédiée qui rejoindra main quand ce sera le bon moment de faire une nouvelle version par exemple ?
Façon avec “Together we'll make X great again!”, c'était sûr que c'était mal parti.
Je suis pas fan de Wayland, mais faut arrêter de foutre X11 et X.Org dans le formol. C'est pas adapté aux systèmes modernes et le code est terrible. D'ailleurs, il y a pas un paquet qui compile sans warning.
Je ne suis pas aller plus loin. Dans l'état actuel, c'est pas sérieux.
Le temps nous dira si cela se stabilise.
Je suis convaincu que ce qui aurait le plus de valeur actuellement pour xserver serait d'écrire une suite de tests et de passer au crible le code avec les analyseurs des compilateurs, pour corriger tout problème de mémoire, comportement indéfini, etc.
La ou on voit un mauvais codeur, je vois un créateur d'emploi, quelqu'un qui prends à coeur de faire tourner l'industrie en permettant à tout un écosystème d'entreprises de sécurité de prospérer.
Je ne dirai pas « Le contributeur le plus prolifique », ni contributeur, ni prolifique, parce que visiblement c’est quelqu’un qui soumet la sortie d’une IA, donc ce n’est pas un contributeur, et sans sujet, il n’y a pas de qualificatif à apporter. Les IAs peuvent produire beaucoup de bruit, c’est pas nouveau.
ce commentaire est sous licence cc by 4 et précédentes
Eh, pour "ne maîtrise pas les bases de C.", la PR est clairement faite par une personne qui n'est pas le codeur principal.
Pour le coup, j'ai aussi zieuté les commits, et il y a énormément de commits avec une seule ligne de code, qui pourrait être regroupé en un seul commit.
Ceci dit, en poussant un peu, il y a l'air d'avoir des commits plus conséquent.
Le fork est clairement fait par une personne réactionnaire, par contre pour le code, il a l'air de changer plains de truc, a un commit tree, qui a l'air un peu ma-tu-vue, mais je suis incapable de savoir s'il va réussir à faire quelques chose en quelques coups d'œils sur son code.
Le fait qu'il ait cassé les claviers peut être une preuve d'incompétence, comme juste l'un des symptômes du fait qu'il fasse un gros refactoring.
Je l'ai trouvé pas mal, il explique que le mec qui a fork est le plus gros contributeur de x11 de 2024, donc il a une certaine experiance avec X11.
Par contre, beaucoup de ses contributions ne sont pas forcément appréciées, car il a tendance à casser les choses, dont l'ABI.
À part la politique, il y avait une grosse friction entre la personne qui a fait le fork, et les gents derrière X11, c'est que la personne derrière le fork veut améliore X11, quitte à casser des choses, alors que la majorité des dev et mainteneur de X11, préfère essayer de garder un code stable.
Oui et non, quand tu fais un nouveau projet, tu passes ton temps à le casser avant d'avoir une API stable.
La personne derrière le code, a clairement l'air d'être dans l'idée d'amélioré quitte à casser, ce qui ne va forcément pas plaire aux mainteneurs de xorg.
On parle d'un projet qui est plus vieux que moi (qui pourrait me vendre comme dev sénior)
amélioré quitte à casser
A titre personnel j'ai tendance à penser que casser n'améliore pas. Quand on est dev il faut savoir faire la part des choses entre se faire plaisir (et c'est utile, même si pour ça il faut tout casser) et rendre service aux usagers (et c'est indispensable, et peut être la principale justification que je trouve à se faire plaisir).
Dit autrement, le comportement tel que rapporté ici (je n'ai pas été voir à la source) ressemble à casser des œufs en promettant une omelette très très hypothétique. Le temps jugera. :)
Selon moi la question c'est surtout pourquoi casser dans la branche main. C'est normal de casser des trucs pendant que tu codes, mais :
* fais le sur ta branche
* mets des tests (je crois que ça lui a été dit plusieurs fois)
* dis aux autres de tester ta branche
* et après quand tout le monde est content on merge
D'ailleurs je me demande pourquoi il peut pousser des trucs crades sur main, il y a peut-être un soucis d'organisation au niveau de X11 aussi.
Il n'a ni expérience avec X11 (on ne casse pas une ABI ni API de plusieurs décennies sans nécessité, documentation ni transition planifiée) ni compétence en C.
Le dev qui a accepté ses contributions dans xserver a été bien trop optimiste. Un exemple où l'on a confondu la quantité avec la qualité.
# Slogan
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+7/-0).
Make X great again? Ils vont retirer le support des couleurs?
https://github.com/X11Libre/xserver
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Slogan
Posté par Faya . Évalué à 10 (+11/-2). Dernière modification le 08 juin 2025 à 22:32.
Alors en fouillant un peu il semblerait que le monsieur soumette des patchs qui cassent plein de trucs et qu'il trouve ça normal. Du coup on lui a effectivement demandé d'aller jouer ailleurs :
[EDIT] Il s'était déjà fait rembarrer par Linus en parlant du vaccin qui créerait une nouvelle race humanoïde : https://www.theregister.com/2021/06/11/linus_torvalds_vaccine_smackdown/
[^] # Re: Slogan
Posté par Misc (site web personnel) . Évalué à 10 (+8/-1). Dernière modification le 08 juin 2025 à 22:42.
Au passage, dans son message sur une liste de FDO, il parle de "talking to a journalist whose name must not be spoken in many other Redhat/IBM tax evasion outlets, like GNOME (they're also banning honorable long time contributors for just mentioning that name)", et sans surprise, il parle de Brian Lunduke cf la vidéo d'il y a 3 jours.
[^] # Re: Slogan
Posté par Christophe . Évalué à 7 (+7/-2).
Je ne suis pas convaincu pour l'instant. Sur le plan technique, sur les deux liens fournis:
J'ai l'impression que ça défrise un peu les dinosaures que quelqu'un cherche activement à faire bouger la bête…
Ensuite s'il arrive à faire avancer son fork, tant mieux, mais je pense que maintenant c'est un peu tard et tout le monde a tourné la page, de gré ou de force, donc il aura du mal à fédérer autour de son projet. Et puis ses opinions complotistes ne donnent pas trop envie de s'attacher au personnage.
[^] # Re: Slogan
Posté par DerVogel . Évalué à 7 (+8/-1).
Ce qui est vraiment repproché c'est que l'ABI a été cassée sans necessité et que ses patchs se contentent de bouger du code avec d'énormes diff, sans corriger de bug ni apporter de nouvelles fonctionnalités. Son code est également peu ou pas testé.
Pour couronner le tout c'est un adepte des théories du complot.
[^] # Re: Slogan
Posté par Christophe . Évalué à 3 (+2/-1).
Et il a répondu à cela:
Au final des quelques échanges que j'ai lu, j'ai l'impression que tout est fait pour que xorg soit abandonné:
Je remarque que le dernier commentaire du deuxième lien se termine (venant d'un dev xorg) par
Bien sûr, rien de tel n'a été fait. Je trouve cet environnement de dev assez toxique en fait, et il a bien fait de plier bagages.
[^] # Re: Slogan
Posté par DerVogel . Évalué à 6 (+6/-0).
Note qu’il est possible de faire du ménage sans rien casser. Enfin j’essaie chez moi 😅
Ben… oui, c’est un projet abandonné, de fait. Pourquoi les gens s’étonnent encore ? Il n’y a que Enrico qui y met autant d’entrain, quand tous les devs sont passés à Wayland (je compte XWayland dedans). À la limite des CVE sont corrigées, de temps en temps. Xorg est en mode de maintenance minimale.
Cela ne veut pas dire que tous les utilisateurs·trices sont passées sous Wayland, bien sûr. Mais geler un projet obsolète pour se concentrer sur la techno actuelle, ça me paraît une utilisation très sensée des ressources (limitées). Il y a encore beaucoup de boulot sur Wayland, cependant les progrès ont été plus rapides ces derniers 12 mois.
Je n’entrerais pas dans le débat Wayland vs. X11. Wayland n’est pas la panacée. Aucune techno ne l’est.
Mais les faits sont là : X est une techno reconnue obsolète par ses propres développeurs. Cf. l’excellente vidéo de Daniel Stone à ce sujet : “The Real Story Behind Wayland and X” (assez amusante en plus).
Ce n’est pas mon impression en lisant les liens. J’y note surtout une énorme lassitude sur le manque de rigueur des contributions et le déni de l’abandon de X par certains contributeurs.
Je pense aussi, les points de vue des intéressé·e·s sont irréconciliables. Mais cela ne va pas être facile. Je lui souhaite bon courage pour remplacer la fondation XOrg et prendre en charge le développement du monstre. Il est très courageux et motivé, alors pourquoi pas ? Ce sera l’occasion de voir à quel point X suscite encore de l’intérêt et, qui sait, contredire la direction qu’ont la grande majorité des environnements de bureau et des distributions Linux.
[^] # Re: Slogan
Posté par Misc (site web personnel) . Évalué à 8 (+5/-0). Dernière modification le 09 juin 2025 à 19:13.
Alors, de ce que je sais suite à une discussion avec un admin de FDO, ce qu'on lui reproche, c'est surtout de ne pas écouter quand on lui dit "fait pas ça, ça casse tout". On lui reproche de faire ça pour le code, mais aussi pour l'infra, ce qui impacte d'autres personnes quand la CI est surchargé.
Ensuite, libre à lui de croire qu'il est persécuté par un vaste complot voulant imposer Wayland (vu que visiblement, le plan en 3 étapes, c'est "Wayland -> ???? -> Profit", exactement le même que pour Systemd, avec "Systemd -> ???? -> Profit").
[^] # Re: Slogan
Posté par Renault (site web personnel) . Évalué à 9 (+6/-0).
Au hasard dans une branche dédiée qui rejoindra
mainquand ce sera le bon moment de faire une nouvelle version par exemple ?[^] # Re: Slogan
Posté par Maclag . Évalué à 5 (+2/-0).
Les vrais hommes commitent dans 'main' sans tester.
La crème de l'élite envoie en prod alors que les tests ne sont pas finis!
Pis d'abord pour qui tu travailles pour proposer de bosser proprement? Quels intérêts financiers tu défends? Hein???
(ne répondez pas je suis déjà dehors)
-----> [ ]
[^] # Re: Slogan
Posté par David Demelier (site web personnel) . Évalué à 4 (+2/-0).
Façon avec “Together we'll make X great again!”, c'était sûr que c'était mal parti.
Je suis pas fan de Wayland, mais faut arrêter de foutre X11 et X.Org dans le formol. C'est pas adapté aux systèmes modernes et le code est terrible. D'ailleurs, il y a pas un paquet qui compile sans warning.
AI is a mental disorder
# Zero bug original corrigé mais de nouveaux bugs
Posté par DerVogel . Évalué à 8 (+8/-0).
Ils ont cassé le clavier.
Le contributeur le plus prolifique prétend corriger des failles de sécurité mais ne ne maîtrise pas les bases de C.
Je ne suis pas aller plus loin. Dans l'état actuel, c'est pas sérieux.
Le temps nous dira si cela se stabilise.
Je suis convaincu que ce qui aurait le plus de valeur actuellement pour xserver serait d'écrire une suite de tests et de passer au crible le code avec les analyseurs des compilateurs, pour corriger tout problème de mémoire, comportement indéfini, etc.
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par Misc (site web personnel) . Évalué à 5 (+4/-2).
La ou on voit un mauvais codeur, je vois un créateur d'emploi, quelqu'un qui prends à coeur de faire tourner l'industrie en permettant à tout un écosystème d'entreprises de sécurité de prospérer.
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 9 (+6/-0).
Je ne dirai pas « Le contributeur le plus prolifique », ni contributeur, ni prolifique, parce que visiblement c’est quelqu’un qui soumet la sortie d’une IA, donc ce n’est pas un contributeur, et sans sujet, il n’y a pas de qualificatif à apporter. Les IAs peuvent produire beaucoup de bruit, c’est pas nouveau.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par uso (site web personnel) . Évalué à 5 (+4/-0).
Eh, pour "ne maîtrise pas les bases de C.", la PR est clairement faite par une personne qui n'est pas le codeur principal.
Pour le coup, j'ai aussi zieuté les commits, et il y a énormément de commits avec une seule ligne de code, qui pourrait être regroupé en un seul commit.
Ceci dit, en poussant un peu, il y a l'air d'avoir des commits plus conséquent.
Le fork est clairement fait par une personne réactionnaire, par contre pour le code, il a l'air de changer plains de truc, a un commit tree, qui a l'air un peu ma-tu-vue, mais je suis incapable de savoir s'il va réussir à faire quelques chose en quelques coups d'œils sur son code.
Le fait qu'il ait cassé les claviers peut être une preuve d'incompétence, comme juste l'un des symptômes du fait qu'il fasse un gros refactoring.
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
ou du vibe coding.
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par uso (site web personnel) . Évalué à 1 (+1/-1).
Il y a Brodie Robertson qui a fait une vidéo sur le fork: https://www.youtube.com/watch?v=iCU4W5Ab33c
Je l'ai trouvé pas mal, il explique que le mec qui a fork est le plus gros contributeur de x11 de 2024, donc il a une certaine experiance avec X11.
Par contre, beaucoup de ses contributions ne sont pas forcément appréciées, car il a tendance à casser les choses, dont l'ABI.
À part la politique, il y avait une grosse friction entre la personne qui a fait le fork, et les gents derrière X11, c'est que la personne derrière le fork veut améliore X11, quitte à casser des choses, alors que la majorité des dev et mainteneur de X11, préfère essayer de garder un code stable.
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par Pol' uX (site web personnel) . Évalué à 4 (+2/-0).
Mais n'y a t'il pas contradiction entre améliorer et casser ? Et donc peut être un soucis de méthode, de moyens, voire d'objectif ?
Adhérer à l'April, ça vous tente ?
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par uso (site web personnel) . Évalué à 1 (+1/-1).
Oui et non, quand tu fais un nouveau projet, tu passes ton temps à le casser avant d'avoir une API stable.
La personne derrière le code, a clairement l'air d'être dans l'idée d'amélioré quitte à casser, ce qui ne va forcément pas plaire aux mainteneurs de xorg.
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par Pol' uX (site web personnel) . Évalué à 5 (+3/-0).
On parle d'un projet qui est plus vieux que moi (qui pourrait me vendre comme dev sénior)
A titre personnel j'ai tendance à penser que casser n'améliore pas. Quand on est dev il faut savoir faire la part des choses entre se faire plaisir (et c'est utile, même si pour ça il faut tout casser) et rendre service aux usagers (et c'est indispensable, et peut être la principale justification que je trouve à se faire plaisir).
Dit autrement, le comportement tel que rapporté ici (je n'ai pas été voir à la source) ressemble à casser des œufs en promettant une omelette très très hypothétique. Le temps jugera. :)
Adhérer à l'April, ça vous tente ?
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par Faya . Évalué à 4 (+2/-0).
Selon moi la question c'est surtout pourquoi casser dans la branche main. C'est normal de casser des trucs pendant que tu codes, mais :
* fais le sur ta branche
* mets des tests (je crois que ça lui a été dit plusieurs fois)
* dis aux autres de tester ta branche
* et après quand tout le monde est content on merge
D'ailleurs je me demande pourquoi il peut pousser des trucs crades sur main, il y a peut-être un soucis d'organisation au niveau de X11 aussi.
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par DerVogel . Évalué à 2 (+2/-0).
Il n'a ni expérience avec X11 (on ne casse pas une ABI ni API de plusieurs décennies sans nécessité, documentation ni transition planifiée) ni compétence en C.
Le dev qui a accepté ses contributions dans xserver a été bien trop optimiste. Un exemple où l'on a confondu la quantité avec la qualité.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.