Kent Overstreet, desarrollador del sistema de archivos Bcachefs, indicó que el futuro del sistema de archivos en desarrollo en el núcleo está en duda debido a las acciones del comité encargado de hacer cumplir el código de conducta en la comunidad de desarrolladores (Comité CoC). Linus Torvalds se negó a aceptar un nuevo conjunto de correcciones para Bcachefs en la rama del núcleo 6.13, citando quejas del comité de CoC.
Unos días antes, se realizó una modificación en los documentos que regulan la actividad relacionada con el código de conducta, introduciendo la posibilidad de bloquear a un desarrollador en caso de violar el código de conducta y negarse a resolver el conflicto según el escenario propuesto por el comité del CoC. La nueva redacción de las reglas, en caso de negarse a ofrecer una disculpa pública, permite imponer un "baneo" temporal que bloquea la aceptación de parches y pull requests, así como la exclusión del infractor del debate en la comunidad mediante el bloqueo del acceso a los correos y servicios de kernel.org.
Linus Torvalds, Greg Kroah-Hartman (responsable de las ramas estables del núcleo), Miguel Ojeda (Rust-for-Linux), Dave Hansen (responsable del subsistema mm de Intel), Jonathan Corbet (LWN), Steven Rostedt (Red Hat), Dan Williams (Intel), Theodore Ts'o (ext4) y Konstantin Ryabitsev (administrador de Kernel.org) acordaron las modificaciones al código de conducta. El bloqueo puede durar hasta el ciclo de desarrollo de una nueva rama del núcleo (aproximadamente 2 meses). Como condición para levantar el bloqueo, el comité del CoC puede exigir una disculpa pública del infractor. La decisión de bloquear se toma por el comité del CoC con el acuerdo de 2/3 de los participantes en la votación.
El bloqueo de Kent Overstreet está relacionado con la expresión ofensiva "Get your head examined. And get the fuck out of here with this shit.", dicha durante una discusión con Michal Hocko, uno de los desarrolladores del sistema de distribución de memoria en el núcleo. Los miembros del comité del CoC notaron la ofensa y solicitaron una disculpa pública, a lo que Kent respondió negándose, considerando inaceptable sacar asuntos personales a la luz pública y afirmando que ya habían resuelto el asunto de manera privada con Michal. Kent también mencionó las incómodas sugerencias sobre la necesidad de mantener la imagen de la comunidad, pero, según él, esto estaba dictado por el deseo de preservar la atracción de participación de las corporaciones en el proyecto.
Kent describió en detalle la historia y su visión del conflicto, y criticó la imposición, por parte del comité CoC, de una comunicación refinada en la comunidad, que, en su opinión, interfiere en la cultura ingenieril establecida. Las disputas generalmente surgen entre personas que se preocupan profundamente por su trabajo, pero que tienen diferentes puntos de vista. Durante debates acalorados, los desarrolladores pueden perder el control de sus emociones y gritarse entre sí, pero este es un proceso de trabajo aceptado por los participantes, que, al final, conduce a encontrar soluciones efectivas y avanzar en el proyecto.
Sostener los debates acalorados, según Kent, da lugar a una cultura de desprecio que disminuye las ganas de interactuar con los demás, convirtiendo el desarrollo en un club para unos pocos elegidos, en lugar de mantener una comunidad en la que todos puedan participar y expresar su opinión. El trabajo de los ingenieros se centra en resolver problemas complejos, no en evitarlos, y en este contexto, suprimir los debates en su inicio es una práctica perjudicial.
Según la observación de Kent, los debates acalorados suelen surgir cuando los desarrolladores quieren llegar al fondo de las cuestiones y tratan de resolver problemas técnicamente interesantes. Incluso si las partes en conflicto no pueden llegar a un acuerdo entre sí, hay una tercera persona que, al evaluar la situación desde fuera, puede resolver el problema, teniendo en cuenta los argumentos presentados por las diferentes partes del debate.
Kent reconoce que no se contuvo al intentar presentar argumentos técnicos, pero recibió a cambio excusas formales y una falta de interés en profundizar en los detalles. Se señala que el conflicto con el subsistema de gestión de memoria (mm) comenzó hace un año, cuando el responsable se negó a aceptar un cambio necesario para implementar un mecanismo de perfilado ligero para las operaciones de asignación de memoria. Para que el mecanismo funcionara, era necesario añadir macros sobre las funciones de asignación de memoria, y el responsable las rechazó, temiendo que pudieran afectar negativamente al rendimiento.
Un año después, la situación se repitió al intentar lograr un cambio relacionado con el manejo de errores en los sistemas de archivos: el mantenedor del subsistema mm volvió a rechazar el cambio, esta vez citando posibles implicaciones para la seguridad. Según Kent, el mantenedor no quiso profundizar en los detalles y escuchar los argumentos de otros desarrolladores que estaban de acuerdo con la necesidad del cambio, y se limitó a hacer valoraciones superficiales (el cambio estaba relacionado con la aceptación de una excepción que permitía el manejo de ciertos errores de asignación de memoria en el modo GFP_NOFAIL, que prohíbe el manejo externo de errores en secciones críticas, como el manejo de transacciones de registro en el FS, lo que lleva a la finalización forzada del proceso, incluso en situaciones en las que se podría manejar el error).
Kent también mencionó que los miembros del comité CoC también son propensos a ataques emocionales, por ejemplo, uno de sus integrantes durante una discusión en los pasillos de la conferencia se permitió expresiones bastante insultantes (llamó a otros desarrolladores 'assholes'). Este comportamiento en la comunicación personal en la conferencia no es más aceptable que en una lista de correo, y parece que los defensores del código intentan imponer a otros reglas que ellos mismos violan.
Fuente: opennet.ru
