Kent Overstreet, desenvolvedor do sistema de arquivos Bcachefs, informou que o futuro deste sistema que ele desenvolve no n\u00facleo est\u00e1 em d\u00favida devido \u00e0s a\u00e7\u00f5es do comit\u00ea respons\u00e1vel pela manuten\u00e7\u00e3o do c\u00f3digo de conduta da comunidade de desenvolvedores (Comit\u00ea CoC). Linus Torvalds se recusou a aceitar mais um conjunto de corre\u00e7\u00f5es para o Bcachefs na ramifica\u00e7\u00e3o do n\u00facleo 6.13, citando reclama\u00e7\u00f5es do comit\u00ea CoC. <\/p>\n
Poucos dias antes disso, foi feita uma altera\u00e7\u00e3o nos documentos que regulam as atividades relacionadas ao c\u00f3digo de conduta, permitindo a possibilidade de bloqueio do desenvolvedor em caso de viola\u00e7\u00e3o do c\u00f3digo de conduta e da recusa em resolver o conflito conforme o cen\u00e1rio proposto pelo comit\u00ea do CoC. A nova reda\u00e7\u00e3o das regras, em caso de recusa em fazer um pedido p\u00fablico de desculpas, permite a aplica\u00e7\u00e3o de um 'banimento', bloqueando temporariamente a aceita\u00e7\u00e3o de patches e pull requests, al\u00e9m de excluir o violador do c\u00f3digo das discuss\u00f5es na comunidade, bloqueando o acesso a mailing lists e servi\u00e7os do kernel.org. <\/p>\n
Acordaram com a altera\u00e7\u00e3o do c\u00f3digo de conduta Linus Torvalds, Greg Kroah-Hartman (respons\u00e1vel pelos ramos est\u00e1veis do n\u00facleo), Miguel Ojeda (Rust-for-Linux), Dave Hansen (mantenedor do subsistema mm da Intel), Jonathan Corbet (LWN), Steven Rostedt (Red Hat), Dan Williams (Intel), Theodore Ts'o (ext4) e Konstantin Ryabitsev (administrador do Kernel.org). O bloqueio pode ocorrer por um per\u00edodo n\u00e3o superior ao ciclo de desenvolvimento de um novo ramo do n\u00facleo (cerca de 2 meses). Como condi\u00e7\u00e3o para o levantamento do bloqueio, o comit\u00ea do CoC pode exigir que o infrator se desculpe publicamente. A decis\u00e3o de bloquear \u00e9 tomada pelo comit\u00ea do CoC com a concord\u00e2ncia de 2\/3 dos participantes da vota\u00e7\u00e3o. <\/p>\n
O bloqueio de Kent Overstreet est\u00e1 relacionado \u00e0 express\u00e3o ofensiva 'Get your head examined. And get the fuck out of here with this shit.', proferida durante uma discuss\u00e3o com Michal Hocko, um dos desenvolvedores do sistema de gerenciamento de mem\u00f3ria no n\u00facleo. O insulto foi notado pelos membros do comit\u00ea do CoC, que pediram um pedido p\u00fablico de desculpas, ao qual Kent respondeu negativamente, considerando inaceit\u00e1vel trazer assuntos pessoais para o p\u00fablico e afirmando que ele e Michal j\u00e1 haviam resolvido essa quest\u00e3o pessoalmente. Kent tamb\u00e9m mencionou os inc\u00f4modos provocados por sugest\u00f5es que envolviam a necessidade de manter a imagem da comunidade, mas, na opini\u00e3o de Kent, essas sugest\u00f5es surgiram do desejo de preservar a atratividade da participa\u00e7\u00e3o no projeto para as corpora\u00e7\u00f5es. <\/p>\n
Kent descreveu detalhadamente a hist\u00f3ria e sua vis\u00e3o do conflito, al\u00e9m de criticar a imposi\u00e7\u00e3o do Comit\u00ea CoC de uma comunica\u00e7\u00e3o refinada na comunidade, que, em sua opini\u00e3o, prejudica a cultura de engenharia estabelecida. Discursos acalorados geralmente surgem entre pessoas que se preocupam profundamente com seu trabalho, mas t\u00eam pontos de vista diferentes. Durante debates intensos, os desenvolvedores podem n\u00e3o conter suas emo\u00e7\u00f5es e gritar uns com os outros, mas esse \u00e9 um processo de trabalho aceito pelos participantes, que acaba levando \u00e0 busca de uma solu\u00e7\u00e3o eficaz e ao avan\u00e7o do projeto. <\/p>\n
Reprimir debates acalorados, na opini\u00e3o de Kent, leva \u00e0 cria\u00e7\u00e3o de uma cultura de desd\u00e9m, que desestimula a intera\u00e7\u00e3o com os outros e transforma o desenvolvimento em um clube exclusivo, ao inv\u00e9s de preservar uma comunidade em que todos possam participar e expressar suas opini\u00f5es. O trabalho dos engenheiros \u00e9 resolver problemas complexos, e n\u00e3o evit\u00e1-los. Nesse contexto, reprimir debates assim que surgem \u00e9 uma pr\u00e1tica prejudicial. <\/p>\n
De acordo com a observa\u00e7\u00e3o de Kent, debates intensos geralmente surgem quando os desenvolvedores querem chegar ao fundo do problema e tentam resolver quest\u00f5es tecnicamente interessantes. Mesmo que os debatedores n\u00e3o consigam chegar a um consenso, h\u00e1 sempre uma terceira pessoa que, ao avaliar a situa\u00e7\u00e3o de fora, \u00e9 capaz de solucionar o problema, levando em considera\u00e7\u00e3o os argumentos apresentados por diferentes partes do debate. <\/p>\n
Kent reconhece que n\u00e3o conseguiu conter-se ao tentar apresentar argumentos t\u00e9cnicos, mas recebeu em troca desculpas formais e falta de vontade de se aprofundar nos detalhes. \u00c9 not\u00e1vel que o conflito com o subsistema de gerenciamento de mem\u00f3ria (mm) come\u00e7ou h\u00e1 um ano, quando o respons\u00e1vel se recusou a aceitar a mudan\u00e7a necess\u00e1ria para implementar um mecanismo leve de perfilamento de opera\u00e7\u00f5es de aloca\u00e7\u00e3o de mem\u00f3ria. Para o funcionamento desse mecanismo, era necess\u00e1rio adicionar macros auxiliares sobre as fun\u00e7\u00f5es de aloca\u00e7\u00e3o de mem\u00f3ria, mas o respons\u00e1vel rejeitou isso, temendo que pudesse impactar negativamente o desempenho. <\/p>\n
Ap\u00f3s um ano, a situa\u00e7\u00e3o se repetiu ao tentar obter uma altera\u00e7\u00e3o relacionada ao tratamento de erros em sistemas de arquivos - o mantenedor da subsistema mm novamente rejeitou a altera\u00e7\u00e3o, desta vez alegando uma poss\u00edvel influ\u00eancia na seguran\u00e7a. Na opini\u00e3o de Kent, o mantenedor n\u00e3o quis se aprofundar nos detalhes e ouvir os argumentos de outros desenvolvedores que concordavam com a necessidade da altera\u00e7\u00e3o, limitando-se a considera\u00e7\u00f5es superficiais (a mudan\u00e7a estava relacionada \u00e0 aceita\u00e7\u00e3o de uma exce\u00e7\u00e3o que permitia o tratamento de certos erros de aloca\u00e7\u00e3o de mem\u00f3ria no modo GFP_NOFAIL, que pro\u00edbe o tratamento externo de erros em se\u00e7\u00f5es cr\u00edticas, como no tratamento de transa\u00e7\u00f5es de registro em sistemas de arquivos, levando \u00e0 finaliza\u00e7\u00e3o for\u00e7ada do processo, mesmo em situa\u00e7\u00f5es onde o erro poderia ter sido tratado). <\/p>\n