Kent Overstreet, sviluppatore del filesystem Bcachefs, ha comunicato che il futuro del filesystem in fase di sviluppo \u00e8 incerto a causa delle azioni del comitato che si occupa della codifica del comportamento nella comunit\u00e0 degli sviluppatori (CoC Committee). Linus Torvalds ha rifiutato di accettare un ulteriore insieme di correzioni per Bcachefs nella branch del kernel 6.13, citando il fatto che ci sono stati reclami da parte del comitato CoC. <\/p>\n
Pochi giorni prima, \u00e8 stata apportata una modifica ai documenti che regolano l'attivit\u00e0 legata al codice di condotta, introducendo la possibilit\u00e0 di bloccare uno sviluppatore in caso di violazione del codice stesso e del rifiuto di risolvere il conflitto secondo lo scenario proposto dal comitato CoC. La nuova versione delle regole, in caso di rifiuto a presentare scuse pubbliche, introduce la possibilit\u00e0 di un \u2018bannamento\u2019, bloccando temporaneamente l'accettazione di patch e pull request, e escludendo il trasgressore dalle discussioni nella comunit\u00e0 mediante il blocco dell'accesso alla mailing list e ai servizi di kernel.org. <\/p>\n
Le modifiche al codice di comportamento sono state approvate da Linus Torvalds, Greg Kroah-Hartman (responsabile delle branch stabili del kernel), Miguel Oleda (Rust-for-Linux), Dave Hansen (mantenitore del sottomodulo mm di Intel), Jonathan Corbet (LWN), Steven Rostedt (Red Hat), Dan Williams (Intel), Theodore Ts'o (ext4) e Konstantin Ryabtsev (amministratore di Kernel.org). Il blocco pu\u00f2 durare non oltre il ciclo di sviluppo della nuova branch del kernel (circa 2 mesi). Come condizione per la revoca del blocco, il comitato CoC pu\u00f2 richiedere al trasgressore di presentare pubbliche scuse. La decisione sul blocco \u00e8 presa dal comitato CoC con il consenso di 2\/3 dei membri che votano. <\/p>\n
Il blocco di Kent Overstreet \u00e8 legato all'espressione offensiva \u2018Get your head examined. And get the fuck out of here with this shit.\u2019, pronunciata durante una discussione con Michal Hocko, uno degli sviluppatori del sistema di gestione della memoria del kernel. L'offesa \u00e8 stata notata dai membri del comitato CoC, che hanno chiesto scuse pubbliche, ma Kent ha risposto rifiutando, considerando inaccettabile portare questioni personali in pubblico e dichiarando che lui e Michal avevano gi\u00e0 risolto la questione privatamente. Kent ha anche accennato agli spiacevoli appelli riguardanti la necessit\u00e0 di sostenere l'immagine della comunit\u00e0, ma, secondo lui, questi erano dettati dal desiderio di mantenere l'attrattiva della partecipazione al progetto da parte delle corporazioni. <\/p>\n
Kent ha descritto nel dettaglio la storia e la sua visione del conflitto, criticando l'imposizione da parte del comitato CoC di una comunicazione raffinata nella comunit\u00e0, che a suo avviso viola la cultura ingegneristica consolidata. I conflitti generalmente sorgono tra persone che si preoccupano profondamente del loro lavoro ma hanno punti di vista diversi. Durante le accese discussioni, gli sviluppatori possono non controllare le proprie emozioni e urlarsi contro, ma questo \u00e8 un processo lavorativo accettato dai partecipanti che alla fine porta a trovare soluzioni efficaci e a far progredire il progetto. <\/p>\n
Secondo Kent, l'inibizione delle accese discussioni porta alla creazione di una cultura di disinteresse, che scoraggia la collaborazione e trasforma lo sviluppo in un club esclusivo, anzich\u00e9 mantenere una comunit\u00e0 dove ognuno possa partecipare e esprimere la propria opinione. Il lavoro degli ingegneri consiste nel risolvere problemi complessi, non nell'evitarli; in questo contesto, sopprimere le discussioni all'inizio \u00e8 una pratica dannosa. <\/p>\n
Secondo Kent, le accese discussioni sorgono generalmente quando gli sviluppatori vogliono andare a fondo e risolvere problemi tecnicamente interessanti. Anche se i litiganti non riescono a trovare un accordo, c'\u00e8 sempre una terza parte che, valutando la situazione da una prospettiva esterna, \u00e8 in grado di risolvere il problema, tenendo conto degli argomenti presentati da entrambe le parti del conflitto. <\/p>\n
Kent riconosce di aver perso la calma cercando di presentare argomentazioni tecniche, ma ricevendo in cambio soltanto scuse formali e mancanza di volont\u00e0 di approfondire i dettagli. Si nota che il conflitto con il mantenitore del sottomodulo di gestione della memoria (mm) \u00e8 nato circa un anno fa, quando quest'ultimo ha rifiutato di accettare una modifica necessaria per implementare un meccanismo di profilazione leggero delle operazioni di allocazione della memoria. Per il funzionamento del meccanismo era necessaria l'aggiunta di macro-involucri attorno alle funzioni di allocazione della memoria, e il mantenitore le ha rifiutate, temendo che potessero influire negativamente sulle prestazioni. <\/p>\n
Un anno dopo, la situazione si \u00e8 ripetuta nel tentativo di ottenere una modifica relativa alla gestione degli errori nei file system - l'accompagnatore della sottosistema mm ha nuovamente respinto la modifica, questa volta citando possibili impatti sulla sicurezza. Secondo Kent, l'accompagnatore non ha voluto approfondire i dettagli e ascoltare gli argomenti degli altri sviluppatori che si erano dichiarati favorevoli alla modifica, limitandosi a giudizi superficiali (la modifica riguardava l'adozione di un'eccezione che consentiva la gestione di alcuni errori di allocazione della memoria in modalit\u00e0 GFP_NOFAIL, che vieta la gestione esterna degli errori in sezioni critiche, come la gestione delle transazioni di journaling nei file system, portando alla terminazione forzata del processo anche quando l'errore poteva essere gestito). <\/p>\n