Kent Overstreet, ontwikkelaar van het Bcachefs-bestandssysteem, heeft gemeld dat de toekomst van het bestandssysteem waar hij aan werkt in het ongewisse is door acties van het comit\u00e9 dat verantwoordelijk is voor de naleving van de gedragsregels binnen de ontwikkelaarsgemeenschap (CoC-commissie). Linus Torvalds weigerde een nieuwe set correcties voor Bcachefs op te nemen in de kernelversie 6.13, verwijzend naar beschuldigingen van de CoC-commissie. <\/p>\n
Enkele dagen eerder werd een wijziging in de documenten die de activiteiten met betrekking tot de gedragscode reglementeren, doorgevoerd. Deze wijziging introduceert de mogelijkheid om een ontwikkelaar te blokkeren in het geval van schending van de gedragscode en het niet eens zijn met het voorgestelde scenario van de CoC-commissie om conflicten op te lossen. De nieuwe versie van de regels introduceert, in het geval van weigering om publieke excuses aan te bieden, de mogelijkheid tot het uitgeven van een 'ban', die tijdelijk het aannemen van patches en pull-requests blokkeert, en ook het uitsluiten van de schender van de gedragscode uit discussies binnen de gemeenschap door de toegang tot de mailinglijst en diensten van kernel.org te blokkeren. <\/p>\n
Linus Torvalds, Greg Kroah-Hartman (verantwoordelijk voor de stabiele kernelversies), Miguel Oheda (Rust-for-Linux), Dave Hansen (ondersteunend voor de mm-subsysteem van Intel), Jonathan Corbet (LWN), Steven Rostedt (Red Hat), Dan Williams (Intel), Theodore Ts'o (ext4) en Konstantin Ryabtsev (beheerder van Kernel.org) hebben ingestemd met de wijzigingen in de gedragsregels. De blokkade kan worden opgelegd voor een periode die niet langer is dan de ontwikkelingscyclus van een nieuwe kernelversie (ongeveer 2 maanden). Om de blokkade op te heffen, kan de CoC-commissie eisen dat de overtreder publiekelijk excuses aanbiedt. De beslissing over de blokkade wordt genomen door de CoC-commissie met instemming van 2\/3 van de stemgerechtigde leden. <\/p>\n
De blokkade van Kent Overstreet is verbonden aan de kwetsende opmerking 'Get your head examined. And get the fuck out of here with this shit.', die tijdens een discussie met Michal Hocko, een van de ontwikkelaars van het geheugenbeheersysteem in de kernel, werd gemaakt. Het beledigende commentaar werd opgemerkt door leden van de CoC-commissie, die om publieke excuses vroegen, maar Kent weigerde, omdat hij het onacceptabel vond om persoonlijke zaken publiekelijk te bespreken en verklaarde dat zij met Michal deze kwestie al priv\u00e9 hadden opgelost. Kent noemde ook de vervelende aanmaningen met de noodzaak om het imago van de gemeenschap te ondersteunen, maar volgens Kent waren deze voortgekomen uit de wens om de aantrekkelijkheid van deelname aan het project voor bedrijven te behouden. <\/p>\n
Kent beschreef in detail het verhaal en zijn visie op het conflict, en hij bekritiseerde de druk die het CoC-committe uitoefent om verfijnde communicatie in de gemeenschap op te leggen, wat volgens hem de gevestigde engineeringcultuur schaadt. Meningsverschillen ontstaan meestal tussen mensen die diep om hun werk geven, maar verschillende standpunten hebben. Tijdens verhitte discussies kunnen ontwikkelaars hun emoties niet beheersen en tegen elkaar schreeuwen, maar dit is een aanvaarde werkwijze onder de deelnemers die uiteindelijk leidt tot het vinden van effectieve oplossingen en vooruitgang van het project. <\/p>\n
Volgens Kent leidt het onderdrukken van verhitte discussies tot een cultuur van minachting, die het verlangen om met anderen samen te werken afneemt en de ontwikkeling in een exclusieve club verandert, in plaats van een gemeenschap te behouden waar iedereen kan deelnemen en zijn mening kan geven. Het werk van ingenieurs draait om het oplossen van complexe problemen, en niet om ze te vermijden; in deze context is het onderdrukken van discussies bij hun oorsprong een schadelijke praktijk. <\/p>\n
Volgens Kent ontstaan verhitte discussies meestal wanneer ontwikkelaars diepgaand willen graven en proberen technisch interessante problemen op te lossen. Zelfs als de debatten geen consensus bereiken, is er vaak een derde partij die de situatie van buitenaf kan bekijken en deze kan oplossen door rekening te houden met de argumenten van de verschillende kanten in de discussie. <\/p>\n
Kent erkent dat hij niet kon inhouden, terwijl hij technische argumenten probeerde naar voren te brengen, maar kreeg in ruil daarvoor formele excuses en de wens om niet in detail in te gaan. Er wordt opgemerkt dat het conflict met de begeleidende geheugenbeheersubsyteem (mm) al een jaar geleden begon, toen de begeleider weigerde een wijziging te accepteren die nodig was voor de implementatie van een lichtgewicht mechanisme voor het profileren van geheugenallocaties. Voor de werking van het mechanisme was het nodig om macro-wrapper boven de geheugenallocatiefuncties toe te voegen en de begeleider wees deze af, uit vrees dat ze de prestaties negatief zouden be\u00efnvloeden. <\/p>\n
Een jaar later deed zich dezelfde situatie voor bij een poging om een wijziging te bewerkstelligen met betrekking tot foutafhandeling in bestandssystemen \u2014 de verantwoordelijke voor de mm-subsystemen wees de wijziging weer af, dit keer met een verwijzing naar mogelijke veiligheidsrisico's. Volgens Kent was de verantwoordelijke niet bereid om dieper in de details te duiken en de argumenten van andere ontwikkelaars, die het eens waren over de noodzaak van de wijziging, aan te horen, maar bleef hij beperkt tot oppervlakkige opmerkingen (de wijziging hield verband met de aanname van een uitzondering, die de verwerking van bepaalde fouten bij geheugentoewijzing in de modus GFP_NOFAIL toegestaan, verbiedt externe foutafhandeling in kritieke secties, zoals de afhandeling van transacties in de journaling van het bestandssysteem, wat leidt tot de geforceerde be\u00ebindiging van processen, zelfs in situaties waarin de fout kon worden afgehandeld). <\/p>\n