L'autore di BcacheFS è stato temporaneamente sospeso dallo sviluppo del kernel Linux a causa di una violazione del codice di condotta

Kent Overstreet, sviluppatore del filesystem Bcachefs, ha comunicato che il futuro del filesystem in fase di sviluppo è incerto a causa delle azioni del comitato che si occupa della codifica del comportamento nella comunità 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.

Pochi giorni prima, sono state apportate modifiche ai documenti che regolano le attività relative al codice di condotta, introducendo la possibilità di bloccare uno sviluppatore in caso di violazione del codice di condotta e di disaccordo nel risolvere il conflitto secondo lo scenario proposto dal comitato CoC. La nuova versione delle regole prevede che, in caso di rifiuto di scuse pubbliche, si possa adottare un "ban" temporaneo che blocca l'accettazione di patch e richieste di pull, nonché esclude il trasgressore dai dibattiti nella comunità, bloccando l'accesso alla mailing list e ai servizi di kernel.org.

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ò 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ò richiedere al trasgressore di presentare pubbliche scuse. La decisione sul blocco è presa dal comitato CoC con il consenso di 2/3 dei membri che votano.

Il blocco di Kent Overstreet è legato all'espressione offensiva "Get your head examined. And get the fuck out of here with this shit.", espressa durante una discussione con Michal Hocko, uno degli sviluppatori del sistema di gestione della memoria del kernel. L'insulto è stato notato dai membri del comitato CoC, che hanno chiesto scuse pubbliche, a cui Kent ha risposto rifiutando, considerandolo inappropriato sollevare questioni personali in pubblico e affermando di aver già risolto la questione privatamente con Michal. Kent ha anche menzionato le pressioni sconcertanti relative al mantenimento dell'immagine della comunità, che a suo avviso erano dettate dal desiderio di mantenere l'attrattiva della partecipazione al progetto da parte delle corporazioni.

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à, 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 è un processo lavorativo accettato dai partecipanti che alla fine porta a trovare soluzioni efficaci e a far progredire il progetto.

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é mantenere una comunità 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 è una pratica dannosa.

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'è sempre una terza parte che, valutando la situazione da una prospettiva esterna, è in grado di risolvere il problema, tenendo conto degli argomenti presentati da entrambe le parti del conflitto.

Kent riconosce di aver perso la calma cercando di presentare argomentazioni tecniche, ma ricevendo in cambio soltanto scuse formali e mancanza di volontà di approfondire i dettagli. Si nota che il conflitto con il mantenitore del sottomodulo di gestione della memoria (mm) è 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.

Dopo un anno, la situazione si è ripetuta nel tentativo di ottenere una modifica riguardante la gestione degli errori nei file system: il manutentore del sottosistema mm ha nuovamente rifiutato la modifica, questa volta facendo riferimento a un possibile impatto sulla sicurezza. Secondo Kent, il manutentore non ha voluto approfondire i dettagli e ascoltare le argomentazioni degli altri sviluppatori, concordi sulla necessità della modifica, limitandosi a valutazioni superficiali (la modifica era collegata all'adozione di un'eccezione che consentiva la gestione di alcuni errori di allocazione della memoria in modalità GFP_NOFAIL, che vieta la gestione esterna degli errori nelle sezioni critiche, come la gestione delle transazioni di registrazione nel FS, causando la terminazione forzata del processo, anche quando l'errore poteva essere trattato).

Kent ha anche menzionato che i membri del comitato CoC non sono immuni da attacchi emotivi; ad esempio, uno dei suoi membri, durante una discussione nei corridoi di una conferenza, si è permesso espressioni piuttosto offensive (ha definito altri sviluppatori «asshole»). Comportamenti di questo tipo in comunicazione diretta durante una conferenza non sono più accettabili che su una mailing list, e risulta quindi che i sostenitori del codice cercano di imporre regole agli altri che loro stessi violano.

Fonte: opennet.ru

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster