Kent Overstreet, twórca systemu plików Bcachefs, poinformował, że przyszłość rozwijanego przez niego systemu plików w rdzeniu stoi pod znakiem zapytania z powodu działań komitetu odpowiedzialnego za egzekwowanie kodeksu postępowania w społeczności programistów (Komitet CoC). Linus Torvalds odmówił przyjęcia nowego zestawu poprawek do Bcachefs do gałęzi rdzenia 6.13, odwołując się do skarg ze strony komitetu CoC.
Kilka dni wcześniej w dokumentach regulujących działalność związaną z kodeksem postępowania wprowadzono zmianę, która umożliwia zablokowanie programisty w przypadku naruszenia kodeksu postępowania i braku zgody na rozwiązanie konfliktu zgodnie z proponowanym scenariuszem komitetu CoC. Nowa wersja zasad w przypadku odmowy złożenia publicznych przeprosin wprowadza możliwość nałożenia "bana", który przez pewien czas blokuje akceptację poprawek i pull-requestów, a także wyklucza naruszającego kodeks z dyskusji w społeczności poprzez zablokowanie dostępu do listy mailingowej oraz usług kernel.org.
Do zmian w kodeksie postępowania zgodzili się Linus Torvalds, Greg Kroah-Hartman (odpowiedzialny za stabilne gałęzie rdzenia), Miguel Ojeda (Rust-for-Linux), Dave Hansen (opiekun subsystemu mm z Intela), Jonathan Corbet (LWN), Steven Rostedt (Red Hat), Dan Williams (Intel), Teodor Tso (ext4) oraz Konstantin Ryabtsev (administrator Kernel.org). Blokada może trwać nie dłużej niż cykl rozwoju nowej gałęzi rdzenia (około 2 miesiące). Jako warunek zniesienia blokady komitet CoC może zażądać od naruszającego złożenia publicznych przeprosin. Decyzję o blokadzie podejmuje komitet CoC przy zgodzie 2/3 uczestników głosowania.
Blokada Kenta Overstreeta była związana z obraźliwym stwierdzeniem „Zbadaj swoją głowę. A wypierdalać stąd z tym gównem.”, które padło w trakcie dyskusji z Michałem Hocko, jednym z deweloperów systemu zarządzania pamięcią w jądrze. Obrażenie zauważyli członkowie komisji CoC i poprosili o publiczne przeprosiny, na co Kent odpowiedział odmową, uznając za niewłaściwe publiczne poruszanie spraw osobistych i stwierdzając, że oni z Michałem już rozwiązali ten problem prywatnie. Kent wspomniał również o nieprzyjemnych sugestiach dotyczących konieczności dbania o wizerunek społeczności, jednak jego zdaniem były one dyktowane chęcią utrzymania atrakcyjności uczestnictwa korporacji w projekcie.
Kent szczegółowo opisał historię i swoją wizję konfliktu, a także skrytykował narzucanie przez komisję CoC wysublimowanej komunikacji w społeczności, które jego zdaniem narusza ustaloną kulturę inżynieryjną. Spory zazwyczaj pojawiają się między osobami, które głęboko przejmują się swoją pracą, ale mają różne punkty widzenia. W trakcie gorących sporów deweloperzy mogą nie dojść do siebie z emocjami i krzyczeć na siebie, ale to akceptowany przez uczestników proces roboczy, który ostatecznie prowadzi do znalezienia skutecznego rozwiązania i postępu projektu.
Zdaniem Kenta, stłumienie gorących sporów prowadzi do powstania kultury lekceważenia, która zniechęca do interakcji z innymi i przekształca rozwój w klub dla wybranych, zamiast utrzymać społeczność, w której każdy może wziąć udział i wyrazić swoją opinię. Praca inżynierów polega na rozwiązywaniu złożonych problemów, a nie na ich unikaniu; w tym kontekście tłumienie sporów w zarodku jest szkodliwą praktyką.
Według obserwacji Kenta, gorące spory zazwyczaj występują, gdy deweloperzy chcą dotrzeć do sedna sprawy i próbują rozwiązać technicznie interesujące problemy. Nawet jeśli sporzy nie mogą dojść do porozumienia, znajduje się trzecia osoba, która ocenia sytuację z boku i jest w stanie rozwiązać problem, uwzględniając argumenty przedstawione przez różne strony sporu.
Kent przyznaje, że nie wytrzymał, próbując przedstawić argumenty techniczne, ale otrzymał jedynie formalne wymówki i brak chęci do zagłębienia się w szczegóły. Zauważa się, że konflikt z osobą odpowiedzialną za subsystém zarządzania pamięcią (mm) pojawił się już rok temu, gdy ta osoba odmówiła przyjęcia zmiany potrzebnej do wdrożenia lekkiego mechanizmu profilowania operacji alokacji pamięci. Do działania mechanizmu konieczne było dodanie makro-ow wraps nad funkcjami alokacji pamięci, a osoba ta je odrzuciła, obawiając się, że mogą one negatywnie wpłynąć na wydajność.
Po roku sytuacja się powtórzyła podczas próby wprowadzenia zmiany związanej z obsługą błędów w systemach plików — osoba odpowiedzialna za subsystém mm ponownie odrzuciła zmianę, tym razem powołując się na możliwy wpływ na bezpieczeństwo. Zdaniem Kenta, osoba ta nie chciała zagłębić się w szczegóły i wysłuchać argumentów innych programistów, którzy zgodzili się na konieczność zmiany, ograniczając się do płytkich ocen (zmiana była związana z wprowadzeniem wyjątku, który umożliwiałby obsługę niektórych błędów związanych z alokacją pamięci w trybie GFP_NOFAIL, który zabrania zewnętrznej obsługi błędów w krytycznych sekcjach, takich jak przetwarzanie transakcji logowania w FS, co prowadzi do przymusowego zakończenia procesu, nawet w sytuacji, gdy błąd mógłby być obsłużony).
Kent wspomniał również, że członkowie komitetu CoC nie są wolni od emocjonalnych wybuchów, na przykład jeden z nich podczas dyskusji na konferencji pozwalał sobie na całkiem obraźliwe wypowiedzi (nazwając innych programistów „asshole”). Takie zachowanie w osobistej komunikacji na konferencji jest równie nieakceptowalne, jak na liście mailingowej, a okazuje się, że zwolennicy kodeksu starają się narzucić innym zasady, które sami łamią.
Źródło: opennet.ru
