Siguiendo el ejemplo de Héctor Martín, quien se retiró de sus responsabilidades como mantenedor y dejó de participar en la revisión de paquetes, Karol Herbst, quien ha mantenido el controlador Nouveau y el mecanismo de trazado MMIO (MMIOTRACE) en la compañía Red Hat, también anunció su renuncia. Después de su partida, quedarán en el núcleo otros dos mantenedores que apoyan el controlador Nouveau y que, según Karol, están haciendo un excelente trabajo.
La razón de su salida se menciona como la falta de un ambiente inclusivo entre los desarrolladores del núcleo. Karol está convencido de que en la comunidad de desarrollo de software libre, el trabajo debe realizarse con respeto, en igualdad y sin jugar con el poder. Según Karol, la gota que colmó el vaso fue el mensaje de Theodore Ts'o, en el que comparaba a los mantenedores con una 'delgada línea azul' (identificada con las fuerzas del orden y simboliza la frontera entre el orden y la anarquía), que busca que el código aceptado en el núcleo sea mantenible y de calidad.
Según Karol, alguien que dice esas palabras no puede ocupar un puesto como mantenedor, sin importar cuán importante sea para el proyecto, y debe ser excluido antes de que se dé cuenta de lo que esas palabras significan para muchas personas marginadas y el horror que provocan en sus mentes. Karol se va porque no puede permanecer en una comunidad que tolera tales palabras.
Theodore Ts'o hizo la comparación con la delgada línea azul durante una discusión sobre la resistencia de los desarrolladores veteranos al avance de Rust en el núcleo. Escribió que el poder de los mantenedores es limitado y no pueden influir en el desarrollo de cambios ya aprobados, ya que no tienen la capacidad de ordenar a las personas que trabajen en mejoras y en la infraestructura de pruebas. La única herramienta para garantizar la calidad es la capacidad de los mantenedores para prevenir la inclusión en el núcleo de cambios crudos y problemáticos. Una vez que el código es aceptado, los mantenedores pierden su influencia sobre los desarrolladores y se convierten en responsables personales de ese código.
Al adoptar un cambio significativo, los mantenedores deben asegurarse de que el cambio funcione completamente y que sus desarrolladores sean capaces de mantener el código después de que se integre en el núcleo y no lo dejen sin supervisión. Teodor menciona como ejemplo a aquellos equipos que solo están interesados en promover su proyecto, que desaparecen tan pronto como su código es aceptado y no vuelven a aparecer, dejando a los mantenedores lidiar con todas las deficiencias cometidas.
Algunos lanzan acusaciones de doble rasero, ya que el código de algunos desarrolladores es aceptado casi de inmediato, mientras que el de otros se demora. En este aspecto, la confianza establecida y la reputación merecida son importantes. Si un desarrollador ya ha demostrado su capacidad para hacerse cargo de los cambios entregados, las aprobaciones son rápidas. Para los novatos, la aceptación de los cambios puede alargarse, ya que el revisor debe entender si el participante podrá hacerse cargo de su código. Por lo tanto, los participantes, especialmente aquellos que intentan promover cambios radicales, deben dedicar mucho tiempo a convertirse en parte de la comunidad. Por ejemplo, la integración de cambios para compilar el núcleo con el compilador Clang tomó 10 años.
Fuente: opennet.ru
