De um tradutor: este texto é uma tradução de uma postagem de blog pessoal de Michael Stapelberg, um destacado desenvolvedor de código aberto ( perfil do GitHub ), que fez uma contribuição significativa para o desenvolvimento do Debian.
Foi difícil escrever este post do ponto de vista emocional, mas não me limitei a "uma carta curta, porque não tinha tempo". Antes de ler este texto, lembre-se de que estou escrevendo com as melhores intenções e não tenho como objetivo desmotivar ou menosprezar a contribuição de um dos desenvolvedores. Em vez disso, quero explicar por que meu nível de frustração excedeu todos os valores aceitáveis.
O Debian faz parte da minha vida há 10 anos.
Algumas semanas atrás, em uma reunião do Debian em Zurique, encontrei meus velhos amigos que não via há muitos anos. Quando eu já estava andando de bicicleta em casa, percebi que todos os tópicos que discutimos se resumiram ao que discutimos com eles da última vez. Discutimos os méritos do systemd, que mais uma vez atraíram a atenção da comunidade de código aberto, abordando o tópico de processos no Debian. O ponto culminante foi a discussão da democracia enquanto tal e os correspondentes erros teóricos e práticos. Mas, de fato, esse é um tópico puramente suíço.
Esta não é uma revisão do mitap do passado, só quero explicar o que me fez pensar sobre minha atual atitude em relação ao Debian e se ela me convém.
Então, tomei uma decisão que tive que tomar há muito tempo: estou diminuindo minha participação no desenvolvimento do Debian.
O que isso significa?
Nas próximas semanas, acontecerá o seguinte:
- Vou passar os pacotes importantes para o comando mantido;
- Eu me removerei dos pacotes Uploaders que contêm outros mantenedores;
- os pacotes em que eu era a única escolta se tornariam órfãos.
Tentarei continuar mantendo as páginas
manpages.debian.org e o serviço
codesearch.debian.net , mas aprecio muito qualquer ajuda nessa área.
Se você tiver alguma dúvida ou tarefa, considere que estou de férias indefinidas. Tentarei participar de algumas questões administrativas (por exemplo, a transferência de permissões) e tarefas endereçadas pessoalmente a mim, mas somente se não demorar muito tempo.
Porque
Quando entrei no Debian, eu ainda estava estudando, ou seja, eu tinha muito tempo livre. Agora, depois de cinco anos em período integral, aprendi muito - tanto em termos de como e no que funciona em grandes projetos de desenvolvimento de software, quanto em entender minhas preferências pessoais em sistemas de computadores. Agora estou claramente ciente do que passo nessa pequena parte do meu tempo livre e do que me resta no final do dia.
Cada uma das seções a seguir se concentrará em coisas que me machucaram como desenvolvedor. Esta lista é fornecida em ordem aleatória. Alguns desses problemas se afetam, por exemplo - se as alterações do sistema fossem realizadas melhor, teríamos a chance de os pacotes serem mais fáceis de manusear pela máquina.
Processo de Mudança Debian
Nos últimos anos, minha equipe atual vem trabalhando em várias reorganizações em toda a base de código (afetando milhares de projetos), por isso recebemos muitas lições valiosas sobre como fazer essas alterações com eficiência. Me incomoda que o Debian funcione de quase todos os modos, quase da maneira oposta. Eu aprecio o fato de que cada projeto é diferente, mas acho que muitos dos pontos listados abaixo se aplicam ao Debian como um todo.
No Debian, o desenvolvimento de pacotes está indo na direção certa usando um documento chamado Debian Policy, ou sua versão de software
, Lintian .
Apesar do fato de que o fiapo é muito conveniente para obter um feedback rápido direto ou local / autônomo, é ainda melhor não exigir tal ferramenta. Por exemplo, o comando C ++, que introduz um novo sinalizador de segurança para todos os pacotes, também deve ser capaz de tornar seu trabalho transparente (a
julgar pelo perfil do GitHub, o idioma principal do Go é Michael, aproximadamente Trans. ).
Em vez disso, agora todos os pacotes estão sendo feitos “sujos” (orig. - fiapo-impuro): todos os participantes devem ler o que é essa coisa nova, como ela pode quebrar, se afeta o trabalho em geral e, se sim, como. Então você precisa executar manualmente alguns testes e, finalmente, descartar as alterações. Tudo isso é uma infinidade de operações mecânicas aéreas e manuais entre pacotes.
No modelo Debian, a
decisão de lançar as notícias repousa nos pacotes que o acompanham, e não nos desenvolvedores. No meu trabalho principal, descobrimos que é mais eficiente fazer o oposto: se a alteração escrita afeta uma parte significativa dos usuários, são os desenvolvedores que devem decidir sobre a necessidade de sua implementação. Essa abordagem torna o desenvolvimento do projeto mais eficiente e reduz os custos de tempo e mão de obra. Obviamente, há exceções, por exemplo, em grandes áreas onde os chips de idiomas são usados, que devem ser tratados pelos respectivos proprietários-curadores, mas o importante é que, por padrão, tudo deve ser diferente do que é agora.
O Debian
não possui ferramentas para fazer grandes mudanças : é programaticamente difícil trabalhar com pacotes e repositórios fragmentados (mais sobre isso na seção abaixo). O evento mais próximo do "envio de alterações para a revisão" padrão é o processo de abrir um relatório de bug com um patch anexado. Pareceu-me que o processo existente de aceitar uma correção de bug era muito complicado e comecei a trabalhar em um bot de mesclagem, mas apenas Guido e mais ninguém mostraram interesse nele (
aparentemente, o autor fala sobre Guido agx Gunter , outro desenvolvedor Debian, - aprox .
Em termos literários, a reação ao impulso e, consequentemente, o recebimento de feedback são lentas. Simplesmente não há prazos. Às vezes, recebo e-mails avisando que o patch que enviei há vários anos (!!!) foi finalmente contido. Isso prolonga os projetos semanais por muitos anos, o que para mim é um poderoso desmotivador.
É curioso notar, mas a prática da atividade on-line de tartaruga também é projetada na cultura off-line, e não quero discutir as vantagens do systemd 10 anos depois de ouvi-lo pela primeira vez.
E, finalmente, qualquer mudança pode ser paralisada por aqueles que discordam, que se recusam a cooperar. Meu exemplo canônico dessa situação é rsync. O curador recusou meus remendos, que adicionam suporte ao debhelper ao pacote, apenas a partir de suas próprias crenças.
Conceder esse grau de liberdade pessoal a mantenedores individuais impede que todos nós, participantes do projeto, aumentemos o nível de abstração da compilação Debian, o que, por sua vez, complica as ferramentas de desenvolvimento.
Como seria tudo isso em um mundo ideal?
- Como projeto, devemos lutar pela unificação. Afinal, a unificação não exclui experimentos; simplesmente altera o compromisso atual entre experimentos mais simples e automação mais complexa para um compromisso entre experimentos mais complexos e automação mais simples.
- Nossa cultura de desenvolvimento deve se afastar do paradigma “este pacote é minha casa, como você se atreve a tocá-lo”, um senso comum de propriedade, no qual qualquer participante pode facilmente fazer ou verificar alterações, mesmo sem envolver curadores específicos que os acompanhem.
Para entender como são as grandes alterações bem-sucedidas (patches), recomendo que você leia a apresentação do meu colega Hiram Wright
"Mudanças em larga escala no Google: lições aprendidas com as migrações em massa de cinco anos" .
Fluxo de trabalho e infraestrutura fragmentados
O Debian normalmente prefere abordagens descentralizadas em relação às centralizadas. Por exemplo, pacotes separados são armazenados em repositórios separados, e cada repositório pode usar qualquer SCM (geralmente git e svn) ou não. Além disso, cada repositório pode ser hospedado em qualquer site. Obviamente, o conteúdo de cada repositório também varia um pouco de equipe para equipe, e até dentro da equipe.
Na prática, as opções de hospedagem não padrão raramente são usadas, uma vez que não justificam seu custo, mas costumam causar bastante sofrimento ao tentar automatizar o processo de fazer alterações nos pacotes. Portanto, em vez de usar a API do GitLab para criar solicitações de mesclagem, você precisa desenvolver um sistema completamente diferente e mais complexo que funcione periodicamente (ou constantemente!) Repositórios inacessíveis, abstrai as diferenças nos patches entregues (relatórios de erros, solicitações de mesclagem) , solicitações de extração) e assim por diante ...
Processos de desenvolvimento radicalmente diferentes não são apenas uma perda de tempo. Participei de longas discussões sobre vários processos de desenvolvimento de git durante o DebConf 13 e percebi que discussões semelhantes estavam sendo realizadas na época.
Pessoalmente, não lembro detalhes suficientes sobre as várias metodologias de desenvolvimento. Toda vez que toco em um pacote que não funciona como o meu, fico muito chateado porque preciso reexaminar aspectos de seu trabalho.
Percebi uma fragmentação semelhante do fluxo de trabalho em minha própria equipe de empacotamento Go e tentei corrigi-lo
fazendo sugestões de alterações no fluxo de trabalho , mas não consegui implementá-las. A falta de automação eficaz e a baixa taxa de mudança nas ferramentas, apesar da minha disposição de gastar meu próprio tempo e energia, acabaram com qualquer motivação.
Infraestrutura obsoleta: pacotes de download
Quando você deseja disponibilizar um pacote no Debian, carrega arquivos assinados por GPG via FTP anônimo. Existem vários tipos de tarefas (o daemon da fila, desmarcado, dinstall e outros) que são executados em um planejamento fixo (por exemplo, o dinstall é executado às 01:52 UTC, 07:52 UTC, 13:52 UTC e 19:52 UTC).
Calculei que, dependendo da hora do dia, você pode esperar mais de 7 horas (!!!) antes de instalar seu pacote.
Mas a pior parte para mim é que o feedback é assíncrono em relação ao carregamento. Eu gosto de fazer algo, finalizá-lo e passar para a próxima tarefa. A configuração atual requer uma longa espera e, de fato, uma troca cara entre tarefas sem boas razões técnicas. Você pode notar que alguns minutos realmente não importam, mas quando todo o tempo em um dia que eu posso gastar no Debian é medido em minutos, é de grande importância perceber o meu próprio desempenho e satisfação com o trabalho realizado.
A última mensagem que posso encontrar sobre como acelerar esse processo é uma
postagem de George Ganneff Jaspert de 2008.
Como seria tudo isso em um mundo ideal?
- O FTP anônimo seria substituído por um serviço da web que aceita meu pacote e retorna em sua resposta uma decisão oficial de aceitá-lo ou rejeitá-lo.
- Para pacotes recebidos, há uma página exibindo o status da compilação e a hora em que o pacote estará disponível através de uma rede de espelhos.
- Os pacotes devem estar disponíveis alguns minutos após a conclusão da montagem.
Infraestrutura preterida: Bug Tracker
Eu tenho medo de interagir com o rastreador de erros do Debian. Debbugs é um pedaço de código direto de 1994 que atualmente é usado apenas pelo Debian e pelo projeto GNU.
Os processos de depuração são baseados no uso de email, ou seja, são assíncronos e pesados. Apesar de funcionar nas máquinas mais rápidas que temos no projeto Debian (bem, eles me disseram quando este tópico foi abordado pela última vez), sua interface da Web carrega extremamente lentamente.
Notavelmente, a interface da web no bugs.debian.org é somente leitura.
Configurar um
espaço de
trabalho de email para
reportbug (1) ou trabalhar manualmente com anexos é um desafio bastante sério.
Por alguma razão que eu não entendo, toda interação com debbugs leva a
muitas conversas .
Além da implementação técnica, também não me lembro de nenhuma maneira das várias maneiras pelas quais o Debian usa pacotes de pseudo geração para erros e processos. Preciso deles muito raramente para eu finalmente colocar tudo na minha cabeça e lembrar exatamente como eles funcionam e são usados, mas ocasionalmente os encontro, então essa variedade é irritante.
Como seria tudo isso em um mundo ideal?
- O Debian mudará de uma maneira não padrão de rastrear bugs para (qualquer) já resolvido.
- O Debian automatiza esses processos. A interface principal deve ser mais conveniente (por exemplo, um formulário da web).
Infraestrutura obsoleta: arquivos por correspondência por e-mail
Estou confuso com o fato de que em 2019 ainda não temos uma ferramenta conveniente para exibir tópicos de discussão arquivados no correio. Tão amplamente quanto no Debian, email e conversas não são mais usados em nenhum lugar, por isso é até um tanto irônico. O uso de
Gmane pareceu resolver esse problema, mas sua disponibilidade nos últimos anos foi, para dizer o mínimo, abrupta (agora, no momento em que escrevemos este post, ele não funciona).
Tentei criar um arquivo multithread, mas nossos mestres de folha não ficaram impressionados e recusaram-se a apoiar o projeto.
É difícil para máquinas trabalhar com o Debian
Embora seja óbvio que você possa trabalhar com pacotes Debian programaticamente, essa experiência não é agradável. Tudo parece lento e volumoso. Selecionei três pequenos exemplos para ilustrar minha posição sobre esse assunto.
O debiman precisa da
ajuda da piuparts na análise do mecanismo alternativo de cada pacote para exibir páginas de documentação, por exemplo,
PSQL (1) . Isso foi necessário porque os scripts modificam o banco de dados alternativo chamando scripts de shell. Mas, sem realmente instalar o pacote, você não saberá quais alterações ele faz.
O pk4 deve manter seu próprio cache para procurar metadados do pacote com base em seu nome. Outras ferramentas analisam o banco de dados apt do zero a cada chamada. O formato correto do banco de dados, ou pelo menos o formato de troca binária, será de grande importância para esse processo.
A Pesquisa de Código Debian deseja receber novos pacotes o mais rápido possível. A instância
fedmsg foi usada anteriormente, mas não existe mais. Não está claro onde receber notificações de novos pacotes e onde é melhor recebê-las.
Pilha de compilação complexa
Aqui você pode ler meu post
“Ferramentas de Compilação de Pacotes Debian” . O que realmente me preocupa é o fato de que aumentar o número de ferramentas não é considerado um problema.
O Debian é uma experiência dolorosa para um desenvolvedor
A maioria das perguntas que eu levantei se refere à experiência de desenvolvimento do Debian, mas, como descrevi recentemente no meu post sobre
Debian Debug Debug Debugging Experience , a experiência de desenvolvimento
usando o Debian também deixa muito a desejar.
Tenho mais ideias
O artigo acabou sendo bastante volumoso, mas espero que você tenha uma idéia aproximada da minha motivação.
Embora eu tenha descrito várias falhas específicas acima, o último prego na tampa do caixão é a falta de uma perspectiva positiva para o futuro. Tenho outras idéias que me parecem realmente convincentes, mas com base em como meus projetos anteriores progrediram, acho que não posso implementar nenhuma delas como parte do projeto Debian.
Pretendo postar mais algumas postagens sobre maneiras específicas de melhorar os sistemas operacionais no meu blog. Então entre.
E finalmente, espero que este post inspire alguém, idealmente um grupo de pessoas, a melhorar a vida dos desenvolvedores Debian.