Primeira parte da entrevista.
Sistema de controle de versão distribuído Git
JA: Linux é apenas o primeiro de seus projetos a impactar globalmente o mundo do código aberto. Em 2005, você também criou o Git, um sistema de controle de versão distribuído extremamente popular. Você rapidamente moveu sua árvore de origem do kernel Linux do repositório Bitkeeper proprietário para o Git recém-criado, que você tornou o código-fonte aberto, e no mesmo ano você transferiu o suporte do Git para Junio Hamano . A história desses eventos é fascinante, conte-nos o que o levou a entregar este projeto tão rapidamente, e como você encontrou e escolheu Junio?
LT: Portanto, a resposta a essa pergunta tem duas partes.
Primeiro, eu absolutamente não queria criar um novo sistema de controle de origem. O Linux foi criado porque eu estava muito interessado na interface de baixo nível entre hardware e software - a princípio, esse trabalho foi feito por amor ao assunto e interesse pessoal. Pelo contrário, o Git foi criado por necessidade: não porque eu estivesse interessado no controle de origem, mas porque a maioria dos sistemas de controle de versão disponíveis naquela época me deram um verdadeiro desgosto, e aquele que me pareceu o mais suportável e ao mesmo tempo realmente funcionou muito bem com o modelo de desenvolvimento do Linux (BitKeeper) faliu.
Resumindo: trabalho no Linux há mais de 30 anos ( ainda faltam alguns meses para o aniversário do primeiro lançamento , mas comecei a trabalhar no que mais tarde se tornou o Linux há mais de 30 anos), e todo esse tempo eu têm apoiado isso. Mas Git? Eu nem pensei em como mantê-lo no longo prazo. Eu definitivamente gosto dele e, claro, acho que é o melhor sistema de controle de fonte disponível, mas não é meu grande amor e paixão, se é que você me entende.
Então, eu sempre quis encontrar alguém para manter esse sistema de controle de origem para mim; na verdade, eu ficaria feliz em não escrever nada.
Este é o contexto.
Quanto a Junio - na verdade, ele é um dos primeiros a realmente entrar no desenvolvimento do Git. As primeiras mudanças dele vieram a mim alguns dias depois que eu disponibilizei publicamente a primeira (e muito grosseira) versão do Git. Portanto, Junio está envolvido neste projeto, pode-se dizer, desde os primeiros dias do Git.
Mas não pense que acabei de entregar o projeto à primeira pessoa que conheci. Tenho mantido o Git por vários meses, e o que me levou a perguntar a Junio se ele gostaria de assumir esse suporte é o sutil senso de "bom gosto". Na verdade, não posso descrever com mais precisão: a programação é reduzida a resolver problemas técnicos, mas a questão é comovocê os resolve, e essa é uma daquelas coisas que começam a ser reconhecidas com o tempo: certas pessoas têm “bom gosto” e por isso escolhem a solução “certa”.
Não quero fingir que programar é uma arte, porque, na realidade, programar é basicamente uma boa engenharia. Acredito profundamente no mantra de Thomas Edison de "um por cento de talento e noventa e nove por cento de diligência"; quase todo o ponto de sucesso está em pequenos detalhes e no trabalho de rotina diário. Mas, no entanto, às vezes você tem que mostrar “inspiração” e aquele “bom gosto”, ou seja, não apenas resolver um problema, mas resolvê-lo de forma limpa, precisa e, sim, até lindamente.
Junio tem um "bom gosto".
Sempre que se trata de Git, lembro-me de ser muito claro sobre isso: embora tenha sido o pioneiro do Git e projetado suas ideias centrais, muitas vezes recebo um grande reconhecimento por ele. Isso foi há mais de 15 anos, e eu só estive realmente imerso no Git durante o primeiro ano. Junio é exemplar no suporte ao Git, e é por causa dele que o Git é o que é hoje.
Aliás, toda essa história com “bom gosto” e procurando por pessoas que o possuam, bem como com a capacidade de confiar nessas pessoas - se aplica não apenas ao Git, mas não menos extensamente a toda a história do Linux. Ao contrário do Git, o Linux é um produto que ainda suporte. Estou ativamente engajado, mas o que o Linux é em muitos aspectos semelhante ao Git é o envolvimento de um grande número de pessoas no projeto. Acho que uma das conquistas mais notáveis do Linux é que existem literalmente centenas de contribuidores ativos apoiando-o, e todos eles, que são responsáveis por diferentes partes do kernel, têm essa dificuldade de definir "senso de gosto".
JA: Você já delegou apoio a alguém e depois percebeu que essa decisão estava errada?
LT: A estrutura do nosso trabalho de apoio nunca foi tão preto e branco ou inflexível a ponto de nos causar problemas. Na verdade, é improvável que algum dia tentaremos documentar completamente o procedimento de suporte. Sim, temos um arquivo MAINTAINERS, mas ele foi criado para que você possa encontrar as pessoas certas não é realmente um sinal de algum tipo de posse exclusiva.
Portanto, toda a estrutura “quem é dono do quê” é maioritariamente plástica e orientada, significa “esta pessoa é ativa e faz bem o seu trabalho”, e não “opa, confiamos o projeto à pessoa, mas ele pegou e estragou tudo ”.
A situação também é plástica no sentido de que talvez você esteja dando suporte a um subsistema, mas precisa pegar algo de outro sistema - então, esses limites são permeáveis. Normalmente, essas coisas são primeiro discutidas ativamente com as pessoas e só depois são feitas, mas o ponto é que existe essa prática, e não existem regras rígidas e rápidas como “você só pode tocar neste arquivo”.
Na verdade, aqui revisitamos o tópico de licenciamento levantado na Parte 1 e destacamos um dos princípios pelos quais o Git foi projetado, que é "todos têm sua própria árvore e, tecnicamente, nenhuma árvore é especial".
Uma vez que muitos outros projetos têm ferramentas utilizadas como CVS ou SVN - fundamentalmente algumas pessoas que especial tornar-se e aproveitar a "posse" que vem com esse status. No mundo do BSD, esse fenômeno é chamado de "bit de confirmação": é um bit cujo dono tem o direito de enviar o código para o repositório central (ou pelo menos algumas partes dele).
Sempre odiei esse modelo, porque inevitavelmente afeta a política e gera um "clique" na comunidade de desenvolvedores, onde algumas pessoas se tornam privilegiadas e são confiáveis por padrão. O problema não é nem mesmo que eles "confiem por padrão", mas apenas do outro lado da moeda: eles não confiam em alguém, em outras pessoas , e eles, por definição, acabam sendo estranhos que precisam passar por um dos “guardas” para fazer o trabalho. ".
Novamente, este não é o caso no Git. Todos são iguais. Todos podem clonar um branch, iniciar seu próprio desenvolvimento, e se fizerem um bom trabalho, quando eles se fundirem, seu branch pode retornar ao principal, e se estiver bem, então é confiado a eles o suporte, e eles são os únicos que passam a ser responsáveis por mesclar o código nas árvores pelas quais são responsáveis;).
Portanto, não há necessidade de dotar as pessoas de privilégios especiais, um "pedaço de confirmação". Isso também significa que nenhuma política de confirmação surge, ninguém precisa "confiar por padrão". Se descobrir que alguém fez um trabalho ruim ou, mais frequentemente, a pessoa simplesmente perdeu o interesse no projeto e achou o trabalho mais interessante - seu trabalho não entrará no branch principal ao mesclar e eles não ficarão confusos sob os pés de outras pessoas que podem oferecer idéias novas e frescas.
JA: Você já ficou impressionado com os novos recursos do Git e os incorporou em seus fluxos de trabalho? Você pode citar os recursos que, em sua opinião, ainda faltam no Git?
LT: claro, em primeiro lugar, eram meus desejos de funcionalidade que foram satisfeitos, então raramente tive que pensar em quaisquer novos recursos.
O Git definitivamente melhorou ao longo dos anos, e algumas dessas melhorias também se refletiram em meus fluxos de trabalho. Por exemplo, o Git sempre foi muito rápido - afinal, esse foi um dos objetivos de design que me propus a fazer, mas muito do trabalho foi originalmente feito em scripts de shell organizados em torno de alguns programas auxiliares básicos. Com o passar dos anos, a maioria desses scripts de shell sumiu, o que significa que posso aplicar os kits de patch de Andrew Morton ainda mais rápido do que originalmente. Isso é muito encorajador, pois foi a velocidade de trabalho com patches que usei como um dos primeiros benchmarks em testes de desempenho.
Então, para mim, Git sempre foi bom, mas só ficou melhor com o tempo.
Significativo as melhorias estão relacionadas a quão mais confortável se tornou para "usuários regulares" trabalhar com o Git. Em grande parte devido ao fato de que as pessoas descobriram como o fluxo de tarefas funciona no Git e se acostumaram a ele (é muito diferente do CVS e outros análogos aos quais as pessoas estão acostumadas), mas o próprio Git se tornou muito mais agradável de usar.
Os servidores em nuvem da Macleod são rápidos e seguros.
Cadastre-se pelo link acima ou clicando no banner e ganhe 10% de desconto no primeiro mês de aluguel de um servidor de qualquer configuração!
