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
Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is traditionally generally responsible for at least one package, but according to their available time and desire, they are free to become involved in numerous teams and projects, thus acquiring more responsibilities within the project.
Package maintenance is a relatively regimented activity, very documented, or even regulated. It must, in effect, comply with all the standards established by the
Debian Policy. Fortunately, there are many tools that facilitate the maintainer's work. The developer can, thus, focus on the specifics of their package and on more complex tasks, such as “squashing“ bugs.
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.
Since its inception, the project has been successively led by 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, Jonathan Carter, and Andreas Tille.
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:
Even if this constitution establishes a semblance of democracy, the daily reality is quite different: Debian naturally follows the free software rules of the do-ocracy: the one who does things gets to decide how to do them. A lot of time can be wasted debating the respective merits of various ways to approach a problem; the chosen solution will be the first one that is both functional and satisfying… which will come out of the time that a competent person puts into it.
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".
This effective operational method guarantees the quality of contributors in the “key” Debian teams. This method is by no means perfect, and occasionally there are those who do not accept this way of operating. The selection of developers accepted in the teams may appear a bit arbitrary, or even unfair. Furthermore, not everybody has the same definition of the service expected from these teams. For some, it is unacceptable to have to wait eight days for inclusion of a new Debian package, while others will wait patiently for three weeks without a problem. As such, there are regular complaints from the disgruntled about the “quality of service” from some teams.
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
Users can also use the command line to send bug reports on a Debian package with the reportbug tool. It helps making sure the bug in question hasn't already been filed, thus preventing redundancy in the system. It reminds the user of the definitions of the severity levels, for the report to be as accurate as possible (the developer can always fine-tune these parameters later, if needed, e.g. using the bts command). It helps writing a complete bug report, without the user needing to know the precise syntax, by writing it and allowing the user to edit it. This report will then be sent via an e-mail server (by default, a remote one run by Debian, but reportbug can also use a local server).
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.
This email-based workflow is still popular, but it tends to be replaced by the usage of merge requests (or pull requests) whenever the software is hosted in a platform like GitHub or GitLab — and Debian is using GitLab on its salsa.debian.org server. On those systems, once you have created an account, you fork the repository, effectively creating a copy of the repository in your own account, and you can then clone that repository and push your own changes in it. 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, offering an appealing and easy to use Debian system for children;
Debian Edu, focused on the creation of a specialized distribution for the academic and educational world;
Debian Med, dedicated to the medical field;
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.
