Kent Overstreet, dezvoltatorul sistemului de fișiere Bcachefs, a declarat că viitorul acestuia în nucleul Linux este incert din cauza acțiunilor comitetului responsabil cu respectarea codului de conduită în comunitatea dezvoltatorilor (CoC Committee). Linus Torvalds a refuzat să accepte un nou set de corecții pentru Bcachefs în ramura nucleului 6.13, invocând plângerile venite din partea comitetului CoC.
Cu câteva zile înainte, au fost aduse modificări documentelor care reglementează activitatea legată de codul de conduită, introducând posibilitatea de a bloca un dezvoltator în cazul încălcării codului de conduită și a negării de a soluționa conflictul conform scenariului propus de comitetul CoC. Noua versiune a regulilor permite, în cazul refuzului de a oferi scuze publice, impunerea unui „ban”, care va bloca primirea de patch-uri și pull-request-uri pentru o anumită perioadă, precum și excluderea încălcătorului codului din discuțiile comunității prin blocarea accesului la lista de poștă și serviciile kernel.org.
Modificările aduse codului de conduită au fost acceptate de Linus Torvalds, Greg Kroah-Hartman (responsabil pentru ramurile stabile ale nucleului), Miguel Oheda (Rust-for-Linux), Dave Hansen (responsabil cu subsistemul mm de la Intel), Jonathan Corbet (LWN), Steven Rostedt (Red Hat), Dan Williams (Intel), Theodore Ts'o (ext4) și Konstantin Ryabitsev (administrator Kernel.org). Blocarea poate fi aplicată pentru o perioadă care nu depășește ciclul de dezvoltare al unei noi ramuri a nucleului (aproximativ 2 luni). Ca condiție de ridicare a blocării, comitetul CoC poate solicita încălcătorului să ofere scuze publice. Decizia de blocare este luată de comitetul CoC cu acordul a 2/3 dintre participanții la vot.
Blocarea lui Kent Overstreet este legată de expresia jignitoare „Get your head examined. And get the fuck out of here with this shit.”, exprimată în timpul unei discuții cu Michal Hocko, unul dintre dezvoltatorii sistemului de distribuție a memoriei în nucleu. Insulta a fost observată de către membrii comitetului CoC, care au solicitat scuze publice, iar Kent a răspuns refuzând, considerând inacceptabil să se dezvăluie probleme personale în public și afirmând că ei și Michal au rezolvat deja această problemă pe calea privată. Kent a menționat, de asemenea, că discuțiile au lăsat un sentiment neplăcut, făcând referire la necesitatea de a susține imaginea comunității, dar, în opinia lui Kent, aceste cerințe au fost dictate de dorința de a menține atractivitatea participării corporațiilor în proiect.
Kent a descris în detaliu istoria și viziunea sa asupra conflictului, criticând, de asemenea, impunerea de către comitetul CoC a unei comunicări rafinate în comunitate, care, în opinia sa, încalcă cultura ingineriei stabilită. Disputele apar, de obicei, între persoane care le pasă profund de munca lor, dar care au perspective diferite. În timpul disputelor aprinse, dezvoltatorii pot să nu își controleze emoțiile și să se certe, dar acesta este un proces de lucru acceptat de participanți, care, în cele din urmă, duce la găsirea unei soluții eficiente și la avansarea proiectului.
Potrivit lui Kent, reprimarea disputelor fierbinți duce la apariția unei culturi a disprețului, care descurajează interacțiunea cu alții și transformă dezvoltarea într-un club exclusivist, în loc să mențină o comunitate în care toți pot participa și își pot exprima opiniile. Munca inginerilor constă în a rezolva probleme complexe, nu în a le evita, iar în acest context, suprimarea disputelor la început este o practică dăunătoare.
Conform observațiilor lui Kent, disputele încinse apar, de obicei, când dezvoltatorii doresc să ajungă la esență și încearcă să rezolve probleme tehnic interesante. Chiar dacă disputanții nu pot ajunge la un acord, se găsește o a treia persoană, care, evaluând situația din exterior, poate rezolva problema, având în vedere argumentele prezentate de diferitele părți ale disputei.
Kent recunoaște că nu s-a putut abține, încercând să aducă argumente tehnice, dar a primit în schimb scuze formale și lipsa dorinței de a se adânci în detalii. Se remarcă că conflictul cu subsystemul de gestionare a memoriei (mm) a început cu un an în urmă, când responsabilul a refuzat să accepte o modificare necesară pentru implementarea unui mecanism ușor de profilare a operațiunilor de alocare a memoriei. Funcționarea mecanismului necesita adăugarea unor macro-wrappers deasupra funcțiilor de alocare a memoriei, iar responsabilul le-a respins, temându-se că acestea ar putea afecta negativ performanța.
După un an, situația s-a repetat în încercarea de a obține o modificare legată de gestionarea erorilor în sistemele de fișiere — responsabilul subsistemului mm a respins din nou modificarea, de data aceasta invocând un potențial impact asupra securității. În opinia lui Kent, responsabilul nu a dorit să aprofundeze detaliile și să asculte argumentele altor dezvoltatori care erau de acord cu necesitatea schimbării, limitându-se doar la judecăți superficiale (modificarea era legată de adoptarea unei excepții care permitea gestionarea unor erori de alocare a memoriei în condiții de funcționare GFP_NOFAIL, care interzice gestionarea externă a erorilor în secțiunile critice, cum ar fi gestionarea jurnalizării în FS, ceea ce duce la terminarea forțată a procesului, chiar și în situații unde eroarea ar fi putut fi gestionată).
Kent a mai menționat că membrii comitetului CoC nu sunt nici ei lipsiți de izbucniri emoționale, de exemplu, unul dintre participanții săi, în timpul discuțiilor informale de la conferință, și-a permis să folosească expresii complet jignitoare (a numit alți dezvoltatori „asshole”). Un astfel de comportament în comunicarea personală la conferință nu este mai acceptabil decât pe o listă de discuții, rezultând că susținătorii codului încearcă să impună altora reguli pe care ei înșiși le încalcă.
Sursa: opennet.ro
