Querida comunidade Debian,

Este é bits do DPL de abril.

Fim do 10

Tenho certeza de que estava falando no interesse de todo o projeto ao aderir à campanha "Fim do 10". Aqui está o que escrevi aos(as) iniciadores(as):

Olá, Joseph, e a todos(as) os(as) participantes da campanha "Fim do 10". Em nome de todo o projeto Debian, gostaria de dizer que nos juntamos com orgulho à sua grande campanha. Estamos com vocês na promoção do Software Livre, na defesa das liberdades dos(as) usuários(as) e na proteção do nosso planeta, evitando o desperdício desnecessário de hardware. Obrigado por liderarem esta iniciativa importante.

Andreas Tille Líder do Projeto Debian

Tenho algumas metas que gostaria de compartilhar com vocês para meu segundo mandato.

Delegação ftpmaster

Isso se divide em tarefas que podem ser feitas antes e depois do lançamento da Trixie.

Antes da Trixie:

⁣1. Reduzindo barreiras às verificações de conformidade do DFSG

Voltando em 2002, O Debian estabeleceu uma maneira de distribuir software criptográfico no repositório principal, enquanto este tipo de software era anteriormente restrito ao repositório não-US. Um resultado desse arranjo, que influencia nosso fluxo de trabalho, é que todos os pacotes enviados para a fila NEW devem permanecer no servidor que os hospeda. Esse requisito significa que membros da equipe ftpmaster devem efetuar login naquela máquina específica, onde estarão limitados(as) a um conjunto restrito de ferramentas para revisar o código enviado.

Essa configuração pode atuar como uma barreira à participação, principalmente para colaboradores(as) que, de outra forma, poderiam auxiliar na revisão de pacotes para garantir a conformidade com a DFSG. Acredito que é hora de reavaliar essa limitação e trabalhar para remover tais obstáculos.

Em outubro do ano passado, tivemos contato inicial com o consultor jurídico da SPI, que observou que as regulamentações americanas sobre criptografia foram um pouco flexibilizadas nos últimos anos (a partir de 2021). Isso sugere que agora pode ser possível revisitar e potencialmente revisar as condições sob as quais gerenciamos software criptográfico na fila NEW.

Pretendo investigar isso mais a fundo. Se você tem experiência em software ou em lei de controle de exportação e tem interesse em ajudar com este tópico, entre em contato comigo.

O objetivo final é facilitar a contribuição de mais pessoas para garantir que o código na fila NEW esteja em conformidade com o DFSG.

⁣2. Discutindo Alternativas

Minhas chances de entrar em contato com outras distribuições continuaram limitadas. No entanto, em relação ao processamento de novos softwares, descobri que o OpenSUSE usa um fluxo de trabalho baseado em Git que exige cinco aprovações "LGTM" de um grupo de desenvolvedores(as) confiáveis. Até onde sei, o Fedora segue uma abordagem semelhante.

Inspirado por isso, uma iniciativa comunitária recente -- o projeto Gateway to NEW — permite a revisão por pares de novos pacotes para verificar a conformidade com o DFSG antes que eles entrem na fila NEW. Esse esforço permite que qualquer pessoa contribua, revisando pacotes e sinalizando possíveis problemas com antecedência via Git. Eu particularmente aprecio o fato da revisão do DFSG ser acoplada ao CI, permitindo avaliação tanto da licença quanto da técnica.

Embora esse processo atualmente resulte em alguma duplicação de trabalho -- já que as revisões finais ainda são realizadas pela equipe do ftpmaster -- ele oferece uma oportunidade valiosa para detectar problemas antecipadamente e melhorar a qualidade geral dos uploads. Se a comunidade enxergar valor a longo prazo nessa abordagem, ela poderá servir de base para a evolução dos nossos fluxos de trabalho. Integrá-la mais estreitamente ao DAK poderia agilizar o processo, e recentemente vimos merge requests refletindo que as sugestões da comunidade podem ser aceitas prontamente.

