Suivant Hector Martin, Karol Herbst a également annoncé qu'il se retirait de ses fonctions de mainteneur et cessait de participer à la révision des patches. Il a été le porteur du pilote Nouveau et du mécanisme de traçage MMIO (MMIOTRACE) au sein de Red Hat. Après son départ, deux autres mainteneurs resteront dans le noyau pour soutenir le pilote Nouveau, qui, selon Karol, font un excellent travail.
Comme raison de son départ, il mentionne le manque d'inclusivité dans l'environnement des développeurs du noyau. Karol est convaincu que, dans la communauté du logiciel open source, le travail doit être fait dans le respect, sur un pied d'égalité et sans abus de pouvoir. Selon Karol, la goutte d'eau a été le message de Theodore Ts'o, dans lequel il comparait les mainteneurs à une « fine ligne bleue » (associée aux forces de l'ordre et symbolisant la frontière entre l'ordre et l'anarchie), qui veille à ce que le code intégré au noyau soit maintenu et de qualité.
Selon Karol, celui qui prononce de telles paroles ne devrait pas occuper un poste de mainteneur, peu importe son importance pour le projet, et devrait être exclu avant de réaliser ce que ces mots signifient pour de nombreuses personnes marginalisées et les horreurs qu'ils suscitent dans leur esprit. Karol part car il ne peut rester dans une communauté qui tolère de telles paroles.
Theodore Ts'o a fait la comparaison avec la fine ligne bleue lors de la discussion sur la résistance des anciens développeurs à l'intégration de Rust dans le noyau. Il a écrit que le pouvoir des mainteneurs est limité et qu'ils ne peuvent pas influencer la poursuite du développement des modifications déjà acceptées, car ils n'ont pas le pouvoir d'ordonner aux gens de travailler sur des améliorations et l'infrastructure de test. Le seul outil pour garantir la qualité est la capacité des mainteneurs à empêcher l'inclusion dans le noyau de changements bruts et douteux. Une fois le code accepté, les mainteneurs perdent les leviers d'influence sur les développeurs et deviennent personnellement responsables de ce code.
Lorsque des changements significatifs sont adoptés, les mainteneurs doivent s'assurer que la modification est entièrement fonctionnelle et que ses développeurs sont capables de maintenir le code après son intégration dans le noyau, sans laisser ce code sans supervision. Théodore cite en exemple des équipes qui ne s'intéressent qu'à la promotion de leur création, qui disparaissent ensuite dès que le code est accepté, laissant les mainteneurs gérer toutes les erreurs commises.
Certains accusent de doubles standards, car le code de certains développeurs est accepté presque immédiatement, tandis que celui d'autres passe par des processus longs. Dans ce domaine, la confiance établie et la réputation méritée sont essentielles. Si un développeur a déjà démontré sa capacité à répondre des modifications apportées, les validations se font rapidement. Pour les nouveaux, l'acceptation des modifications peut prendre du temps, car l'accompagnateur doit comprendre si le participant pourra assumer son code. Ainsi, les membres, en particulier ceux essayant de promouvoir des changements radicaux, doivent consacrer beaucoup de temps à devenir partie intégrante de la communauté. Par exemple, l'intégration des modifications pour la compilation du noyau avec Clang a nécessité 10 ans.
Source : opennet.ru
