Kent Overstreet, Entwickler von Bcachefs, hat mitgeteilt, dass die Zukunft des von ihm entwickelten Dateisystems im Kern aufgrund der Ma\u00dfnahmen des Komitees, das f\u00fcr die Einhaltung des Verhaltenskodex in der Entwicklergemeinschaft verantwortlich ist (CoC-Kommittee), fraglich ist. Linus Torvalds hat sich geweigert, einen weiteren Satz von Korrekturen f\u00fcr Bcachefs in den Kernzweig 6.13 aufzunehmen, und verwies auf Beschwerden des CoC-Kommittees. <\/p>\n
Vor einigen Tagen wurde eine \u00c4nderung in die Dokumente, die die Aktivit\u00e4ten im Zusammenhang mit dem Verhaltenskodex regeln, eingef\u00fcgt, die die M\u00f6glichkeit der Sperrung eines Entwicklers im Falle eines Versto\u00dfes gegen den Verhaltenskodex und der Weigerung, den Konflikt nach dem vom CoC-Ausschuss vorgeschlagenen Szenario zu regeln, einf\u00fchrt. Die neue Regelung sieht vor, dass im Falle einer Weigerung, eine \u00f6ffentliche Entschuldigung abzugeben, die M\u00f6glichkeit besteht, einen \u201eBan\u201c auszusprechen, der vor\u00fcbergehend die Annahme von Patches und Pull-Requests blockiert und den Regelverletzer aus Diskussionen in der Community ausschlie\u00dft, indem der Zugang zu Mailing-Listen und den Services von kernel.org gesperrt wird. <\/p>\n
Mit den \u00c4nderungen am Verhaltenskodex einverstanden sind Linus Torvalds, Greg Kroah-Hartman (verantwortlich f\u00fcr 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\u00fcr einen Zeitraum erfolgen, der den Entwicklungszyklus eines neuen Kernel-Zweigs (etwa 2 Monate) nicht \u00fcberschreitet. Als Bedingungen f\u00fcr die Aufhebung der Sperrung kann das CoC-Komitee vom \u00dcbelt\u00e4ter eine \u00f6ffentliche Entschuldigung verlangen. Die Entscheidung \u00fcber die Sperrung wird vom CoC-Komitee bei Zustimmung von 2\/3 der Abstimmenden getroffen. <\/p>\n
Die Sperrung von Kent Overstreet steht im Zusammenhang mit der beleidigenden \u00c4u\u00dferung \u201eGet your head examined. And get the fuck out of here with this shit.\u201c, die w\u00e4hrend einer Diskussion mit Michal Hocko, einem der Entwickler des Speichersystems im Kernel, gemacht wurde. Beleidigungen wurden von Mitgliedern des CoC-Ausschusses bemerkt, die eine \u00f6ffentliche Entschuldigung forderten, auf die Kent ablehnte und es als unangemessen erachtete, pers\u00f6nliche Angelegenheiten \u00f6ffentlich anzusprechen, und erkl\u00e4rte, dass sie das Problem bereits pers\u00f6nlich mit Michal gekl\u00e4rt h\u00e4tten. Kent erw\u00e4hnte auch unangenehme Andeutungen zur Unterst\u00fctzung des Ansehens der Community, die seiner Meinung nach von dem Wunsch diktiert seien, die Attraktivit\u00e4t der Beteiligung am Projekt f\u00fcr Unternehmen zu erhalten. <\/p>\n
Kent beschreibt ausf\u00fchrlich die Geschichte und seine Sicht auf den Konflikt und kritisiert au\u00dferdem das Aufzwingen einer raffinierten Kommunikation im Community durch das CoC-Komitee, das seiner Meinung nach die bestehende Ingenieurkultur st\u00f6rt. Konflikte entstehen oft zwischen Menschen, die tief um ihre Arbeit besorgt sind, aber unterschiedliche Meinungen haben. In hitzigen Diskussionen k\u00f6nnen Entwickler ihre Emotionen nicht stets im Zaum halten und einander anschreien, doch dies ist ein akzeptierter Arbeitsprozess, der letztendlich zu effektiven L\u00f6sungen f\u00fchrt und das Projekt voranbringt. <\/p>\n
Das Unterdr\u00fccken hitziger Debatten f\u00fchrt, so Kent, zu einer Kultur der Missachtung, die das Verlangen hemmt, mit anderen zu interagieren, und die Entwicklung in einen Club der Auserw\u00e4hlten verwandelt, anstatt eine Gemeinschaft zu bewahren, in der jeder teilnehmen und seine Meinung \u00e4u\u00dfern kann. Die Aufgabe von Ingenieuren besteht darin, komplexe Probleme zu l\u00f6sen, nicht sie zu vermeiden. In diesem Kontext ist die Unterdr\u00fcckung von Streitigkeiten bei ihrem Entstehen eine sch\u00e4dliche Praxis. <\/p>\n
Laut Kent entstehen hitzige Debatten oft dann, wenn Entwickler zum Kern der Sache vordringen wollen und versuchen, technisch interessante Probleme zu l\u00f6sen. Selbst wenn die Streitenden sich nicht einigen k\u00f6nnen, gibt es immer eine dritte Person, die die Situation objektiv bewertet 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\u00fcckhalten konnte, als er versuchte, technische Argumente vorzubringen, aber auf formale Ausreden und eine Weigerung stie\u00df, sich mit den Details auseinanderzusetzen. Es wird bemerkt, dass der Konflikt mit dem Verantwortlichen f\u00fcr das Speichermanagement (mm) bereits vor einem Jahr entstanden ist, als dieser sich weigerte, die notwendigen \u00c4nderungen f\u00fcr die Implementierung eines leichtgewichtigen Mechanismus zur Profilerstellung von Speicherzuweisungen anzunehmen. F\u00fcr den Betrieb des Mechanismus war es erforderlich, Makro-Bindungen \u00fcber den Funktionen zur Speicherzuweisung hinzuzuf\u00fcgen, die jedoch abgelehnt wurden, da bef\u00fcrchtet wurde, dass sie die Leistung negativ beeinflussen k\u00f6nnten. <\/p>\n
Ein Jahr sp\u00e4ter wiederholte sich die Situation, als versucht wurde, eine \u00c4nderung im Zusammenhang mit der Fehlerbehandlung in Dateisystemen zu erreichen - der f\u00fcr das mm-Subsystem zust\u00e4ndige Entwickler wies erneut die \u00c4nderung zur\u00fcck und berief sich diesmal auf m\u00f6gliche Auswirkungen auf die Sicherheit. Nach Kents Meinung wollte der zust\u00e4ndige Entwickler nicht in die Einzelheiten einsteigen und die Argumente anderer Entwickler h\u00f6ren, die sich f\u00fcr die Notwendigkeit der \u00c4nderung ausgesprochen hatten, sondern beschr\u00e4nkte sich auf oberfl\u00e4chliche Urteile (die \u00c4nderung wollte eine Ausnahme einf\u00fchren, die die Behandlung bestimmter Fehler bei der Speicherzuweisung im Modus GFP_NOFAIL zulie\u00df, der die externe Fehlerbehandlung in kritischen Abschnitten, wie der Behandlung von Transaktionen im Journal-Dateisystem, verbot, was zur abrupten Beendigung des Prozesses f\u00fchrte, selbst in Situationen, in denen der Fehler h\u00e4tte behandelt werden k\u00f6nnen). <\/p>\n