Os resultados finais abundantes produzidos pelo projeto Debian derivam simultaneamente do trabalho na infraestrutura realizado pelos experientes desenvolvedores Debian, de trabalho individual ou coletivo dos desenvolvedores de pacotes Debian e dos comentários dos usuários.
1.3.1. Os Desenvolvedores Debian
Os desenvolvedores Debian tem várias responsabilidades, e como membros oficiais do projeto, eles têm grande influência na direção que o projeto toma. Um desenvolvedor Debian é geralmente responsável por pelo menos um pacote, mas de acordo com seu tempo disponível e vontade, eles são livres para se envolverem em numerosas equipes e projetos, adquirindo, assim, mais responsabilidades dentro do projeto.
Manutenção de pacotes é uma atividade relativamente organizada, muito documentada ou mesmo regulamentada. Deve, de fato, obedecer todas as normas estabelecidas pela
Política Debian. Felizmente, existem muitas ferramentas que facilitam o trabalho do mantenedor. O desenvolvedor pode, assim, se concentrar nas especificidades do seu pacote e em tarefas mais complexas, tais como correção de erros.
A política, um elemento essencial do Projeto Debian, estabelece as normas que asseguram a qualidade dos pacotes e interoperabilidade perfeita da distribuição. Graças a esta Política, o Debian permanece consistente apesar de seu tamanho gigantesco. Esta Política não é cláusula pétrea, mas continuamente evolui graças às propostas formuladas na lista de discussão
debian-policy@lists.debia.org. As alterações acordadas por todas as partes interessadas são aprovadas e aplicadas ao texto por um reduzido grupo de mantenedores que não têm qualquer responsabilidade editorial (eles somente incluem as modificações acordadas pelos desenvolvedores do Debian que são membros da lista acima referida). Você pode ler as propostas de alteração em andamento no sistema de rastreamento de erros:
A Política cobre muito bem os aspectos técnicos do empacotamento. O tamanho do projeto também levanta problemas organizacionais, que são tratados pela Constituição Debian, que estabelece uma estrutura e meios para tomada de decisão. Em outras palavras, um sistema formal de governança.
Esta constituição define alguns papéis e posições, além de responsabilidades e autoridades para cada um(a). É particularmente interessante notar que os(as) desenvolvedores (as) do Debian sempre têm a decisão definitiva tomada autoridade por uma votação de resolução geral, em que uma maioria qualificada de três quartos (75%) de votos é necessária para as alterações significativas a serem feitas (como aquelas com um impacto sobre os Documentos de Fundação). No entanto, os(as) desenvolvedores (as) anualmente elegem um(a) "líder" para representá-los(as) em reuniões, e assegurar a coordenação interna entre equipes diferentes. Esta eleição é sempre um período de intensas discussões. Este papel do(a) líder do Projeto Debian (
DPL) não é formalmente definido por qualquer documento: os(as) candidatos(as) para esse posto normalmente propõe sua própria definição da posição. Na prática, os papéis do(a) líder incluem servir como um(a) representante para os meios de comunicação, de coordenação entre equipes "internas" , e fornecer orientação geral para o projeto, dentro do qual os(as) desenvolvedores (as) podem se relacionar: as opiniões do(a) DPL são implicitamente aprovadas pela maioria dos(as) membros(as) do projeto .
Especificamente, o líder tem autoridade real; o voto dele resolve votações empatadas, ele pode tomar qualquer decisão que não esteja sob a autoridade de alguém e pode delegar parte das suas responsabilidades.
Desde a sua criação, o projeto foi sucessivamente liderado por Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman e Jonathan Carter.
A Constituição também define uma "comissão técnica". O papel essencial desta comissão é o de decidir sobre questões técnicas, quando os desenvolvedores envolvidos não chegaram a um acordo entre si. Caso contrário, esta comissão tem um papel consultivo para qualquer desenvolvedor que não consegue tomar uma decisão para o quai é responsável. É importante notar que eles só se envolvem quando convidados a fazê-lo por uma das partes em questão.
Finalmente, a Constituição define a posição de "secretário de projeto", que é responsável pela organização dos votos relacionados às várias eleições e resoluções gerais.
O procedimento de “resolução geral” (general resolution -
GR) é totalmente detalhado na constituição, desde o período de discussão inicial até a contagem final dos votos. O aspecto mais interessante desse processo é que, quando se trata de uma votação real, os(as) desenvolvedores (as) precisam classificar as diferentes opções de votação entre eles(as) e o(a) vencedor(a) é selecionado(a) com um
Método de Condorcet (mais especificamente, o método de Schulze). Para obter mais detalhes, consulte:
Embora esta constituição se assemelhe a uma aparente democracia, a realidade cotidiana é muito diferente: o Debian naturalmente segue as regras da meritocracia do software livre: quem faz as coisas decide como fazê-las. Muito tempo pode ser desperdiçado debatendo os méritos de várias formas de abordar um problema; a solução escolhida será a primeira que é funcional e satisfatória... que honrará o tempo que uma pessoa competente colocou nela.
Esta é a única maneira de obter reconhecimento: fazer algo de útil e mostrar que funciona bem. Muitas equipes "administrativas" Debian operam por cooptação, preferindo voluntários que já contribuíram efetivamente e provaram sua competência. A natureza pública do trabalho dessas equipes faz com que seja possível a observação e ajuda por parte de novos contribuintes, sem a necessidade de privilégios especiais. É por isso que o Debian é frequentemente descrito como uma "meritocracia".
Este efetivo método operacional garante a qualidade dos contribuidores nas equipes Debian "chave". Este método é de forma alguma perfeito e, ocasionalmente, há aqueles que não aceitam esta forma de operar. A seleção dos desenvolvedores aceitos nas equipes pode parecer um pouco arbitrária, ou mesmo injusta. Além disso, nem todo mundo tem a mesma definição do serviço esperado das equipes. Para alguns, é inaceitável ter que esperar oito dias para a inclusão de um pacote novo, enquanto outros vão esperar pacientemente por três semanas sem nenhum problema. Como tal, há queixas regulares a partir de descontentes com a "qualidade de serviço" de algumas equipes.
1.3.2. O Papel Ativo dos Usuários
Alguém pode se perguntar se é relevante mencionar os usuários entre aqueles que trabalham dentro do projeto Debian, mas a resposta é com certeza "sim". eles desempenham um papel fundamental no projeto. Longe de serem "passivos", alguns usuários executam versões de desenvolvimento do Debian e regularmente apresentam relatórios de bugs para indicar problemas. Outros vão ainda mais longe e apresentam ideias de melhorias, mediante a apresentação de um relatório de bug com um nível de gravidade "wishlist", ou mesmo apresentam correções no código fonte, chamadas de "patches" (remendos em português) (veja
Seção 1.3.2.3, “Enviando correções” ).
A ferramenta fundamental para submeter bugs no Debian é o Sistema de Rastreio de Bugs (Debian BTS) que é usado por muitas partes do projeto. A parte pública (a interface web) permite aos usuários visualizarem todos os bugs reportados, com a opção de mostrar uma lista ordenada de erros selecionados de acordo com vários critérios, tais como: pacote afetado, gravidade, estado, endereço do relator, endereço do mantenedor responsável, etiquetas, etc. Também é possível navegar pela lista completa do histórico de todas as discussões sobre cada um dos bugs.
Por dentro, o BTS Debian é baseado em e-mail: todas informações que armazena vêm de mensagens enviadas pelas pessoas envolvidas. Qualquer e-mail enviado para
12345@bugs.debian.org irá, portanto, ser atribuída à história de bug número 12345. Pessoas autorizadas podem "fechar" um erro ao escrever uma mensagem descrevendo as razões para a decisão de fechar o erro para
12345-done@bugs.debian.org (um bug é fechado quando o problema indicado foi resolvido ou não é mais relevante). Um novo bug é relatada através do envio de um e-mail para
submit@bugs.debian.org de acordo com um formato específico que identifica o pacote em questão. O endereço
control@bugs.debian.org permite a edição de todos as "meta-informações" relacionadas a um bug.
O BTS Debian tem outras características funcionais, tais como o uso de etiquetas para rotular erros. Para mais informações, consulte
Usuários(as) também podem usar a linha de comando para enviar relatórios de bugs em um pacote Debian com o comando reportbug. Ele ajuda ao garantir que o bug em questão ainda não foi preenchido, prevenindo assim redundância no sistema. Ele lembra o(a) usuário(a) da definição dos níveis de severidade para que o relatório seja tão preciso quanto possível (o(a) desenvolvedor(a) pode sempre ajustar esses parâmetros mais tarde, se necessário). Ele ajuda a escrever um relatório de bug completo sem que o(a) usuário(a) precise conhecer a sintaxe exata, escrevendo-o e permitindo que o(a) usuário(a) possa editá-lo. Este relatório será enviado através de um servidor de e-mail (por padrão, um servidor de e-mail remoto executado pelo Debian, mas o reportbug também pode usar um servidor local).
Esta ferramenta tem como primeiro alvo as versões de desenvolvimento, que é onde os bugs são corrigidos. Efetivamente, as mudanças não são bem-vindas na versão estável do Debian, com poucas exceções para as atualizações de segurança ou outras atualizações importantes (se, por exemplo, um pacote não funciona de forma alguma). A correção de um pequeno bug em um pacote Debian deve, portanto, esperar pela próxima versão estável.
1.3.2.2. Tradução e documentação
Além disso, inúmeros usuários satisfeitos do serviço oferecido pelo Debian gostariam de fazer uma contribuição própria para o projeto. Como nem todos tem níveis apropriados de experiência em programação, eles escolhem ajudar com a tradução e revisão de documentação. Há listas de discussão específicas para vários idiomas.
1.3.2.3. Enviando correções
Usuários mais avançados podem ser capazes de fornecer uma correção para um programa, enviando um patch.
Um patch é um arquivo que descreve mudanças a serem feitas a um ou mais arquivos de referência. Especificamente, ele irá conter uma lista de linhas a serem removidos ou adicionado ao código, bem como (por vezes) linhas tomadas a partir do texto de referência, substituindo as modificações no contexto (que permitem identificar o posicionamento das alterações, se os números de linha foram alterados).
O instrumento utilizado para aplicar as modificações em tal arquivo é simplesmente chamado de patch. A ferramenta que o cria é chamada diff, e é utilizada como se segue:
$ diff -u file.old file.new >file.patch
O arquivo file.patch contém as instruções para alterar o conteúdo do file.old em File.new . Podemos enviá-lo para alguém, que pode usá-lo para recriar File.new a partir dos outros dois, deste jeito:
$ patch -p0 file.old <file.patch
O arquivo file.old, é agora idêntico ao file.new.
Na prática, a maioria dos softwares é mantida em repositórios Git e os(as) contribuidores(as) são mais propensos a usar git para recuperar o código-fonte e propor mudanças. O git diff gerará um arquivo no mesmo formato que o diff -u faria e git apply pode fazer o mesmo que o patch.
Embora a saída de git diff seja um arquivo que pode ser compartilhado com outros desenvolvedores, geralmente existem maneiras melhores de enviar alterações. Se os desenvolvedores preferem receber patches por e-mail, eles geralmente querem patches gerados com git format-patch para que possam ser integrados diretamente no repositório com git am. Isso preserva as meta-informações dos commits e torna possível compartilhar vários commits de uma vez.
Este fluxo de trabalho baseado em email ainda é popular mas a tendência é que seja substituído pelo uso dos merge requests (ou pull requests) sempre que o software seja hospedado numa plataforma como GitHub ou GitLab — e o Debian está usando GitLab no seu servidor salsa.debian.org. Nestes sistemas, uma vez que você tenha criado uma conta, você faz um fork no repositório, efetivamente criando uma cópia do repositório na sua própria conta, e então você pode clonar este repositório e mandar suas próprias mudanças nele. From there, the web interface will suggest you to submit a merge request, notifying the developers of your changes, making it easy for them to review and accept your changes with a single click.
1.3.2.4. Outras formas de contribuir
Não só os usuários se ajudam entre si (e outros) com questões técnicas que afetam diretamente a eles, mas também discutem as melhores formas de contribuir para o projeto Debian e ajudá-lo a avançar - discussões que frequentemente resultam em sugestões para melhorias.
Já que o Debian não gasta fundos em todas campanhas de autopromoção de marketing, seus usuários têm um papel essencial na sua difusão, assegurando a sua fama através da propaganda boca a boca.
Este método funciona muito bem, uma vez que fãs do Debian são encontrados em todos os níveis da comunidade de software livre: a partir de festas de instalação (oficinas onde os usuários experientes ajudam os recém-chegados para instalar o sistema) organizados por
LUGs locais ou "Grupos de Usuários de Linux", para estandes de associação em grandes convenções que lidam com tecnologias como o Linux, etc.
Voluntários fazem cartazes, folhetos, adesivos e outros materiais promocionais úteis para o projeto, que colocam à disposição de todos, e que o Debian oferece gratuitamente em seu portal web e na sua wiki:
1.3.3. Equipes, Blends e subprojetos
Desde seu início, o Debian é organizado em torno do conceito de pacotes de pacotes-fonte, cada um com seu(sua) mantenedor(a) ou grupo de mantenedores(as). Numerosas equipes de trabalho lentamente apareceram, garantindo a administração da infraestrutura, gestão de tarefas que não são específicas de determinados pacotes (garantia de qualidade, Política Debian, instalador, etc.), com as últimas equipes crescendo ao redor dos subprojetos.
1.3.3.1. Subprojetos Debian atuais e Blends
Cada um com seu próprio Debian! Um subprojeto é um grupo de voluntários interessados em adaptar o Debian para necessidades específicas. Além da seleção de um subgrupo de programas destinados a um domínio particular (educação, medicina, criação multimídia, etc), os subprojetos estão também envolvidos em melhorar os pacotes existentes, empacotar software faltando, adaptar o instalador, criação de documentação específica, e mais. Embora um "blend" possa não ser exatamente a mesma coisa, seu funcionamento e bastante similar e também tenta fornecer uma solução para grupos de pessoas que pretendem usar o Debian para um domínio particular. Pode-se dizer que o "Debian Pure Blends" é o sucessor dos sub-projetos.
Aqui está uma pequena seleção de Debian Pure Blends lançados:
Debian Junior, por Ben Armstrong, que oferece um sistema Debian atraente e fácil de usar por crianças;
Debian Edu, por Petter Reinholdtsen, focada na criação de uma distribuição especializada para o mundo acadêmico e educacional;
Debian Med, por Andreas Tille, dedicada para o campo medicinal;
Debian Multimedia, que trata do trabalho de áudio e multimídia;
Debian GIS, que cuida de aplicações e usuários(as) de Sistemas de Informações Geográficas;
Debian Astro, para astrônomos(as) profissionais e amadores(as);
Debian Science, trabalhando para que pesquisadores(as) e cientistas tenham uma experiência melhor ao usar o Debian;
Freedombox, criado para desenvolver, projetar e promover servidores pessoais que executem software livre para comunicação privada e pessoal;
Debian Games, que oferece jogos no Debian, dos fliperamas às aventuras, até simulações e estratégias;
DebiChem, marcado em Chemistry ("química"), fornece programas e suites para química.
O número de projetos, muito provavelmente, continuará a crescer com o tempo e com a percepção das vantagens dos Debian Pure Blends. Totalmente suportados pela infraestrutura Debian existente , eles podem, com efeito, se concentrar no trabalho com valor acrescentado real, sem se preocupar em permanecer sincronizado com o Debian, uma vez que são desenvolvidos dentro do projeto.
1.3.3.2. Times Administrativos
A maioria das equipes administrativas são relativamente fechadas e recrutam só por co-optação. O melhor meio para se tornar parte de uma é inteligentemente auxiliar os atuais membros, demonstrando que você tenha entendido seus objetivos e métodos de operação.
O ftpmasters estão a cargo do repositório oficial dos pacotes Debian. Eles mantêm o programa que recebe pacotes enviados por desenvolvedores e automaticamente armazenam eles, depois de algumas verificações no servidor de referência ( ftp-master.debian.org ).
Eles devem igualmente verificar as licenças de todos os novos pacotes, a fim de assegurar que o Debian pode distribuí-los, antes da sua inclusão no corpo de pacotes existentes. Quando um desenvolvedor deseja remover um pacote, aborda esta equipe através do sistema de acompanhamento de bugs e o "pseudopacote" ftp.debian.org .
A equipe
Administradores de Sistema do Debian (
DSA) (
debian-admin@lists.debian.org), como se poderia esperar, é responsável pela administração do sistema de muitos servidores utilizados pelo projeto. Eles garantem o ótimo funcionamento de todos os serviços básicos (DNS, Web, e-mail, shell, etc), instalam o software solicitado por desenvolvedores Debian e tomam todas as precauções no que diz respeito à segurança.
A equipe listmasters administra o servidor de e-mail que gerencia as listas de discussão. Eles criam novas listas, tratam das quicadas (avisos de falha na entrega), e mantém os filtros de spam (massa não solicitada de e-mail).
Cada serviço específico tem sua própria equipe de administração, geralmente composta de voluntários que o instalaram (e também frequentemente programam as ferramentas correspondentes eles mesmos). Este é o caso para o sistema de acompanhamento de bugs (BTS), o rastreador de pacotes,
salsa.debian.org (servidor GitLab, consulte a barra lateral
FERRAMENTA GitLab. Hospedagem de repositórios Git e muito mais), os serviços disponíveis em
qa.debian.org,
lintian.debian.org,
buildd.debian.org,
cdimage.debian.org, etc.
1.3.3.3. Equipes de Desenvolvimento, Equipes Transversais
Diferente das equipes administrativas, as equipes de desenvolvimento são bem amplamente abertas, mesmo para os contribuintes de fora. Mesmo que se o Debian não tem vocação para criar um software, o projeto necessita de alguns programas específicos para atender seus objetivos. Claro, desenvolvido sob uma licença de software livre, essas ferramentas fazem uso de métodos comprovados em outras partes do mundo do software livre.
Debian desenvolveu poucos softwares por si só, mas certos programas têm assumido um papel importante, sua fama se espalhou para além escopo do projeto. Bons exemplos são dpkg, o programa de gerenciamento de pacotes do Debian (é, na verdade, uma abreviatura de Debian PacKaGe -- pacote do Debian), e apt, uma ferramenta para instalação automática de qualquer pacote Debian, e suas dependências, garantindo a coesão do sistema após a atualização (seu nome é uma sigla para Advanced Package Tool -- Ferramenta Avançada de Pacotes). Os seus times são, no entanto, muito pequenos, uma vez que um nível bastante elevado de habilidade de programação é necessária para a compreensão do conjunto de ações destes tipos de programas.
A equipe mais importante é provavelmente a do programa de instalação do Debian,
debian-installer, que realizou uma obra de proporções monumentais, desde a sua concepção em 2001. Vários colaboradores foram necessários, uma vez que é difícil escrever um único programa capaz de instalar o Debian em uma dúzia de diferentes arquiteturas. Cada um tem seu próprio mecanismo para inicialização e seu próprio bootloader. Todo este trabalho é coordenado na lista de discussão
debian-boot@lists.debian.org, sob a direção de Cyril Brulebois.
A (muito pequena) equipe do programa debian-cd tem um objetivo ainda mais modesto. Muitos "pequenos" colaboradores são responsáveis pela sua arquitetura, já que o principal desenvolvedor pode não saber todas as sutilezas, nem a forma exata para iniciar o instalador a partir do CD-ROM.
Muitas equipes devem colaborar com outras na atividade de empacotamento:
debian-qa@lists.debian.org tenta, por exemplo, garantir a qualidade em todos os níveis do projeto Debian. A equipe do lista do programa
debian-policy@lists.debian.org desenvolve A Política do Debian de acordo com propostas de todo o lugar. A equipe encarregada de cada arquitetura (
debian- arquitetura @ lists.debian.org ) compila todos os pacotes, adaptando-os à sua arquitetura particular, se necessário.