Por enquanto, gostaria de coletar opiniões sobre como tais iniciativas poderiam complementar melhor o processamento atual do NEW e se um maior consenso sobre revisão por pares confiável poderia ajudar a reduzir a carga sobre a equipe que realiza as verificações de conformidade com o DFSG. Enviar pacotes para revisão e testes automatizados antes do upload pode melhorar a qualidade e incentivar uma participação mais ampla na proteção dos princípios de Software Livre do Debian.

Meus agradecimentos explícitos vão para a equipe do Gateway to NEW por sua valiosa e inovadora contribuição ao Debian.

⁣3. Documentando fluxos de trabalho críticos

Ex-alunos(as) do programa ftpmaster me disseram que entender o conjunto completo de fluxos de trabalho do ftpmaster pode ser bastante difícil. Embora exista alguma documentação útil – graças em particular a Sean Whitton por seu trabalho na documentação das Novas regras de processamento – muitas outras tarefas importantes realizadas pela equipe do ftpmaster permanecem sem ou parcialmente documentadas.

Uma documentação abrangente e acessível beneficiaria enormemente os atuais e futuros(as) integrantes da equipe, especialmente aqueles que integram ou auxiliam em fluxos de trabalho específicos. Também ajudaria a garantir a continuidade e a transparência na gestão de partes críticas do arquivo.

Se essa documentação já existir e eu simplesmente a tiver ignorado, ficarei feliz em ser corrigido. Caso contrário, acredito que esta é uma área em que precisamos melhorar significativamente. Voluntários(as) com talento para escrever documentação técnica são calorosamente convidados a entrar em contato comigo -- ficarei feliz em ajudar a estabelecer conexões com membros da equipe do ftpmaster que estejam dispostos a compartilhar seu conhecimento para que ele possa ser escrito e preservado.

Assim que Trixie for lançado (espero que antes da DebConf):

⁣4. ⁣Divisão da equipe Ftpmaster em equipes DFSG e Archive

Conforme discutido durante o BoF "Conheça a equipe do ftp" na DebConf24, gostaria de propor um refinamento estrutural da atual equipe do Ftpmaster, introduzindo duas equipes delegadas diferentes:

1. Equipe DFSG
2. Equipe Archive (responsável pela manutenção do DAK e ferramentas de processo, incluindo lançamentos)

(Sugestões de nomes alternativos são, obviamente, bem-vindas.) A principal tarefa da equipe do DFSG seria processar a fila NEW e garantir que os pacotes estejam em conformidade com o DFSG. A equipe do Archive se concentraria na manutenção do DAK e no gerenciamento dos aspectos técnicos do archive.

Estou ciente de que, recentemente, a equipe ftpmaster decidiu não buscar ativamente novos membros. Embora eu respeite a autonomia de cada equipe, a consequente falta de um processo de recrutamento gerou atritos e preocupações na comunidade em geral, incluindo a mim. Como Líder do Projeto Debian, é minha responsabilidade garantir a sustentabilidade e a resiliência a longo prazo do nosso projeto, o que inclui promover um ambiente onde novos(as) colaboradores(as) possam ingressar e as equipes existentes permaneçam eficazes e bem apoiadas. Portanto, mesmo que a equipe atual não priorize o recrutamento, buscarei e incentivarei ativamente novos(as) colaboradores(as) para ambas as equipes, com o objetivo de promover a abertura e a colaboração.

Esta proposta não pretende ser uma crítica à dedicação ou às conquistas da equipe atual, pelo contrário, sou grato pelo trabalho árduo e comprometimento demonstrados, muitas vezes em circunstâncias desafiadoras. Minha intenção é ajudar a resolver os problemas estruturais que dificultaram a integração e a especialização, e garantir que ambas as equipes tenham um bom suporte para o futuro.

Acredito também que ambas as equipes devem informar regularmente a comunidade Debian sobre as políticas e procedimentos que aplicam. Agradeço sugestões para uma descrição mais detalhada das tarefas envolvidas, bem como feedback sobre a melhor forma de implementar essa mudança de forma a promover a colaboração e a transparência.

