Kent Overstreet, the developer of the Bcachefs file system, stated that the future of his developed file system in the kernel is in question due to actions taken by the committee responsible for enforcing the code of conduct in the developer community (CoC Committee). Linus Torvalds refused to accept another set of patches for Bcachefs into the 6.13 kernel branch, citing complaints from the CoC committee. <\/p>\n
A few days prior to this, an amendment was made to the documents regulating activities related to the code of conduct, introducing the possibility of blocking a developer in case of violations of the code of conduct and refusal to resolve a conflict according to the scenario proposed by the CoC committee. The new version of the rules introduces a possibility of imposing a ban that would temporarily block the acceptance of patches and pull requests, as well as exclude the code violator from community discussions by blocking access to mailings and kernel.org services if they refuse to publicly apologize. <\/p>\n
Linus Torvalds, Greg Kroah-Hartman (responsible for stable kernel branches), Miguel Ojeda (Rust-for-Linux), Dave Hansen (maintainer of the mm subsystem from Intel), Jonathan Corbet (LWN), Steven Rostedt (Red Hat), Dan Williams (Intel), Theodore Ts'o (ext4), and Konstantin Ryabtsev (administrator of Kernel.org) agreed to the changes in the code of conduct. The blocking can be for a duration not exceeding the development cycle of a new kernel branch (approximately 2 months). As a condition for lifting the ban, the CoC committee may require the violator to issue a public apology. The decision to impose a ban is made by the CoC committee with the agreement of 2\/3 of the voting members. <\/p>\n
Kent Overstreet's blocking is related to the offensive remark 'Get your head examined. And get the fuck out of here with this shit.' made during a discussion with Michal Hocko, one of the developers of the kernel's memory management system. The offense was noted by members of the CoC committee who requested a public apology, to which Kent responded with a refusal, considering it unacceptable to air personal matters publicly and stating that he and Michal had already resolved this issue privately. Kent also mentioned that he was left with an unpleasant impression regarding the insistence on upholding the community's image, which, in his opinion, was dictated by the desire to maintain corporate interest in the project. <\/p>\n
Kent detailed the history and his perspective on the conflict and criticized the CoC committee's imposition of refined communication within the community, which he believes disrupts the established engineering culture. Disputes typically arise among individuals who care deeply about their work but hold differing viewpoints. In intense debates, developers may lose their temper and shout at one another, but this is an accepted part of the process that ultimately leads to effective solutions and propels the project forward. <\/p>\n
Kent believes that stifling heated debates results in a culture of neglect that discourages interaction with others, transforming development into an exclusive club rather than maintaining a community where everyone can participate and voice their opinions. Engineers' work revolves around solving complex problems, not avoiding them, making the suppression of disputes as they arise a harmful practice in this context. <\/p>\n
According to Kent, heated disputes usually occur when developers seek to get to the heart of the matter and address technically intriguing challenges. Even if the disputants cannot reach an agreement, a third party can evaluate the situation externally and solve the problem by considering the arguments presented by both sides of the dispute. <\/p>\n
Kent acknowledges that he lost his temper while trying to present technical arguments, only to receive formal excuses and a reluctance to delve into details in response. It is noted that the conflict with the memory management subsystem (mm) originated a year ago when the maintainer refused to accept a change needed for implementing a lightweight profiling mechanism for memory allocation operations. To operate this mechanism, it was necessary to add macro wrappers around the memory allocation functions, but the maintainer rejected them, fearing they might negatively affect performance. <\/p>\n
A year later, the situation repeated itself when an attempt was made to advocate for changes related to error handling in file systems \u2014 the maintainer of the mm subsystem again rejected the change, this time citing potential security implications. According to Kent, the maintainer refused to delve into the details and listen to the arguments of other developers who agreed on the necessity of the change and instead limited himself to superficial judgments (the change was related to the acceptance of an exception that allowed handling certain out-of-memory errors under the GFP_NOFAIL mode, which prohibits external error handling in critical sections, such as journal transaction handling in the filesystem, leading to forced process termination even when the error could have been handled). <\/p>\n