Кент Оверстрит (Kent Overstreet), разработчик ФС Bcachefs, сообщил, что будущее развиваемой им файловой системы в ядре под вопросом из-за действий комитета, отвечающего за соблюдение кодекса поведения в сообществе разработчиков (CoC Committee). Линус Торвальдс отказался принимать очередной набор исправлений к Bcachefs в состав ветки ядра 6.13, сославшись на наличие претензий со стороны комитета CoC.
За несколько дней до этого, в документы, регламентирующие активность, связанную с кодексом поведения, было внесено изменение, вводящее возможность блокировки разработчика, в случае нарушения кодекса поведения и несогласия урегулировать конфликт по предложенному комитетом CoC сценарию. Новая редакция правил вводит возможность выставления “бана” в случае отказа принести публичные извинения, на какое-то время блокирующего приём патчей и pull-запросов, а также исключающего нарушителя кодекса из обсуждений в сообществе путём блокирования доступа к почтовой рассылке и сервисам kernel.org.
С внесением изменений в кодекс поведения согласились Линус Торвальдс, Грег Кроа-Хартман (ответственный за стабильные ветки ядра), Мигель Охеда (Rust-for-Linux), Дэйв Хансен (сопровождающий подсистему mm из Intel), Джонатан Корбет (LWN), Стивен Ростедт (Red Hat), Дэн Вильямс (Intel), Теодор Цо (ext4) и Константин Рябцев (администратор Kernel.org). Блокировка может осуществляться на время, не превышающее цикл разработки новой ветки ядра (примерно 2 месяца). В качестве условий снятия блокировки комитет CoC может потребовать от нарушителя принесения публичного извинения. Решение о блокировке принимается комитетом CoC при согласии 2/3 участников голосования.
Блокировка Кента Оверстрита связана с оскорбительным выражением “Get your head examined. And get the fuck out of here with this shit.”, высказанным в ходе дискуссии с Михалом Хочко (Michal Hocko), одним из разработчиков системы распределения памяти в ядре. Оскорбление заметили члены комитета CoC и попросили принести публичное извинение, на что Кент ответил отказом, посчитав недопустимым поднятие личных дел на публику и заявив, что они c Михалом уже решили этот вопрос в личном порядке. Кент также упомянул оставившие неприятный осадок уговоры с упоминанием необходимости поддержать имидж сообщества, но, по мнению Кента, продиктованные желанием сохранить привлекательность участия в проекте корпораций.
Кент подробно описал историю и своё видение конфликта, а также раскритиковал навязывание комитетом CoC рафинированного общения в сообществе, которое, по его мнению, нарушает сложившуюся инженерную культуру. Cпоры обычно возникают между людьми, глубоко заботящимися о своей работе, но имеющими разные точки зрения. В ходе горячих споров разработчики могут не сдержать свои эмоции и накричать друг на друга, но это принимаемый участниками рабочий процесс, который в итоге приводит к нахождению эффективного решения и движению проекта вперёд.
Сдерживание жарких споров, по мнению Кента, приводит к появлению культуры пренебрежения, отбивающей желание взаимодействовать с другими, и превращающей разработку в клуб для избранных, вместо сохранения сообщества, в котором каждый может принять участие и высказать своё мнение. Работа инженеров сводится к тому, чтобы решать сложные проблемы, а не избегать их, в этом контексте подавление споров при их зарождении является вредной практикой.
По наблюдению Кента, жаркие споры обычно возникают, когда разработчики хотят докопаться до сути и пытаются решить технически интересные проблемы. Даже если спорщики не могут договориться между собой, находится третье лицо, которое оценив ситуацию со стороны, способно решить проблему, учтя доводы, представленными разными сторонами спора.
Кент признаёт, что не сдержался, пытаясь привести технические доводы, но получив в ответ формальные отговорки и не желание углубляться в детали. Отмечается, что конфликт с сопровождающим подсистему управления памятью (mm) зародился ещё год назад, когда сопровождающий отказался принимать изменение, необходимое для реализации легковесного механизма профилирования операций выделения памяти. Для работы механизма требовалось добавить макро-обвязки над функциями выделения памяти и сопровождающий отклонил их, опасаясь, что они могут негативно повлиять на производительность.
Спустя год ситуация повторилась при попытке добиться изменения, связанного с обработкой ошибок в файловых системах – сопровождающий подсистему mm опять отклонил изменение, на этот раз сославшись на возможное влияние на безопасность. По мнению Кента, сопровождающий не пожелал углубиться в детали и выслушать аргументы других разработчиков, согласившихся с необходимостью изменения, а ограничился лишь поверхностными суждениями (изменение было связано с принятием исключения, допускавшего обработку некоторых ошибок выделение памяти при выставленном режиме GFP_NOFAIL, запрещающем внешнюю обработку ошибок в критических секциях, таких как обработки транзакции журналирования в ФС, что приводит к принудительному завершению процесса, даже в ситуации, когда ошибку можно было обработать).
Кент также упомянул, что члены комитета CoC тоже не лишены эмоциональных выпадов, например, один из его участников при обсуждении в кулуарах на конференции позволял себе вполне оскорбительные выражения (назвал других разработчиков “asshole”). Такое поведение при личном общении на конференции не более приемлемо, чем в списке рассылки, и получается, что сторонники кодекса пытаются навязать другим правила, которые нарушают сами.