Eine weitere Diskussion zwischen Linus Torvalds und Kent Overstreet, dem Entwickler von Bcachefs, endete damit, dass Linus seine Bereitschaft erkl\u00e4rte, den Bcachefs-Code aus dem Linux-Kernel 6.17 zu entfernen. Dabei nahm Linus jedoch in Kernel 6.16 \u00c4nderungen an Bcachefs auf, die Gegenstand neuer Unzufriedenheit \u00fcber Kents Handlungen wurden. Linus schrieb: <\/p>\n
\nIch glaube, dass unsere Wege beim Merge-Fenster 6.17 auseinandergehen werden. <\/p>\n
Sie haben sehr deutlich klargemacht, dass ich keine Fehlerbehebungen in Frage stellen kann und einfach alles akzeptieren muss. <\/p>\n
Ehrlich gesagt f\u00fchle ich mich nicht besonders wohl dabei, in all das verwickelt zu sein, und das Einzige, wor\u00fcber wir beide anscheinend wirklich in der Diskussion \u00fcbereingestimmt haben, ist, dass «wir fertig sind». <\/p><\/blockquote>\n
Der vorausgehende Schriftverkehr mit Kent fand privat statt, und die Einzelheiten sind noch unklar. Dennoch schrieb Kent in der Diskussion zu diesem Thema, dass seine Worte in der privaten Korrespondenz m\u00f6glicherweise falsch interpretiert wurden und er nicht glaubt, dass BcacheFS aus dem Kernel entfernt werden sollte. Gleichzeitig ist er bereit, die Bereitstellung von Bcachefs im Hauptkern von Linux einzustellen, was das Projekt nicht zum Scheitern bringen wird, obwohl es ein riesiges Problem darstellen wird. Im Falle der Entfernung von Bcachefs wird die Entwicklung fortgesetzt und das Dateisystem wird in Form eines DKMS-Moduls verbreitet. Kent bemerkte auch, dass die Entfernung von BcacheFS aus dem Kernel die beste Option f\u00fcr seine und Linus' Ruhe sein w\u00fcrde, aber offensichtlich keine optimale L\u00f6sung f\u00fcr die Benutzer und die Entwicklergemeinschaft darstellt. <\/p>\n
Die Konflikte zwischen Kent und Linus resultieren aus st\u00e4ndigen Verst\u00f6\u00dfen gegen die Regeln f\u00fcr das Einpflegen von \u00c4nderungen und Korrekturen in den Kernel. Kent ist der Meinung, dass die Behebung von Problemen im FS unverz\u00fcglich und auf beliebige Weise vorangetrieben werden sollte. Linus besteht darauf, dass funktionale \u00c4nderungen und gr\u00f6\u00dfere Korrekturen in der Anfangsphase der Entwicklung eines neuen Kernzweigs zul\u00e4ssig sind, w\u00e4hrend sich sp\u00e4te Release-Kandidaten nur auf die Behebung von Fehlern konzentrieren. Kent verst\u00f6\u00dft regelm\u00e4\u00dfig gegen diese Regel und schickt gro\u00dfe \u00c4nderungen zu einem unpassenden Zeitpunkt, was Linus Unmut und eine neue Welle von Konflikten beschert. Zuvor hatte Linus Kent bereits gewarnt, dass er Bcachefs aus dem Hauptkernel entfernen m\u00f6chte, da Kent weiterhin allein in seiner Sandkiste spielt, sich nicht an der gemeinsamen Arbeit beteiligt und sich weigert, die Spielregeln der Entwicklergemeinschaft zu akzeptieren. <\/p>\n
Im Fall des Kernels 6.16 hat Kent eine Reihe von Patches zur Aufnahme in das Update RC3 geschickt, darunter einen Patch mit der Implementierung der neuen Option «journal_rewind». Linus schrieb, dass Kent vergessen habe, dass nach dem Schlie\u00dfen des Fensters f\u00fcr funktionale \u00c4nderungen keine neuen Funktionen in den Kernel aufgenommen werden d\u00fcrfen, selbst wenn sie mit der Behebung anderer Fehler verbunden sind, da die Einf\u00fchrung neuer M\u00f6glichkeiten in den sp\u00e4ten Phasen der Release-Erstellung zu Regressionen f\u00fchren kann. Dar\u00fcber hinaus wird Bcachefs weiterhin als experimentelles Dateisystem positioniert, und die Geschwindigkeit der Fehlerbehebung ist dabei nicht so kritisch. <\/p>\n
Kent antwortete, dass das Hauptziel der Entwicklung — den Benutzern funktionierenden Code bereitzustellen, weshalb er nicht bereit sei, bei der Behebung von Fehlern, die die Datenintegrit\u00e4t betreffen, nachzugeben. Im Gegensatz zu anderen Teilsystemen werden Fehler im Dateisystem nicht durch einen Neustart behoben und k\u00f6nnen zu Datenbesch\u00e4digungen f\u00fchren. Daher ist es Kents Meinung nach nicht akzeptabel, die Behebung solcher Fehler bis zum n\u00e4chsten Fenster f\u00fcr \u00c4nderungsantr\u00e4ge zu verschieben, selbst wenn solche Behebungen umfangreiche \u00c4nderungen erfordern. <\/p>\n