Kent Overstreet, sviluppatore di Bcachefs, ha comunicato che il futuro del file system che sta sviluppando nel kernel \u00e8 in discussione a causa delle azioni del comitato responsabile del rispetto del codice di condotta nella comunit\u00e0 degli sviluppatori (CoC Committee). Linus Torvalds ha rifiutato di accettare un altro insieme di correzioni per Bcachefs nella versione del kernel 6.13, citando l'esistenza di lamentele da parte del comitato CoC. <\/p>\n
Pochi giorni prima, \u00e8 stata apportata una modifica ai documenti che regolano l'attivit\u00e0 relativa al codice di condotta, introducendo la possibilit\u00e0 di bloccare uno sviluppatore in caso di violazione del codice di condotta e di disaccordo nell'affrontare il conflitto secondo lo scenario proposto dal comitato CoC. La nuova edizione delle norme, in caso di rifiuto di presentare scuse pubbliche, introduce la possibilit\u00e0 di un \"bando\", che blocca temporaneamente l'accettazione di patch e pull request, escludendo inoltre il trasgressore dal dibattito nella comunit\u00e0 bloccando l'accesso alle mailing list e ai servizi di kernel.org. <\/p>\n
Con le modifiche al codice di condotta hanno concordato Linus Torvalds, Greg Kroah-Hartman (responsabile delle ramificazioni stabili del kernel), Miguel Ojeda (Rust-for-Linux), Dave Hansen (mantenitore del sottosistema mm di Intel), Jonathan Corbet (LWN), Steven Rostedt (Red Hat), Dan Williams (Intel), Theodor Ts'o (ext4) e Konstantin Ryabitsev (amministratore di Kernel.org). Il blocco pu\u00f2 essere attuato per un periodo che non supera il ciclo di sviluppo di un nuovo ramo del kernel (circa 2 mesi). Come condizione per la rimozione del blocco, il comitato CoC potrebbe richiedere al trasgressore di presentare delle scuse pubbliche. La decisione di blocco viene presa dal comitato CoC con il consenso di 2\/3 dei partecipanti al voto. <\/p>\n
Il blocco di Kent Overstreet \u00e8 legato all'espressione offensiva \"Get your head examined. And get the fuck out of here with this shit.\", pronunciata durante una discussione con Michal Hocko, uno degli sviluppatori del sistema di gestione della memoria nel kernel. L'offesa \u00e8 stata notata dai membri del comitato CoC e gli \u00e8 stato chiesto di presentare scuse pubbliche, ma Kent ha rifiutato, ritenendo inaccettabile portare questioni personali in pubblico e dichiarando che lui e Michal avevano gi\u00e0 risolto la questione privatamente. Kent ha anche menzionato le spiacevoli pressioni riguardo alla necessit\u00e0 di mantenere l'immagine della comunit\u00e0, che secondo lui erano dettate dal desiderio di mantenere l'attrattiva della partecipazione al progetto da parte delle corporation. <\/p>\n
Kent ha descritto in dettaglio la storia e la sua visione del conflitto, oltre a criticare l'imposizione da parte del comitato CoC di una comunicazione raffinata nella comunit\u00e0, la quale, a suo avviso, viola la cultura ingegneristica consolidata. Le controversie sorgono di solito tra persone che si prendono a cuore il proprio lavoro, ma che hanno punti di vista diversi. Durante le accese controversie, gli sviluppatori possono non trattenere le proprie emozioni e urlarsi contro, ma questo \u00e8 un processo lavorativo accettato dai partecipanti, che alla fine porta a trovare una soluzione efficace e a far progredire il progetto. <\/p>\n
Secondo Kent, reprimere le accese dispute porta alla creazione di una cultura di disprezzo, che scoraggia la volont\u00e0 di interagire con gli altri e trasforma lo sviluppo in un club esclusivo, invece di mantenere una comunit\u00e0 in cui tutti possono partecipare e esprimere la propria opinione. Il lavoro degli ingegneri consiste nel risolvere problemi complessi, non nell'evitarli; in questo contesto, sopprimere le dispute fin dall'inizio \u00e8 una pratica dannosa. <\/p>\n
Secondo Kent, le accese dispute di solito nascono quando gli sviluppatori vogliono arrivare al nocciolo della questione e cercano di risolvere problemi tecnicamente affascinanti. Anche se i litiganti non riescono a mettersi d'accordo tra di loro, c'\u00e8 di solito una terza persona che, valutando la situazione dall'esterno, \u00e8 in grado di risolvere il problema, tenendo conto degli argomenti presentati dalle diverse parti della controversia. <\/p>\n
Kent ammette di non aver trattenuto la calma nel tentativo di presentare argomenti tecnici, ricevendo in cambio risposte formali e una mancanza di volont\u00e0 di approfondire i dettagli. Si segnala che il conflitto con il sistema di gestione della memoria (mm) \u00e8 nato gi\u00e0 un anno fa, quando il responsabile ha rifiutato di accettare una modifica necessaria per implementare un meccanismo leggero di profilazione delle operazioni di allocazione della memoria. Per il funzionamento del meccanismo era necessario aggiungere macro-involucri sopra le funzioni di allocazione della memoria e il responsabile li ha rifiutati, temendo che potessero avere un impatto negativo sulle prestazioni. <\/p>\n
Un anno dopo, la situazione si \u00e8 ripresentata nel tentativo di ottenere un cambiamento relativo alla gestione degli errori nei file system \u2014 l'accompagnatore del sottomodulo mm ha nuovamente rifiutato la modifica, questa volta citando un possibile impatto sulla sicurezza. Secondo Kent, l'accompagnatore non ha voluto approfondire i dettagli e ascoltare gli argomenti di altri sviluppatori che si erano detti favorevoli alla modifica, limitandosi a valutazioni superficiali (la modifica riguardava l'introduzione di un'eccezione che consentiva la gestione di alcuni errori di allocazione di memoria in modalit\u00e0 GFP_NOFAIL, che proibisce la gestione esterna degli errori in sezioni critiche, come il trattamento delle transazioni di journaling nei FS, che porta a un'immediata terminazione del processo, anche quando l'errore potrebbe essere gestito). <\/p>\n