Kent Overstreet, développeur du système de fichiers Bcachefs, a indiqué que l'avenir du système de fichiers en cours de développement dans le noyau est incertain en raison des actions du comité responsable du respect du code de conduite dans la communauté des développeurs (Comité CoC). Linus Torvalds a refusé d'accepter un nouvel ensemble de corrections pour Bcachefs dans la branche 6.13 du noyau, en se référant à des plaintes de la part du comité CoC.
Quelques jours avant cela, un changement a été apporté aux documents régissant les activités liées au code de conduite, introduisant la possibilité de bloquer un développeur en cas de violation du code de conduite et de désaccord pour résoudre le conflit selon le scénario proposé par le comité CoC. La nouvelle édition des règles, en cas de refus de présenter des excuses publiques, donne la possibilité d'imposer un « ban », bloquant pendant un certain temps l'acceptation de patches et de pull requests, ainsi qu'excluant l'infraction du code des discussions dans la communauté en bloquant l'accès à la mailing list et aux services kernel.org.
Linus Torvalds, Greg Kroah-Hartman (responsable des branches stables du noyau), Miguel Oveda (Rust-for-Linux), Dave Hansen (responsable de la sous-système mm chez Intel), Jonathan Corbet (LWN), Steven Rostedt (Red Hat), Dan Williams (Intel), Theodore Ts'o (ext4) et Konstantin Ryabtsev (administrateur de Kernel.org) ont accepté les modifications du code de conduite. Le blocage peut être effectué pour une durée ne dépassant pas le cycle de développement d'une nouvelle branche du noyau (environ 2 mois). En tant que condition de levée du blocage, le comité CoC peut exiger des excuses publiques de la part de l'infracteur. La décision de blocage est prise par le comité CoC avec l'accord de 2/3 des participants au vote.
Le blocage de Kent Overstreet est lié à l'expression offensive « Faites-vous examiner la tête. Et foutez le camp d'ici avec ces conneries. », prononcée lors d'une discussion avec Michal Hocko, l'un des développeurs du système de répartition de la mémoire dans le noyau. L'insulte a été remarquée par des membres du comité CoC qui ont demandé des excuses publiques, ce à quoi Kent a répondu par un refus, jugeant inacceptable de soulever des affaires personnelles en public et affirmant qu'il avait déjà réglé ce problème avec Michal en privé. Kent a également mentionné des pressions désagréables en évoquant la nécessité de soutenir l'image de la communauté, mais à son avis, celles-ci étaient dictées par le désir de maintenir l'attrait du projet pour les entreprises.
Kent a détaillé l'histoire et sa vision du conflit, critiquant également l'imposition par le comité CoC d'une communication raffinée au sein de la communauté, qui, selon lui, perturbe la culture d'ingénierie établie. Les disputes surviennent généralement entre des personnes qui se soucient profondément de leur travail, mais qui ont des opinions différentes. Lors de débats animés, les développeurs peuvent perdre leur calme et crier les uns sur les autres, mais cela fait partie d'un processus de travail accepté qui finit par conduire à des solutions efficaces et à l'avancement du projet.
Selon Kent, réprimer les débats animés entraîne l'émergence d'une culture de mépris qui décourage l'interaction avec les autres et transforme le développement en un club exclusif, au lieu de préserver une communauté où chacun peut participer et exprimer son opinion. Le travail des ingénieurs consiste à résoudre des problèmes complexes, et non à les éviter ; dans ce contexte, supprimer les disputes dès leur origine est une pratique nuisible.
D'après les observations de Kent, des débats animés surviennent généralement lorsque les développeurs veulent aller au fond des choses et tentent de résoudre des problèmes techniques intéressants. Même si les débatteurs ne parviennent pas à se mettre d'accord entre eux, une tierce personne, qui évalue la situation de l'extérieur, peut résoudre le problème en tenant compte des arguments présentés par les différentes parties de la dispute.
Kent reconnait qu'il a été emporté en essayant d'apporter des arguments techniques, mais a reçu en retour des excuses formelles et un manque de volonté d'entrer dans les détails. Il est noté que le conflit avec le responsable du sous-système de gestion de la mémoire (mm) a commencé il y a un an, lorsque ce responsable a refusé d'accepter un changement nécessaire pour mettre en œuvre un mécanisme léger de profilage des opérations d'allocation de mémoire. Pour faire fonctionner ce mécanisme, il fallait ajouter des macros autour des fonctions d'allocation de mémoire, et le responsable les a rejetées, craignant qu'elles puissent avoir un impact négatif sur les performances.
Un an plus tard, la situation s'est répétée lors d'une tentative d'obtenir un changement concernant la gestion des erreurs dans les systèmes de fichiers — le responsable du sous-système mm a de nouveau rejeté le changement, cette fois en invoquant un éventuel impact sur la sécurité. Selon Kent, le responsable n'a pas souhaité approfondir les détails et écouter les arguments d'autres développeurs, qui étaient d'accord sur la nécessité du changement, mais s'est limité à des jugements superficiels (le changement était lié à l'acceptation d'une exception permettant de gérer certaines erreurs d'allocation de mémoire en mode GFP_NOFAIL, interdisant le traitement externe des erreurs dans des sections critiques, comme le traitement des transactions de journalisation dans FS, ce qui entraîne l'arrêt du processus, même lorsqu'une erreur pouvait être gérée).
Kent a également mentionné que les membres du comité CoC ne sont pas à l'abri de débordements émotionnels, par exemple, l'un de ses membres, lors d'une discussion dans les coulisses de la conférence, s'est permis d'utiliser des propos assez offensants (il a traité d'autres développeurs de « asshole »). Un tel comportement, en personne lors d'une conférence, n'est pas plus acceptable que sur une liste de diffusion, et il semble que les partisans du code essaient d'imposer aux autres des règles qu'ils violent eux-mêmes.
Source : opennet.ru
