Kent Overstreet, desarrollador del sistema de archivos Bcachefs, indic\u00f3 que el futuro del sistema de archivos en desarrollo en el n\u00facleo est\u00e1 en duda debido a las acciones del comit\u00e9 encargado de hacer cumplir el c\u00f3digo de conducta en la comunidad de desarrolladores (Comit\u00e9 CoC). Linus Torvalds se neg\u00f3 a aceptar un nuevo conjunto de correcciones para Bcachefs en la rama del n\u00facleo 6.13, citando quejas del comit\u00e9 de CoC. <\/p>\n
Unos d\u00edas antes, se realiz\u00f3 un cambio en los documentos que regulan la actividad relacionada con el c\u00f3digo de conducta, introduciendo la posibilidad de prohibir a un desarrollador en caso de violar el c\u00f3digo de conducta y de no aceptar resolver el conflicto seg\u00fan el escenario propuesto por el comit\u00e9 de CoC. La nueva redacci\u00f3n de las reglas, en caso de rechazar presentar disculpas p\u00fablicas, introduce la posibilidad de imponer un 'baneo', que bloquea temporalmente la recepci\u00f3n de parches y solicitudes de extracci\u00f3n, as\u00ed como la exclusi\u00f3n del infractor del c\u00f3digo de las discusiones en la comunidad mediante el bloqueo del acceso a la lista de correo y a los servicios de kernel.org. <\/p>\n
Linus Torvalds, Greg Kroah-Hartman (responsable de las ramas estables del n\u00facleo), 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\u00f3digo de conducta. El bloqueo puede durar hasta el ciclo de desarrollo de una nueva rama del n\u00facleo (aproximadamente 2 meses). Como condici\u00f3n para levantar el bloqueo, el comit\u00e9 del CoC puede exigir una disculpa p\u00fablica del infractor. La decisi\u00f3n de bloquear se toma por el comit\u00e9 del CoC con el acuerdo de 2\/3 de los participantes en la votaci\u00f3n. <\/p>\n
El baneo de Kent Overstreet est\u00e1 relacionado con la expresi\u00f3n ofensiva 'Get your head examined. And get the fuck out of here with this shit.', mencionada durante una discusi\u00f3n con Michal Hocko, uno de los desarrolladores del sistema de distribuci\u00f3n de memoria en el n\u00facleo. La ofensa fue notada por miembros del comit\u00e9 de CoC, quienes pidieron disculpas p\u00fablicas, a lo que Kent respondi\u00f3 neg\u00e1ndose, considerando inapropiado sacar a relucir asuntos personales en p\u00fablico y afirmando que \u00e9l y Michal ya hab\u00edan resuelto este tema de manera privada. Kent tambi\u00e9n mencion\u00f3 que hab\u00eda una presi\u00f3n inc\u00f3moda con la necesidad de mantener la imagen de la comunidad, pero, en opini\u00f3n de Kent, esto respond\u00eda al deseo de conservar el atractivo de la participaci\u00f3n de las corporaciones en el proyecto. <\/p>\n
Kent describi\u00f3 en detalle la historia y su visi\u00f3n del conflicto, y critic\u00f3 la imposici\u00f3n, por parte del comit\u00e9 CoC, de una comunicaci\u00f3n refinada en la comunidad, que, en su opini\u00f3n, 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\u00ed, pero este es un proceso de trabajo aceptado por los participantes, que, al final, conduce a encontrar soluciones efectivas y avanzar en el proyecto. <\/p>\n
Sostener los debates acalorados, seg\u00fan Kent, da lugar a una cultura de desprecio que disminuye las ganas de interactuar con los dem\u00e1s, 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\u00f3n. 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\u00e1ctica perjudicial. <\/p>\n
Seg\u00fan la observaci\u00f3n de Kent, los debates acalorados suelen surgir cuando los desarrolladores quieren llegar al fondo de las cuestiones y tratan de resolver problemas t\u00e9cnicamente interesantes. Incluso si las partes en conflicto no pueden llegar a un acuerdo entre s\u00ed, hay una tercera persona que, al evaluar la situaci\u00f3n desde fuera, puede resolver el problema, teniendo en cuenta los argumentos presentados por las diferentes partes del debate. <\/p>\n
Kent reconoce que no se contuvo al intentar presentar argumentos t\u00e9cnicos, pero recibi\u00f3 a cambio excusas formales y una falta de inter\u00e9s en profundizar en los detalles. Se se\u00f1ala que el conflicto con el subsistema de gesti\u00f3n de memoria (mm) comenz\u00f3 hace un a\u00f1o, cuando el responsable se neg\u00f3 a aceptar un cambio necesario para implementar un mecanismo de perfilado ligero para las operaciones de asignaci\u00f3n de memoria. Para que el mecanismo funcionara, era necesario a\u00f1adir macros sobre las funciones de asignaci\u00f3n de memoria, y el responsable las rechaz\u00f3, temiendo que pudieran afectar negativamente al rendimiento. <\/p>\n
Un a\u00f1o despu\u00e9s, la situaci\u00f3n se repiti\u00f3 al intentar realizar un cambio relacionado con el manejo de errores en los sistemas de archivos; el mantenedor de la subsistema mm nuevamente rechaz\u00f3 el cambio, esta vez argumentando el posible impacto en la seguridad. Seg\u00fan Kent, el mantenedor no quiso profundizar en los detalles y escuchar los argumentos de otros desarrolladores que coincid\u00edan en la necesidad del cambio, limit\u00e1ndose a juicios superficiales (el cambio estaba relacionado con la aceptaci\u00f3n de una excepci\u00f3n que permit\u00eda manejar ciertos errores de asignaci\u00f3n de memoria bajo el modo GFP_NOFAIL, que proh\u00edbe el manejo externo de errores en secciones cr\u00edticas, como el procesamiento de transacciones de registro en el FS, lo que lleva a la terminaci\u00f3n forzada del proceso, incluso en situaciones donde se pudo haber manejado el error). <\/p>\n