Minha intenção com esta proposta é promover um ambiente de trabalho mais aberto e eficaz, e estou comprometido em trabalhar com todas as pessoas envolvidas para garantir que quaisquer mudanças sejam feitas de forma colaborativa e com respeito ao importante trabalho que já está sendo feito.

Estou ciente de que as ideias descritas acima abordam aspectos essenciais do funcionamento do Debian e envolvem responsabilidades entre diversas equipes. Essas não são mudanças pequenas, e implementá-las exigirá discussão e colaboração ponderadas.

Para levar isso adiante, registrei um BoF dedicado à DebConf. Para aproveitar ao máximo essa oportunidade, estou procurando voluntários(as) comprometidos(as) em aprimorar nossos fluxos de trabalho e processos. Com a sua ajuda, podemos preparar propostas concretas e sensatas com antecedência — para que o tempo limitado do BoF possa ser usado de forma eficaz para a tomada de decisões e a construção de consenso.

Resumindo: preciso da sua ajuda para concretizar essas mudanças. Pela minha experiência no meu último mandato, sei que, quando realmente importa, a comunidade Debian se une -- e confio que esse espírito nos guiará novamente.

Observe também: fizemos uma "Chamada para Voluntários(as)" há cinco anos, e muito do que foi escrito lá ainda se aplica hoje. Disseram-me que a resposta na época foi esmagadora, mas que treinar um número tão grande de voluntários(as) não teve boa escalabilidade. Desta vez, espero que possamos encontrar uma abordagem mais sustentável: treinar algumas pessoas dedicadas primeiro e, depois, capacitá-las a transmitir seus conhecimentos. Este também será um tópico no sprint do DebCamp.

Lidando com Pacotes Inativos

O Debian foi fundado com base no princípio de que cada software deve ser mantido por alguém com expertise no assunto -- normalmente um(a) único(a) mantenedor(a) responsável. Esse modelo formou a base histórica do sistema de empacotamento do Debian e ajudou a estabelecer altos padrões de qualidade e responsabilidade. No entanto, com o crescimento do projeto e a expansão do número de pacotes, esse modelo deixou de ser escalável em todas as áreas. A manutenção em equipe surgiu desde então como um complemento prático, permitindo que vários(as) colaboradores(as) compartilhem responsabilidades e reduzam gargalos -- dependendo da política interna de cada equipe.

Enquanto trabalhava na iniciativa Bug do Dia, observei um número significativo de pacotes que não eram atualizados há muito tempo. No caso de pacotes mantidos pela equipe, resolver isso costuma ser simples: uploads podem ser feitos pela equipe ou a equipe pode ser questionada se o pacote deve ser removido. Também identificamos muitos pacotes que se encaixariam bem no escopo de equipes ativas, como as equipes de linguagens como Debian Perl e Debian Python, ou de blends como Debian Games e Debian Multimedia. Muitas vezes, ninguém toma providências -- não por discordância, mas simplesmente por desatenção ou falta de iniciativa.

Além disso, encontramos vários pacotes que provavelmente deveriam ser removidos completamente. Nesses casos, registramos bugs com avisos de pré-remoção, que posteriormente podem ser transformados em solicitações de remoção.

Quando um pacote ainda é mantido formalmente por uma pessoa, mas mostra sinais de negligência (por exemplo, nenhum upload por anos, bugs RC não corrigidos, autopkgtests com falhas), atualmente temos três ferramentas principais:

1. O processo MIA, que lida com mantenedores(as) inativos(as) ou inacessíveis.
2. Recuperação de Pacotes, que permite que os(as) contribuidores(as) assumam a manutenção se as condições forem atendidas.
3. Uploads de Não Mantenedores(as) (NMUs), que se limitam a correções específicas e bem definidas (que não incluem coisas como migração para o Salsa).

Esses mecanismos são importantes e valiosos, mas nem sempre nos permitem reagir com rapidez ou abrangência suficientes. Nossas ferramentas para identificar pacotes que efetivamente não são mantidos são relativamente fracas, e os limites para a tomada de medidas costumam ser altos.

