Kent Overstreet, Entwickler von Bcachefs, hat mitgeteilt, dass die Zukunft des von ihm entwickelten Dateisystems im Kern aufgrund der Maßnahmen des Komitees, das für die Einhaltung des Verhaltenskodex in der Entwicklergemeinschaft verantwortlich ist (CoC-Kommittee), fraglich ist. Linus Torvalds hat sich geweigert, einen weiteren Satz von Korrekturen für Bcachefs in den Kernzweig 6.13 aufzunehmen, und verwies auf Beschwerden des CoC-Kommittees.
Ein paar Tage zuvor wurde eine Änderung in die Dokumente, die die Aktivitäten im Zusammenhang mit dem Verhaltenskodex regeln, eingeführt, die die Möglichkeit einer Sperrung des Entwicklers im Falle eines Verstoßes gegen den Verhaltenskodex und der Weigerung, den Konflikt gemäß dem vom CoC-Ausschuss vorgeschlagenen Szenario zu regeln, zulässt. Die neue Fassung der Regeln sieht im Falle einer Verweigerung, eine öffentliche Entschuldigung abzugeben, die Möglichkeit einer "Sperrung" vor, die vorübergehend das Einreichen von Patches und Pull-Requests blockiert und den Regelverletzer aus den Diskussionen in der Community ausschließt, indem der Zugang zu den Mailing-Listen und den Services von kernel.org blockiert wird.
Mit den Änderungen am Verhaltenskodex einverstanden sind Linus Torvalds, Greg Kroah-Hartman (verantwortlich für die stabilen Kernel-Zweige), Miguel Ojeda (Rust-for-Linux), Dave Hansen (Betreuer des mm-Subsystems von Intel), Jonathan Corbet (LWN), Steven Rostedt (Red Hat), Dan Williams (Intel), Theodore Ts'o (ext4) und Konstantin Ryabtsev (Administrator von Kernel.org). Die Sperrung kann für einen Zeitraum erfolgen, der den Entwicklungszyklus eines neuen Kernel-Zweigs (etwa 2 Monate) nicht überschreitet. Als Bedingungen für die Aufhebung der Sperrung kann das CoC-Komitee vom Übeltäter eine öffentliche Entschuldigung verlangen. Die Entscheidung über die Sperrung wird vom CoC-Komitee bei Zustimmung von 2/3 der Abstimmenden getroffen.
Die Sperrung von Kent Overstreet hängt mit der beleidigenden Äußerung „Lass dir den Kopf untersuchen. Und verzieh dich mit diesem Mist.“ zusammen, die während einer Diskussion mit Michal Hocko, einem der Entwickler des Speichermanagementsystems im Kernel, geäußert wurde. Das Beleidigung wurde von den Mitgliedern des CoC-Ausschusses bemerkt, die um eine öffentliche Entschuldigung baten. Kent wies dies jedoch zurück und hielt es für unangemessen, persönliche Angelegenheiten öffentlich zu machen, und erklärte, dass sie diese Angelegenheit bereits privat mit Michal geklärt hätten. Kent erwähnte auch die unangenehmen Vorschläge, die mit der Notwendigkeit zusammenhingen, das Image der Community zu wahren, aber laut Kent waren diese Vorschläge durch das Bestreben motiviert, die Attraktivität der Unternehmensbeteiligung am Projekt zu erhalten.
Kent beschreibt ausführlich die Geschichte und seine Sicht auf den Konflikt und kritisiert außerdem das Aufzwingen einer raffinierten Kommunikation im Community durch das CoC-Komitee, das seiner Meinung nach die bestehende Ingenieurkultur stört. Konflikte entstehen oft zwischen Menschen, die tief um ihre Arbeit besorgt sind, aber unterschiedliche Meinungen haben. In hitzigen Diskussionen können Entwickler ihre Emotionen nicht stets im Zaum halten und einander anschreien, doch dies ist ein akzeptierter Arbeitsprozess, der letztendlich zu effektiven Lösungen führt und das Projekt voranbringt.
Das Unterdrücken hitziger Debatten führt, so Kent, zu einer Kultur der Missachtung, die das Verlangen hemmt, mit anderen zu interagieren, und die Entwicklung in einen Club der Auserwählten verwandelt, anstatt eine Gemeinschaft zu bewahren, in der jeder teilnehmen und seine Meinung äußern kann. Die Aufgabe von Ingenieuren besteht darin, komplexe Probleme zu lösen, nicht sie zu vermeiden. In diesem Kontext ist die Unterdrückung von Streitigkeiten bei ihrem Entstehen eine schädliche Praxis.
Laut Kent entstehen hitzige Debatten oft dann, wenn Entwickler zum Kern der Sache vordringen wollen und versuchen, technisch interessante Probleme zu lösen. Selbst wenn die Streitenden sich nicht einigen können, gibt es immer eine dritte Person, die die Situation objektiv bewertet und in der Lage ist, das Problem zu lösen, indem sie die Argumente der verschiedenen Streitparteien berücksichtigt.
Kent räumt ein, dass er sich nicht zurückhalten konnte, als er versuchte, technische Argumente vorzubringen, aber auf formale Ausreden und eine Weigerung stieß, sich mit den Details auseinanderzusetzen. Es wird bemerkt, dass der Konflikt mit dem Verantwortlichen für das Speichermanagement (mm) bereits vor einem Jahr entstanden ist, als dieser sich weigerte, die notwendigen Änderungen für die Implementierung eines leichtgewichtigen Mechanismus zur Profilerstellung von Speicherzuweisungen anzunehmen. Für den Betrieb des Mechanismus war es erforderlich, Makro-Bindungen über den Funktionen zur Speicherzuweisung hinzuzufügen, die jedoch abgelehnt wurden, da befürchtet wurde, dass sie die Leistung negativ beeinflussen könnten.
Ein Jahr später trat die Situation erneut auf, als versucht wurde, eine Änderung bezüglich der Fehlerbehandlung in Dateisystemen zu erreichen – der zuständige Betreuer des mm-Subsystems wies die Änderung wieder zurück und berief sich diesmal auf mögliche Sicherheitsauswirkungen. Kent ist der Meinung, dass der Betreuer nicht bereit war, in die Details einzutauchen und die Argumente anderer Entwickler anzuhören, die sich für die Notwendigkeit der Änderung aussprachen, sondern sich nur auf oberflächliche Urteile beschränkte (die Änderung betraf die Annahme einer Ausnahme, die die Behandlung bestimmter Fehler bei der Speicherzuweisung im Modus GFP_NOFAIL erlaubte, der eine externe Fehlerbehandlung in kritischen Sektionen wie der Verarbeitung von Transaktionsprotokollen im Dateisystem verbietet, was zu einem erzwungenen Prozessabbruch führt, selbst in Situationen, in denen der Fehler hätte behandelt werden können).
Kent erwähnte auch, dass die Mitglieder des CoC-Ausschusses ebenfalls nicht vor emotionalen Ausbrüchen gefeit sind. Zum Beispiel erlaubte sich eines seiner Mitglieder während einer Diskussion im Hintergrund der Konferenz ziemlich beleidigende Ausdrücke (bezeichnete andere Entwickler als „asshole“). Solches Verhalten in persönlichen Gesprächen auf der Konferenz ist nicht akzeptabler als in der Mailingliste, und es scheint, dass die Befürworter des Codes versuchen, anderen Regeln aufzuzwingen, die sie selbst nicht einhalten.
Quelle: opennet.ru
