Kent Overstreet, der Entwickler von Bcachefs, hat mitgeteilt, dass die Zukunft des von ihm entwickelten Dateisystems im Kernel aufgrund der Aktivit\u00e4ten des Gremiums, das f\u00fcr die Einhaltung des Verhaltenskodex in der Entwicklergemeinschaft verantwortlich ist (CoC Committee), in Frage steht. Linus Torvalds hat sich geweigert, einen weiteren Satz von \u00c4nderungen an Bcachefs in den Kernel 6.13-Branch aufzunehmen und verwies auf Beschwerden seitens des CoC-Komitees. <\/p>\n
Einige Tage zuvor wurde eine \u00c4nderung in die Dokumente eingef\u00fchrt, die die Aktivit\u00e4ten im Zusammenhang mit dem Verhaltenskodex regeln, wodurch die M\u00f6glichkeit geschaffen wurde, einen Entwickler zu sperren, falls er gegen den Verhaltenskodex verst\u00f6\u00dft und sich weigert, den Konflikt gem\u00e4\u00df dem vom CoC-Komitee vorgeschlagenen Szenario zu kl\u00e4ren. Die neue Regelung sieht im Falle einer Weigerung, \u00f6ffentliche Entschuldigung zu leisten, die M\u00f6glichkeit vor, einen \u201aBann\u2018 zu verh\u00e4ngen, der f\u00fcr eine gewisse Zeit die Annahme von Patches und Pull-Requests blockiert und den Regelverletzer von Diskussionen in der Community ausschlie\u00dft, indem der Zugang zu den Mailinglisten und den Diensten von kernel.org blockiert wird. <\/p>\n
Linus Torvalds, Greg Kroah-Hartman (verantwortlich f\u00fcr die stabilen Kernelzweige), Miguel Ocheda (Rust-for-Linux), Dave Hansen (Betreuer des mm-Subsystems bei Intel), Jonathan Corbet (LWN), Steven Rostedt (Red Hat), Dan Williams (Intel), Theodor Ts'o (ext4) und Konstantin Ryabets (Administrator von Kernel.org) haben den \u00c4nderungen im Verhaltenskodex zugestimmt. Die Blockierung kann f\u00fcr einen Zeitraum erfolgen, der den Entwicklungszyklus eines neuen Kernelzweigs (ungef\u00e4hr 2 Monate) nicht \u00fcberschreitet. Der CoC-Ausschuss kann, um die Blockierung aufzuheben, vom Regelverst\u00f6\u00dfer eine \u00f6ffentliche Entschuldigung verlangen. Die Entscheidung \u00fcber die Blockierung wird vom CoC-Ausschuss mit einer Zustimmung von 2\/3 der abstimmenden Teilnehmer getroffen. <\/p>\n
Die Sperrung von Kent Overstreet h\u00e4ngt mit seiner beleidigenden \u00c4u\u00dferung \u201aUntersuche deinen Kopf. Und verschwinde mit diesem Mist.\u2018 zusammen, die er w\u00e4hrend einer Diskussion mit Michal Hocko, einem der Entwickler des Speichermanagementsystems im Kernel, ge\u00e4u\u00dfert hat. Das Beleidigung wurde von den Mitgliedern des CoC-Komitees bemerkt, die um eine \u00f6ffentliche Entschuldigung baten, was Kent jedoch ablehnte und es als unangemessen betrachtete, pers\u00f6nliche Angelegenheiten \u00f6ffentlich zu machen. Er erkl\u00e4rte, dass er und Michal diese Angelegenheit bereits privat gekl\u00e4rt h\u00e4tten. Kent erw\u00e4hnte auch die unangenehmen Vorschl\u00e4ge, die die Notwendigkeit betonten, das Image der Community zu wahren, aber nach Kents Meinung wurden sie aus dem Wunsch heraus ge\u00e4u\u00dfert, die Attraktivit\u00e4t der Teilnahme am Projekt f\u00fcr Unternehmen zu bewahren. <\/p>\n
Kent beschrieb ausf\u00fchrlich die Geschichte und seine Sicht auf den Konflikt und kritisierte die Auferlegung einer raffinierten Kommunikation seitens des CoC-Teams in der Gemeinschaft, die seiner Meinung nach die bestehende Ingenieurskultur verletzt. Streitigkeiten entstehen normalerweise zwischen Menschen, die sich leidenschaftlich f\u00fcr ihre Arbeit einsetzen, aber unterschiedliche Sichtweisen haben. Inmitten hitziger Debatten k\u00f6nnen Entwickler ihre Emotionen nicht zur\u00fcckhalten und sich anschreien, aber das ist ein akzeptierter Teil des Arbeitsprozesses, der letztendlich zu effektiven L\u00f6sungen und dem Vorankommen des Projekts f\u00fchrt. <\/p>\n
Die Unterdr\u00fcckung hitziger Debatten f\u00fchrt laut Kent zu einer Kultur der Geringsch\u00e4tzung, die den Wunsch, mit anderen zu interagieren, unterdr\u00fcckt und die Entwicklung zu einem exklusiven Club macht, anstatt eine Gemeinschaft zu bewahren, in der jeder teilnehmen und seine Meinung \u00e4u\u00dfern kann. Die Arbeit von Ingenieuren besteht darin, komplexe Probleme zu l\u00f6sen und nicht zu vermeiden; in diesem Kontext ist die Unterdr\u00fcckung von Streitigkeiten in ihren Anf\u00e4ngen eine sch\u00e4dliche Praxis. <\/p>\n
Laut Kent entstehen hitzige Debatten normalerweise, wenn Entwickler zur Sache kommen wollen und versuchen, technisch interessante Probleme zu l\u00f6sen. Selbst wenn die Streitenden sich nicht einigen k\u00f6nnen, gibt es oft eine dritte Partei, die die Situation von au\u00dfen betrachtet und in der Lage ist, das Problem zu l\u00f6sen, indem sie die Argumente der verschiedenen Streitparteien ber\u00fccksichtigt. <\/p>\n
Kent r\u00e4umt ein, dass er sich nicht zur\u00fcckgehalten hat, als er versuchte, technische Argumente vorzubringen, aber stattdessen formale Ausreden erhielt und kein Interesse daran zeigte, in die Details einzutauchen. Es wird angemerkt, dass der Konflikt mit dem f\u00fcr das Speichermanagement (mm) zust\u00e4ndigen Begleiter vor einem Jahr begann, als dieser sich weigerte, eine \u00c4nderung zu akzeptieren, die f\u00fcr die Implementierung eines leichten Profilierungsmechanismus f\u00fcr Speicherzuweisungen erforderlich war. Um den Mechanismus zu betreiben, mussten Makro-Wrapper um die Speicherzuweisungsfunktionen hinzugef\u00fcgt werden, und der Begleiter wies sie zur\u00fcck, aus Angst, dass sie sich negativ auf die Leistung auswirken k\u00f6nnten. <\/p>\n
Ein Jahr sp\u00e4ter wiederholte sich die Situation bei dem Versuch, eine \u00c4nderung im Zusammenhang mit der Fehlerbehandlung in Dateisystemen durchzusetzen \u2013 der daf\u00fcr zust\u00e4ndige Maintainer der mm-Subsysteme wies die \u00c4nderung erneut zur\u00fcck, diesmal unter Verweis auf m\u00f6gliche Sicherheitsimplikationen. Kent der Meinung, dass der Maintainer sich weigerte, tiefer in die Details einzutauchen und die Argumente anderer Entwickler, die der Notwendigkeit der \u00c4nderung zustimmten, anzuh\u00f6ren, und sich nur auf oberfl\u00e4chliche Urteile beschr\u00e4nkte (die \u00c4nderung betraf die Annahme einer Ausnahme, die die Verarbeitung bestimmter Speicherfehler im gesetzten Modus GFP_NOFAIL erlaubte, der die externe Fehlerbehandlung in kritischen Abschnitten wie dem Transaktionsprotokoll in FS untersagte, was dazu f\u00fchrt, dass der Prozess zwangsweise beendet wird, selbst in Situationen, in denen der Fehler behandelt werden k\u00f6nnte). <\/p>\n