A equipe de Recuperação de Pacotes está testando um processo que chamamos provisoriamente de "Intend to NMU" (ITN). O nome é questionável -- alguns sugeriram alternativas como "Intent to Orphan" -- e a discussão sobre isso está em andamento no debian-devel. O mecanismo se destina a situações em que os pacotes parecem inativos, mas ainda não estão formalmente órfãos, introduzindo um período de aviso prévio de 21 dias antes das NMUs, semelhante em espírito ao processo ITS existente. A discussão gerou sugestões para expandir as regras de NMU.

Embora seja crucial não minar a autonomia dos(as) mantenedores(as) que permanecem ativamente envolvidos(as), também não devemos permitir que uma interpretação estrita dessa autonomia bloqueie as melhorias necessárias em pacotes obviamente negligenciados.

Para ser claro: não proponho alterar os direitos dos(as) mantenedores(as) que são claramente ativos(as) e investem em seus pacotes. Esse modelo tem nos servido bem. No entanto, também devemos ser honestos quanto ao fato de que, em alguns casos, os(as) mantenedores(as) param de contribuir -- silenciosamente e sem planos de transição. Nessas situações, precisamos de procedimentos mais ágeis e escaláveis ​​para manter os altos padrões do Debian.

Para isso, registrei uma sessão BoF na DebConf25 para discutir possíveis melhorias na forma como lidamos com pacotes inativos. Essas discussões serão preparadas durante um sprint no DebCamp, onde espero trabalhar com outros(as) desenvolvedores(as) em ideias concretas.

Entre os tópicos que quero revisitar está a minha proposta de novembro passado no debian-devel, intitulada "Barreiras entre pacotes e outras pessoas". Embora o tópico tenha gerado uma discussão substancial, compreensivelmente não levou a um consenso. Pretendo garantir que os vários pontos de vista sejam resumidos de forma justa -- de preferência por alguém com uma postura mais neutra do que eu -- e, se possível, trabalhar em uma proposta formal durante o sprint do DebCamp para apresentar no DebConf BoF.

Minha esperança é que possamos chegar a um acordo sobre mecanismos que nos permitam agir de forma mais eficaz em situações em que voluntários(as), antes muito ativos(as), por algum motivo, se afastaram. Dessa forma, podemos proteger tanto a qualidade do Debian quanto seu espírito colaborativo.

Construindo Financiamento Sustentável para o Debian

O Debian incorre em despesas contínuas para dar suporte à sua infraestrutura -- especialmente manutenção e atualizações de hardware -- bem como para financiar reuniões presenciais como sprints e mini-DebConfs. Esses investimentos são essenciais para o nosso sucesso contínuo: eles permitem uma colaboração produtiva e garantem a robustez do sistema operacional que fornecemos aos(as) usuários(as) e distribuições derivadas em todo o mundo.

Embora a DebConf se beneficie de patrocínios generosos e recebamos regularmente doações de hardware, ainda há espaço considerável para aumentar nossa base financeira — especialmente para apoiar atividades menos visíveis, mas igualmente críticas. Um dos principais objetivos é estabelecer um fluxo de receita mais constante e previsível, ajudando o Debian a planejar com antecedência e responder com mais flexibilidade às necessidades emergentes.

Isso representa uma excelente oportunidade para colaboradores(as) que podem não estar envolvidos em desenvolvimento técnico ou de pacotes. Muitos de nós no Debian somos engenheiros(as) em primeiro lugar -- e arrecadar fundos não é algo para o qual fomos treinados. Mas, assim como o trabalho técnico, construir financiamento sustentável exige expertise e engajamento de longo prazo.

Se você é apaixonado por Software Livre e tem experiência com captação de recursos, captação de doadores, aquisição de patrocínios ou estratégia de desenvolvimento para organizações sem fins lucrativos, valorizamos muito sua ajuda. Apoiar o Debian não significa necessariamente escrever código. Ajudar-nos a construir uma base financeira estável e confiável é igualmente importante- - e pode ter um impacto duradouro.

Atenciosamente Andreas.

PS: Em abril, eu também plantei minha 5000ª árvore e embora seja um off-topic, eu tenho orgulho de compartilhar esta informação com meus amigos do Debian.