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.
A few days before this, a change was made to the documents governing activities related to the code of conduct, introducing the possibility of blocking a developer in case of a violation and refusal to resolve the conflict according to the scenario proposed by the CoC committee. The new version of the rules allows for a temporary "ban" that blocks the acceptance of patches and pull requests, as well as excluding the violator from community discussions by blocking access to the mailing list and kernel.org services if they refuse to publicly apologize.
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.
Kent Overstreet's suspension is linked 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 memory allocation system in the kernel. Members of the CoC committee noticed the insult and requested a public apology, to which Kent responded with refusal, deeming it unacceptable to raise personal issues in public and stating that he and Michal had already resolved the matter privately. Kent also mentioned discomfort concerning suggestions that emphasized the need to uphold the community's image, which Kent believed was motivated by a desire to maintain corporate participation in the project.
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.
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.
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.
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.
A year later, the situation repeated when attempting to achieve a change related to error handling in file systems — the maintainer of the mm subsystem again rejected the change, this time citing potential security implications. According to Kent, the maintainer was unwilling to delve into the details and listen to the arguments of other developers who supported the necessity of the change, instead limiting himself to superficial judgments (the change involved accepting an exception that allowed handling certain memory allocation errors when the GFP_NOFAIL mode was set, which prohibits external error handling in critical sections, such as the transaction logging in the FS, resulting in the process being forcefully terminated even when the error could have been handled).
Kent also mentioned that members of the CoC committee are not free from emotional outbursts; for instance, one of its members made quite offensive remarks during informal discussions at the conference (calling other developers "assholes"). Such behavior in personal interactions at the conference is no more acceptable than in a mailing list, which indicates that supporters of the code are trying to impose rules on others that they themselves violate.
Source: opennet.ru
