Linus desafia a Paragon e critica o GitHub por fusões

Linus Torvalds é conhecido por ele é muito exigente quanto aos procedimentos e padrões que aqueles que ajudam a desenvolver o kernel do Linux devem seguir. E ele geralmente não é muito gentil com aqueles que não estão à altura da tarefa. Lembremos que no passado ele se afastou por um tempo de seu papel para repensar a maneira como se relacionava com as outras pessoas.

Desta vez, foi a Paragon Software, a empresa por trás do driver NTFS3, que gerou sua antipatia.  Anunciado para a versão 5.15 do kernel Linux, ele aprimorará o suporte para o sistema de arquivos nativo do Windows.

Sistemas de controle de versão (MCS)

Para que essa história seja entendida, vamos explicar alguns detalhes que nem todos precisam saber.

Desenvolvedores de projetos de software muito complexos usam software de controle de versão (geralmente operado por um provedor externo na nuvem) Este software permite que você rastreie quem, quando e o que faz as alterações.

Se você não faz parte dos membros do projeto, pode fazer um fork, ou seja, copiar os arquivos do projeto para o seu próprio repositório e, nele, fazer suas próprias modificações. Se gostar do resultado, pode sugerir ao administrador do projeto original que os incorpore, ligando para solicitação de puxar.

Liberação do controlador

No ano passado, a Paragon Software aEle anunciou o lançamento do código do controlador, que já comercializou anteriormente, se comprometendo também a cuidar da manutenção e atualizaçãon. Esta é uma boa notícia, pois é muito melhor do que o que estávamos usando atualmente.

Segundo a própria empresa

A versão atual funciona com arquivos normais / compactados / espaçosos e oferece suporte à reprodução de diário ACL e NTFS. A maior parte do código estava na ramificação linux-next desde 13 de agosto, mas há alguns patches que estiveram na ramificação linux-next por apenas alguns dias. Espero que esteja tudo bem - nenhuma regressão foi detectada nos testes. '

Após o anúncio da Paragon, o O driver NTFS3 teve que passar por muitas rodadas de revisão para melhorar a qualidade do código e torná-lo compatível com os padrões de codificação do resto do kernel.

Parece que ele finalmente conseguiu.

E assim chegamos à mãe das ovelhas.

Linus subtrai Paragon

Para incluir o driver na versão 5.15 do kernel, Linus Torvalds pediu à Paragon Software para fazer o solicitação de recebimento do qual falamos acima. A empresa fez isso, mas não da maneira que Torvalds gosta.

A primeira observação do finlandês foi que a solicitação pull deve ter sido assinada.

Em um mundo perfeito, essa seria uma assinatura PGP que poderia rastrear diretamente até você por meio da cadeia de confiança, mas nunca a solicitei.

Em segundo lugar, ele reclamou que a solicitação de pull isso foi feito na interface da web do serviço, que produz muitos códigos inúteis.

O Github é um site de hospedagem perfeitamente bom e faz várias outras coisas bem também, mas fusões não é uma dessas coisas.

Ele também protestou falta de informação suficiente.

Para o criador do Linux, "as fusões do kernel do Linux devem ser feitas corretamente." E acrescentou: «Isso significa enviar mensagens com informações sobre o que está sendo mesclado e * por que * algo está sendo mesclado. Mas também significa informações adequadas sobre autoria e committer, etc. Tudo isso o GitHub bagunça totalmente. '

Linus Torvalds sabe do que está falando, ele foi o criador do Git, o software no qual se baseiam serviços como o GitHub, agora propriedade da Microsoft. E, curiosamente, foi devido ao desacordo com outro serviço

Eu nunca quis fazer um programa de controle de versão, pois odiava todos eles… Então o BitKeeper apareceu e realmente mudou minha maneira de encará-los. BK acertou a maior parte e ter uma cópia local do repositório e mesclagem distribuída foi muito importante. A grande vantagem do controle de origem distribuído é que ele faz com que um dos principais problemas com os MCSs desapareça - a política em torno de "quem pode fazer alterações".

BK mostrou que isso pode ser evitado dando a cada um seu próprio repositório. Mas BK também tinha seus próprios problemas; houve algumas decisões técnicas que causaram problemas (renomear era doloroso), mas o maior inconveniente era o fato de que, por não ser de código aberto, muitas pessoas não queriam usá-lo. Portanto, embora tenhamos acabado com vários mantenedores do kernel usando BK - era grátis para usar em projetos de código aberto - nunca foi massivo, então ajudou no desenvolvimento do kernel, mas não era perfeito.

Então, em algum momento eu decidi que não poderia continuar usando o BK, mas eu realmente não queria voltar aos velhos tempos pré-BK. Infelizmente, na época, embora houvesse alguns outros SCVs que mais ou menos tentaram distribuir a coisa, nenhum deles se saiu remotamente bem. Eu tinha requisitos de desempenho que não eram nem remotamente satisfeitos com o que estava disponível e também estava preocupado com a integridade do código e de todo o fluxo de trabalho, então acabei decidindo escrever o meu próprio.