                  Um modelo de projeto para o projeto FreeBSD

  Niklas Saers

   Revisao: 40d8d3ce3a

   Copyright (c) 2002-2005 Niklas Saers

   Historico de Revisoes             
   Revisao 1.5                       October, 2014                            
   Remove mention of GNATS which is no longer used by the project.
   Revisao 1.4                       September, 2013                          
   Remove mention of CVS and CVSup which are no longer used by the project.
   Revisao 1.3                       October, 2012                            
   Removido func,oes de pessoas especificas, isso e documentado em outro
   lugar.                            
   Revisao 1.2                       April, 2005                              
   Update one year of changes, replace statistics with those of 2004
   Revisao 1.1                       July, 2004                               
   First update within the FreeBSD tree
   Revisao 1.0                       December 4th, 2003                       
   Ready for commit to FreeBSD Documentation
   Revisao 0.7                       April 7th, 2003                          
   Release for review by the Documentation team
   Revisao 0.6                       March 1st, 2003                          
   Incorporated corrections noted by interviewees and reviewers
   Revisao 0.5                       February 1st, 2003                       
   Initial review by interviewees    

   [ Documento HTML em partes / Documento HTML completo ]

     ----------------------------------------------------------------------

   Indice

   Prefacio

   1. Visao geral

   2. Definic,oes

                2.1. Atividade

                2.2. Processo

                2.3. Hat (Definic,ao/func,ao especifica para algumas pessoas)

                2.4. Resultado

                2.5. FreeBSD

   3. Estrutura organizacional

   4. Modelo de metodologia

                4.1. Modelo de desenvolvimento

                4.2. Lanc,amento de versoes (Release branches)

                4.3. Resumo do modelo

   5. Hats (Func,oes)

                5.1. Hats Universais

                5.2. Hats oficiais (Pessoas com func,oes definidas)

                5.3. Hats dependentes de processo

   6. Processos

                6.1. Adicionando novos committers e removendo committers
                antigos

                6.2. Enviando codigo para o projeto (Committing code)

                6.3. Eleic,ao do Core

                6.4. Desenvolvimento de novos recursos

                6.5. Manutenc,ao

                6.6. Relatorio de Problemas

                6.7. Reagindo ao mau comportamento

                6.8. Engenharia de Release (Versao)

   7. Ferramentas

                7.1. Subversion (SVN)

                7.2. Bugzilla

                7.3. Mailman

                7.4. Pretty Good Privacy

                7.5. Secure Shell

   8. Sub-projetos

                8.1. Subprojeto Ports

                8.2. O projeto de documentac,ao do FreeBSD

   Referencias

   Lista de Figuras

   3.1. A estrutura do projeto FreeBSD

   3.2. A estrutura do Projeto FreeBSD com committers em categorias

   4.1. O modelo de Jo/rgenssen para integrac,ao de mudanc,as

   4.2. A arvore de versoes (release) do FreeBSD

   4.3. O modelo geral de desenvolvimento

   5.1. Visao geral dos hats (func,oes) oficiais

   6.1. Resumo do processo: adicionando um novo committer

   6.2. Resumo do processo: removendo um committer

   6.3. Resumo do processo: um committer aplica o codigo

   6.4. Resumo do processo: um colaborador envia o codigo

   6.5. Resumo do processo: Eleic,oes do Core

   6.6. O modelo de Jo/rgenssen para integrac,ao de mudanc,as

   6.7. Resumo do processo: Relatorio de Pproblemas

   6.8. Resumo do processo: engenharia de release

   8.1. Numero de ports adicionados entre 1996 e 2005

                                    Prefacio

   Ate agora, o projeto FreeBSD lanc,ou varias tecnicas descritas para fazer
   diferentes partes do trabalho. No entanto, um modelo de projeto resumindo
   como o projeto e estruturado e necessario devido `a quantidade crescente
   de membros do projeto. [1] Este artigo fornecera esse modelo de projeto e
   sera doado ao projeto de Documentac,ao do FreeBSD, onde ele podera evoluir
   junto com o projeto, de modo que ele possa, a qualquer momento, refletir a
   maneira como o projeto funciona. E baseado em [Saers, 2003].

   Gostaria de agradecer `as pessoas a seguir por dedicarem tempo para
   explicar coisas que nao estavam claras para mim e por revisar o documento.

     * Andrey A. Chernov <ache@freebsd.org>

     * Bruce A. Mah <bmah@freebsd.org>

     * Dag-Erling Smo/rgrav <des@freebsd.org>

     * Giorgos Keramidas<keramida@freebsd.org>

     * Ingvil Hovig <ingvil.hovig@skatteetaten.no>

     * Jesper Holck<jeh.inf@cbs.dk>

     * John Baldwin <jhb@freebsd.org>

     * John Polstra <jdp@freebsd.org>

     * Kirk McKusick <mckusick@freebsd.org>

     * Mark Linimon <linimon@freebsd.org>

     * Marleen Devos

     * Niels Jo/rgenssen<nielsj@ruc.dk>

     * Nik Clayton <nik@freebsd.org>

     * Poul-Henning Kamp <phk@freebsd.org>

     * Simon L. Nielsen <simon@freebsd.org>

     ----------------------------------------------------------------------

   [1] Isso vai de maos dadas com a lei de Brooks onde "adicionar outra
   pessoa a um projeto atrasado ira atrasa-lo ainda mais" pois ira aumentar
   as necessidades de comunicac,ao Brooks, 1995. Um modelo de projeto e uma
   ferramenta para reduzir as necessidades de comunicac,ao.

                            Capitulo 1. Visao geral

   Um modelo de projeto e um meio de reduzir a sobrecarga de comunicac,oes em
   um projeto. Conforme mostrado por [Brooks, 1995], aumentar o numero de
   participantes do projeto aumenta exponencialmente a comunicac,ao no
   projeto. O FreeBSD tem aumentado nos ultimos anos tanto sua massa de
   usuarios ativos quanto de committers, e a comunicac,ao no projeto aumentou
   de acordo com esse crescimento. Esse modelo de projeto servira para
   reduzir essa sobrecarga, fornecendo uma descric,ao atualizada do projeto.

   Durante as eleic,oes do Core em 2002, Mark Murray declarou: "Me oponho a
   um longo livro de regras, pois isso satisfaz tendencias de advogados e e
   contrario ao tecnocentrismo de que o projeto tanto necessita." [FreeBSD,
   2002B]. Este modelo de projeto nao pretende ser uma ferramenta para
   justificar a criac,ao de imposic,oes para desenvolvedores, mas como uma
   ferramenta para facilitar a coordenac,ao. Isso tem significado como uma
   descric,ao do projeto, com uma visao geral de como os diferentes processos
   sao executados. E uma introduc,ao ao funcionamento do projeto FreeBSD.

   O modelo do projeto FreeBSD sera descrito a partir de 1-o de julho de
   2004. E baseado no paper de Niels Jo/rgensen [Jo/rgensen, 2001],
   documentos oficiais do FreeBSD, discussoes em listas de discussao do
   FreeBSD e entrevistas com os desenvolvedores.

   Depois de fornecer as definic,oes dos termos usados, este documento
   delineara a estrutura organizacional (incluindo descric,oes de func,oes e
   linhas de comunicac,ao), discutira o modelo de metodologia e, depois de
   apresentar as ferramentas usadas para controle de processos, apresentara
   os processos definidos. Finalmente, ele delineara os principais
   subprojetos do projeto FreeBSD.

   [FreeBSD, 2002A, Sec,ao 1.2 e 1.3] fornece a visao e as diretrizes
   arquitetonicas do projeto. A visao e "Produzir o melhor pacote de sistema
   operacional semelhante ao UNIX, respeitando a ideologia das ferramentas de
   software originais, bem como usabilidade, desempenho e estabilidade." As
   diretrizes de arquitetura ajudam a determinar se um problema que alguem
   quer que seja resolvido esta dentro do escopo do projeto

                            Capitulo 2. Definic,oes

   Indice

   2.1. Atividade

   2.2. Processo

   2.3. Hat (Definic,ao/func,ao especifica para algumas pessoas)

   2.4. Resultado

   2.5. FreeBSD

2.1. Atividade

   Uma "atividade" e um elemento do trabalho realizado durante o curso de um
   projeto [PMI, 2000]. Ele tem uma saida e leva a um resultado. Tal saida
   pode ser uma entrada para outra atividade ou parte da entrega do processo.

2.2. Processo

   Um "processo" e uma serie de atividades que levam a um resultado
   especifico. Um processo pode consistir em um ou mais subprocessos. Um
   exemplo de um processo e o design de software.

2.3. Hat (Definic,ao/func,ao especifica para algumas pessoas)

   Uma "hat" e um sinonimo de func,ao. Uma hat tem certas responsabilidades
   em um processo e para o resultado do processo. O hat executa atividades.
   Esta bem definido por quais problemas o hat deve ser contatado pelos
   membros do projeto e pessoas fora do projeto.

2.4. Resultado

   Um "resultado" e a finalizac,ao do processo. Isso e sinonimo de entrega,
   que e definido como "qualquer finalizac,ao mensuravel, tangivel,
   verificavel ou item que deve ser produzido para concluir um projeto ou
   parte de um projeto. Frequentemente usado de forma mais restrita em
   referencia a uma entrega externa, que e uma entrega sujeita `a aprovac,ao
   do patrocinador ou cliente do projeto", por [PMI, 2000]. Exemplos de
   resultados sao um software, uma decisao tomada ou um relatorio escrito.

2.5. FreeBSD

   Ao dizer "FreeBSD" queremos dizer o sistema operacional FreeBSD derivativo
   do BSD semelhante ao UNIX, enquanto ao dizer "o projeto FreeBSD" queremos
   dizer a organizac,ao do projeto.

                      Capitulo 3. Estrutura organizacional

   Enquanto ninguem assume a propriedade do FreeBSD, a organizac,ao do
   FreeBSD e dividida em core, committers e colaboradores e isso faz parte da
   comunidade do FreeBSD que vive em torno dele.

   Figura 3.1. A estrutura do projeto FreeBSD
   A estrutura do projeto FreeBSD

   O numero de committers foi determinado passando pelos logs do CVS de 1-o
   de janeiro de 2004 a 31 de dezembro de 2004 e pelos colaboradores,
   passando pela lista de contribuic,oes e relatorios de problemas.

   O principal recurso na comunidade do FreeBSD sao seus desenvolvedores: os
   committers e colaboradores. E com suas contribuic,oes que o projeto pode
   avanc,ar. Desenvolvedores regulares sao referidos como colaboradores. Ate
   1-o de janeiro de 2003, havia uma estimativa de 5500 colaboradores no
   projeto.

   Os committers sao desenvolvedores com o privilegio de poder aplicar
   mudanc,as (fazer commit). Geralmente, sao os desenvolvedores mais ativos
   que estao dispostos a gastar seu tempo nao apenas integrando seu proprio
   codigo, mas integrando o codigo enviado pelos desenvolvedores que nao tem
   esse privilegio. Eles tambem sao os desenvolvedores que elegem a equipe
   principal (core) e tem acesso a discussoes fechadas.

   O projeto pode ser agrupado em quatro partes separadas distintas, e a
   maioria dos desenvolvedores focara seu envolvimento em uma parte do
   FreeBSD. As quatro partes sao desenvolvimento de kernel, desenvolvimento
   de userland, ports e documentac,ao. Ao se referir ao sistema base, nos
   referimos tanto o kernel quanto o userland.

   Esta divisao muda nosso triangulo para ficar assim:

   Figura 3.2. A estrutura do Projeto FreeBSD com committers em categorias
   A estrutura do Projeto FreeBSD com committers em categorias

   O numero de committers por area foi determinado passando por logs do CVS
   de 1 de janeiro de 2004 a 31 de dezembro de 2004. Observe que muitos
   committers trabalham em varias areas, fazendo com que o numero total seja
   maior que o numero real de committers. O numero total de committers
   naquele momento era 269.

   Os committers se enquadram em tres grupos: committers que estao
   preocupados apenas com uma area do projeto (por exemplo, sistemas de
   arquivos), committers que estao envolvidos apenas com um subprojeto e
   committers que se comprometem com partes diferentes do codigo, incluindo
   subprojetos. Como alguns committers trabalham em partes diferentes, o
   numero total na sec,ao commiters do triangulo e maior que no triangulo
   acima.

   O kernel e o principal bloco de construc,ao do FreeBSD. Enquanto os
   aplicativos em userland sao protegidos contra falhas em outros aplicativos
   do userland, todo o sistema e vulneravel a erros no kernel. Isso,
   combinado com a grande quantidade de dependencias no kernel e que nao e
   facil ver todas as consequencias de uma mudanc,a no kernel, exige que os
   desenvolvedores tenham uma compreensao relativamente completa do kernel.
   Multiplos esforc,os de desenvolvimento no kernel tambem requerem uma
   coordenac,ao mais proxima do que os aplicativos em userland requerem.

   Os principais utilitarios, conhecidos como userland, fornecem a interface
   que identifica o FreeBSD, interface do usuario, bibliotecas compartilhadas
   e interfaces externas para conectar clientes. Atualmente, 162 pessoas
   estao envolvidas no desenvolvimento e manutenc,ao da userland, muitas
   delas sendo mantenedoras de sua propria parte do codigo. A manutenc,ao
   sera discutida na sec,ao Maintainership.

   A documentac,ao e tratada por The FreeBSD Documentation Project e inclui
   todos os documentos em torno do projeto FreeBSD, incluindo as paginas web.
   Durante o ano de 2004, 101 pessoas fizeram commits para o Projeto de
   Documentac,ao do FreeBSD.

   Ports e a colec,ao de meta-dados necessarios para fazer com que os pacotes
   de software sejam compilados corretamente no FreeBSD. Um exemplo de port e
   o port do navegador Mozilla. Ele contem informac,oes sobre onde buscar o
   codigo fonte, quais correc,oes aplicar e como o pacote deve ser instalado
   no sistema. Isso permite que ferramentas automatizadas busquem, criem e
   instalem o pacote. Ate esta data, existem mais de 12600 ports disponiveis.
   [2], variando de servidores web a jogos, linguagens de programac,ao e a
   maioria dos tipos de aplicativos que estao em uso em computadores
   modernos. Os ports serao discutidos em mais detalhes na sec,ao The Ports
   Subproject.

     ----------------------------------------------------------------------

   [2] As estatisticas sao geradas contando o numero de entradas no arquivo
   buscado pelo portsdb ate 1 de abril de 2005. portsdb e uma parte do port
   sysutils/portupgrade.

                       Capitulo 4. Modelo de metodologia

   Indice

   4.1. Modelo de desenvolvimento

   4.2. Lanc,amento de versoes (Release branches)

   4.3. Resumo do modelo

4.1. Modelo de desenvolvimento

   Nao existe um modelo definido para como as pessoas escrevem codigo no
   FreeBSD. No entanto, Niels Jo/rgenssen sugeriu um modelo de como o codigo
   escrito e integrado ao projeto.

   Figura 4.1. O modelo de Jo/rgenssen para integrac,ao de mudanc,as
   O modelo de Jo/rgenssen para integrac,ao de mudanc,as

   A "versao de desenvolvimento" e a branch (ramificac,ao) FreeBSD-CURRENT
   ("-CURRENT") e a "versao de produc,ao " e a branch (ramificac,ao)
   FreeBSD-STABLE ("-STABLE") [Jo/rgensen, 2001].

   Este e um modelo para uma mudanc,a e mostra que, apos a codificac,ao, os
   desenvolvedores buscam a revisao da comunidade e tentam integra-la com
   seus proprios sistemas. Depois de integrar a mudanc,a na versao de
   desenvolvimento, chamada FreeBSD-CURRENT, ela e testada por muitos
   usuarios e desenvolvedores na comunidade FreeBSD. Depois de passar por
   testes suficientes, e feito o merge (aplicado) na versao de produc,ao,
   chamada FreeBSD-STABLE. A menos que cada estagio seja concluido com exito,
   o desenvolvedor precisa voltar e fazer modificac,oes no codigo e reiniciar
   o processo. Integrar uma mudanc,a com -CURRENT ou -STABLE e chamado de
   fazer um commit.

   Jo/rgensen descobriu que a maioria dos desenvolvedores do FreeBSD trabalha
   individualmente, o que significa que este modelo e usado em paralelo por
   muitos desenvolvedores nos diferentes esforc,os de desenvolvimento em
   andamento. Um desenvolvedor tambem pode estar trabalhando em varias
   alterac,oes, de modo que, enquanto ele aguarda revisao ou que pessoas
   testem uma ou mais de suas alterac,oes, ele pode estar escrevendo outra
   alterac,ao.

   Como cada commit representa um incremento, este e um modelo massivamente
   incremental. Os commits sao tao frequ:entes que durante um ano [3], 85427
   commits foram feitos, fazendo uma media diaria de 233 commits.

   Dentro do processo "code" na figura de Jo/rgensen, cada programador tem
   seu proprio estilo de trabalho e segue seus proprios modelos de
   desenvolvimento. O suporte poderia muito bem ter sido chamado de
   "desenvolvimento", pois inclui coleta e analise de requisitos, sistema e
   projeto detalhados, implementac,ao e verificac,ao. No entanto, a unica
   saida desses estagios e o codigo-fonte ou a documentac,ao do sistema.

   Da perspectiva de um modelo em etapas (como o modelo em cascata), os
   outros suportes podem ser vistos como verificac,ao adicional e integrac,ao
   do sistema. Essa integrac,ao do sistema tambem e importante para ver se
   uma alterac,ao e aceita pela comunidade. Ate que o codigo seja
   "committed", o desenvolvedor e livre para escolher quanto se deve
   comunicar sobre o restante do projeto. Para que o -CURRENT funcione como
   um buffer (para que as ideias brilhantes que tinham algumas desvantagens
   nao descobertas possam ser recuperadas), o tempo minimo que um "commit"
   deve estar no -CURRENT antes de fazer o merge (aplicar o codigo) para
   -STABLE e de 3 dias. Esse merge (aplicac,ao) e referido como um MFC (Merge
   From Current).

   E importante notar a palavra "change (mudanc,a)". A maioria dos commits
   nao contem novos recursos radicais, mas sao atualizac,oes de manutenc,ao.

   As unicas excec,oes desse modelo sao correc,oes de seguranc,a e
   alterac,oes nos recursos que estao obsoletos na branch (ramificac,ao)
   -CURRENT. Nesses casos, as alterac,oes podem ser "committed" diretamente
   na branch -STABLE.

   Alem de muitas pessoas trabalhando no projeto, ha muitos projetos
   relacionados ao Projeto FreeBSD. Estes sao projetos desenvolvendo novos
   recursos, subprojetos ou projetos cujo resultado e incorporado ao FreeBSD
   [4]. Esses projetos se encaixam no Projeto FreeBSD, assim como os
   esforc,os regulares de desenvolvimento: eles produzem codigo que sao
   integrados ao Projeto FreeBSD. No entanto, alguns deles (como Ports e
   Documentac,ao) tem o privilegio de serem aplicaveis &#8203;&#8203;`as duas
   branchs (ramificac,oes) ou de commit diretamente na -CURRENT e na -STABLE.

   Nao ha padroes para como o design deve ser feito, nem o design e coletado
   em um repositorio centralizado. O design principal e o do 4.4BSD. [5] Como
   o design e parte do processo "Code (Codigo)" no modelo de Jo/rgenssen,
   cabe a cada desenvolvedor ou sub-projeto como isso deve ser feito. Mesmo
   que o projeto deva ser armazenado em um repositorio central, a saida dos
   estagios do projeto seria de uso limitado, pois as diferenc,as de
   metodologias as desvalorizariam se de alguma forma interoperaveis. Para o
   design geral do projeto, o projeto conta com os subprojetos para negociar
   interfaces adequadas entre si, em vez de ditar interfaces.

4.2. Lanc,amento de versoes (Release branches)

   Os lanc,amentos do FreeBSD sao melhor ilustrados por uma arvore com muitas
   branches (ramificac,oes), onde cada branch principal representa uma versao
   principal. Versoes secundarias sao representadas por branches das branches
   maiores.

   Na arvore de versoes a seguir, as setas que seguem uma a outra em uma
   determinada direc,ao representam uma branch. Caixas com linhas completas e
   encorporadas representam lanc,amentos oficiais. Caixas com linhas
   pontilhadas representam a branch de desenvolvimento nesse momento. Branchs
   de seguranc,a sao representadas por ovais. As encorporadas diferem das
   caixas em que representam um fork, definindo um lugar onde uma branch se
   divide em duas branchs, onde uma das branches se tornam uma sub-branch
   (sub ramificac,ao). Por exemplo, em 4.0-RELEASE, a branch 4.0-CURRENT e
   dividida em 4-STABLE e 5.0-CURRENT. No 4.5-RELEASE, a branch retirou uma
   branch de seguranc,a chamada RELENG_4_5.

   Figura 4.2. A arvore de versoes (release) do FreeBSD
   A arvore de versoes (release) do FreeBSD

   A ultima versao -CURRENT e sempre referida como -CURRENT, enquanto a
   versao mais recente -STABLE e sempre referida como -STABLE. Nessa figura,
   -STABLE se refere a 4-STABLE, enquanto -CURRENT refere-se a 5.0-CURRENT
   seguindo para 5.0-RELEASE. [FreeBSD, 2002E]

   Um "lanc,amento principal" e sempre feito a partir da branch -CURRENT. No
   entanto, a branch -CURRENT nao precisa ser feito fork nesse momento, mas
   pode concentrar-se na estabilizac,ao. Um exemplo disso e que, apos
   3.0-RELEASE, 3.1-RELEASE tambem era uma continuac,ao da branch -CURRENT, e
   -CURRENT nao se tornou uma branch de desenvolvimento verdadeira ate que
   esta versao fosse lanc,ada e fosse feito o fork da branch 3-STABLE. Quando
   -CURRENT retorna para se tornar uma branch de desenvolvimento, ele so pode
   ser seguido por um lanc,amento principal. Preve-se que seja feito o fork
   do 5-STABLE a partir da branch 5.0-CURRENT em torno da 5.3-RELEASE. Nao e
   feito ate que seja feito o fork da 5-STABLE, entao a branch de
   desenvolvimento sera marcada como 6.0-CURRENT.

   Uma "versao secundaria" e feita a partir da branch -CURRENT apos uma
   versao principal ou da branch -STABLE.

   Seguindo e incluindo, 4.3-RELEASE [6], quando uma liberac,ao secundaria
   foi feita, ela se torna uma "branch de seguranc,a". Isso se destina a
   organizac,oes que nao desejam seguir a branch -STABLE e os possiveis
   recursos novos/alterados que oferece, mas que exigem um ambiente
   absolutamente estavel, atualizando apenas para implementar atualizac,oes
   de seguranc,a. [7]

   Cada atualizac,ao para uma branch de seguranc,a e chamada de "patchlevel
   (`a nivel de correc,ao)". Para cada aprimoramento de seguranc,a que e
   feito, o numero de patchlevel e aumentado, tornando mais facil para as
   pessoas rastrearem a branch para ver quais melhorias de seguranc,a
   implementaram. Nos casos em que houve falhas graves de seguranc,a, uma
   nova versao inteira pode ser feita a partir de uma branch de seguranc,a.
   Um exemplo disso e a 4.6.2-RELEASE.

4.3. Resumo do modelo

   Para resumir, o modelo de desenvolvimento do FreeBSD pode ser visto como a
   seguinte arvore:

   Figura 4.3. O modelo geral de desenvolvimento
   O modelo geral de desenvolvimento

   A arvore do desenvolvimento do FreeBSD com esforc,os continuos de
   desenvolvimento e integrac,ao continua.

   A arvore simboliza as versoes de lanc,amento com versoes principais
   gerando novas branchs principais e versoes secundarias sendo versoes da
   branch principal. A branch superior e a branch -CURRENT, onde todo o
   desenvolvimento novo e integrado, e a branch -STABLE e a branch
   diretamente abaixo dela.

   Nuvens de esforc,os de desenvolvimento pairam sobre o projeto, onde os
   desenvolvedores usam os modelos de desenvolvimento que eles acham
   adequados. O produto de seu trabalho e entao integrado em -CURRENT, onde
   ele e depurado paralelamente e finalmente e feito o merge (aplicado o
   codigo) do -CURRENT na -STABLE. As correc,oes de seguranc,a sao feitos os
   merges (aplicado os codigos) da -STABLE para as branches de seguranc,a.

     ----------------------------------------------------------------------

   [3] O periodo de 1-o de janeiro de 2004 a 31 de dezembro de 2004 foi
   examinado para encontrar esse numero.

   [4] Por exemplo, o desenvolvimento da pilha Bluetooth comec,ou como um
   subprojeto ate ser considerada estavel o suficiente para ser feito o merge
   (aplicado) na branch -CURRENT. Agora e parte do sistema principal do
   FreeBSD.

   [5] De acordo com Kirk McKusick, depois de 20 anos desenvolvendo sistemas
   operacionais UNIX, as interfaces sao, na maioria das vezes, resolvidas.
   Portanto, nao ha necessidade de muito design. No entanto, novas
   aplicac,oes do sistema e novo hardware levam a algumas implementac,oes
   sendo mais beneficas do que aquelas que costumavam ser ter preferencia. Um
   exemplo e a introduc,ao da navegac,ao Web que tornou a conexao TCP/IP
   normal uma sequencia curta de dados, em vez de um fluxo continuo durante
   um periodo de tempo mais longo.

   [6] A primeira versao onde isso aconteceu foi na 4.5-RELEASE, mas as
   branches de seguranc,a foram criadas ao mesmo tempo para 4.3-RELEASE e
   4.4-RELEASE.

   [7] Existe uma terminologia que se sobrepoe `a palavra "stable (estavel)",
   o que leva a alguma confusao. A branch -STABLE ainda e uma branch de
   desenvolvimento, cujo objetivo e ser util para a maioria das pessoas. Se
   nunca for aceitavel que um sistema obtenha alterac,oes que nao sao
   anunciadas no momento em que e implantado, esse sistema deve executar uma
   branch de seguranc,a.

                          Capitulo 5. Hats (Func,oes)

   Indice

   5.1. Hats Universais

   5.2. Hats oficiais (Pessoas com func,oes definidas)

   5.3. Hats dependentes de processo

   Muitos committers tem uma area especial de responsabilidade. Esses papeis
   sao chamados de hats. Esses titulos podem ser func,oes do projeto, como
   diretor de relac,oes publicas ou mantenedor de uma determinada area do
   codigo. Como esse e um projeto em que as pessoas doam voluntariamente seu
   tempo livre, as pessoas com hats atribuidos nem sempre estao disponiveis.
   Eles devem, portanto, nomear um substituto que possa desempenhar o cargo
   de hat em sua ausencia. A outra opc,ao e ter o cargo ocupado por um grupo.

   Muitos desses hats nao sao formalizados. Hats formalizados tem uma carta
   indicando o proposito exato do hat, juntamente com seus privilegios e
   responsabilidades. A redac,ao de tais cartas e uma nova parte do projeto
   e, portanto, ainda nao foi concluida para todos os hats. Essas descric,oes
   de hats nao sao uma formalizac,ao, e sim um resumo da func,ao com links
   para a carta quando disponiveis e enderec,os de contato.

5.1. Hats Universais

  5.1.1. Colaborador

   Um Colaborador contribui para o projeto do FreeBSD como desenvolvedor,
   como autor, enviando relatorios de problemas ou contribuindo de outras
   formas para o progresso do projeto. Um colaborador nao tem privilegios
   especiais no projeto do FreeBSD. [FreeBSD, 2002F]

  5.1.2. Committer

   Uma pessoa que possui os privilegios necessarios para adicionar seu codigo
   ou documentac,ao ao repositorio. Um committer fez um commit nos ultimos 12
   meses. [FreeBSD, 2000A] Um committer ativo e um committer que fez uma
   media de um commit por mes durante esse tempo.

   Vale a pena notar que nao existem barreiras tecnicas para impedir que
   alguem, uma vez tendo ganho privilegios de commit para o main- ou um
   sub-projeto, de fazer commits em partes do codigo desse projeto que o
   committer nao obteve permissao especificamente para modificar. No entanto,
   quando quiser fazer modificac,oes em partes que um committer nao tenha
   participado antes, ele deve ler os logs para ver o que aconteceu nesta
   area antes, e tambem ler o arquivo MAINTAINER para ver se o mantenedor
   desta parte tem quaisquer pedidos especiais sobre como as alterac,oes no
   codigo devem ser feitas

  5.1.3. Equipe principal (Core Team)

   A equipe principal e eleita pelos committers da lista de committers e
   serve como a diretoria do projeto FreeBSD. Promove colaboradores ativos
   para committers, atribui pessoas a hats bem definidos e e o mediador final
   de decisoes envolvendo o caminho que o projeto deve seguir. Em 1-o de
   julho de 2004, o core consistia de 9 membros. As eleic,oes sao realizadas
   a cada dois anos.

  5.1.4. Maintainership

   Maintainership significa que essa pessoa e responsavel pelo que e
   permitido entrar nessa area do codigo e tem a palavra final caso ocorram
   discordancias sobre o codigo. Isso envolve trabalho proativo destinado a
   estimular contribuic,oes e trabalho reativo na revisao de commits.

   Com o codigo fonte do FreeBSD vem o arquivo MAINTAINERS que contem um
   resumo de uma linha de como cada mantenedor gostaria que as contribuic,oes
   fossem feitas. Ter este aviso e informac,oes de contato permite que os
   desenvolvedores se concentrem no esforc,o de desenvolvimento, em vez de
   ficarem presos em uma correspondencia lenta, caso o mantenedor nao esteja
   disponivel por algum tempo.

   Se o mantenedor nao estiver disponivel por um periodo de tempo
   excessivamente longo, e outras pessoas fizerem uma quantidade
   significativa de trabalho, a manutenc,ao pode ser trocada sem a aprovac,ao
   do mantenedor. Isto e baseado na postura de que a manutenc,ao deve ser
   demonstrada, nao declarada.

   A manutenc,ao de uma parte especifica do codigo e um hat que nao e mantido
   como um grupo.

5.2. Hats oficiais (Pessoas com func,oes definidas)

   Os hats oficiais no Projeto FreeBSD sao hats que sao mais ou menos
   formalizados e, principalmente, com func,oes administrativas. Eles tem
   autoridade e responsabilidade por sua area. A ilustrac,ao a seguir mostra
   as linhas de responsabilidade. Depois disso segue uma descric,ao de cada
   hat, incluindo quem os mantem.

   Figura 5.1. Visao geral dos hats (func,oes) oficiais
   Visao geral dos hats (func,oes) oficiais

   Todas as caixas consistem em grupos de committers, exceto as caixas
   pontilhadas onde os detentores nao sao necessariamente committers. Os
   circulos planificados sao subprojetos e consistem em committers e pessoas
   que nao sao committers do projeto principal.

  5.2.1. Gerente de Projetos de Documentac,ao

   The FreeBSD Documentation Project e o arquiteto responsavel por definir e
   acompanhar as metas de documentac,ao para os committers no projeto
   Documentac,ao.

   Hat mantido pela: Equipe do DocEng <doceng@FreeBSD.org>. O Capitulo
   DocEng.

  5.2.2. Postmaster

   O Postmaster e responsavel pelo envio correto do email para o enderec,o de
   email dos committers. Ele tambem e responsavel por garantir que as listas
   de discussao funcionem e deve tomar medidas contra possiveis interrupc,oes
   de correspondencia, como filtros de virus, spam e trolls.

   Hat atualmente mantido pelo: Time Postmaster <postmaster@FreeBSD.org>.

  5.2.3. Coordenac,ao de Release (Versoes/Lanc,amentos)

   As responsabilidades da Equipe de Engenharia de Release sao

     * Definir, publicar e seguir um cronograma de lanc,amento para releases
       (versoes) oficiais

     * Documentando e formalizando procedimentos de engenharia da release

     * Criac,ao e manutenc,ao de branches de codigo

     * Coordenando com as equipes de Ports e Documentac,ao para ter um
       conjunto atualizado de pacotes e documentac,ao lanc,ados com as novas
       releases

     * Coordenar com a equipe de seguranc,a para que as versoes pendentes nao
       sejam afetadas por vulnerabilidades divulgadas recentemente.

   Mais informac,oes sobre o processo de desenvolvimento estao disponiveis na
   sec,ao release engineering.

   Hat mantido pela: Equipe de Engenharia de Release <re@FreeBSD.org>. O
   Capitulo de Engenharia de Release.

  5.2.4. Relac,oes Publicas & Contato Corporativo

   Relac,oes Publicas & As responsabilidades do contato corporativo sao:

     * Fazer declarac,oes de imprensa quando acontecem coisas que sao
       importantes para o projeto FreeBSD.

     * Ser a pessoa de contato oficial para corporac,oes que estao
       trabalhando em estreita colaborac,ao com o Projeto FreeBSD.

     * Tomar medidas para promover o FreeBSD tanto na comunidade Open Source
       quanto no mundo corporativo.

     * Lidar com a lista de discussao "freebsd-advocacy".

   Este hat nao esta atualmente ocupado.

  5.2.5. Oficial de seguranc,a

   A principal responsabilidade do Security Officer (Oficial de Seguranc,a) e
   coordenar a troca de informac,oes com outras pessoas na comunidade de
   seguranc,a e no projeto FreeBSD. O agente de seguranc,a tambem e
   responsavel por tomar medidas quando os problemas de seguranc,a sao
   relatados e promover um comportamento proativo de desenvolvimento quando
   se trata de seguranc,a.

   Devido ao receio de que informac,oes sobre vulnerabilidades possam vazar
   para pessoas com intenc,oes maliciosas antes que um patch esteja
   disponivel, apenas o Oficial de Seguranc,a, composto por um oficial, um
   adjunto e dois membros do Core team, recebe informac,oes confidenciais
   sobre problemas de seguranc,a. No entanto, para criar ou implementar um
   patch, o Oficial de Seguranc,a tem a equipe de seguranc,a oficial
   <security-team@FreeBSD.org> para ajudar no trabalho.

  5.2.6. Gerenciador do Repositorio de Codigo Fonte

   O Source Repository Manager (Gerenciador do Repositorio de Codigo Fonte) e
   o unico que tem permissao para modificar diretamente o repositorio sem
   usar a ferramenta SVN. E sua responsabilidade garantir que os problemas
   tecnicos que surgem no repositorio sejam resolvidos rapidamente. O
   gerenciador do repositorio de codigo fonte possui a autoridade para voltar
   commits, se isso for necessario para resolver um problema tecnico do SVN.

   Hat mantido pelo: Source Repository Manager <clusteradm@FreeBSD.org>.

  5.2.7. Gerente de Eleic,oes

   O Gerente de Eleic,oes e responsavel pelo processo Core election. O
   gerente e responsavel por executar e manter o sistema eleitoral, e e a
   autoridade final caso eventos imprevistos menores ocorram no processo
   eleitoral. Grandes imprevistos devem ser discutidos com o Core team

   Hat realizado apenas durante as eleic,oes.

  5.2.8. Gerenciamento de sites

   O hat Web site Management e responsavel por coordenar o lanc,amento de
   paginas Web atualizadas em espelhos ao redor do mundo, pela estrutura
   geral do site principal e pelo sistema em que esta sendo executado. O
   gerenciamento precisa coordenar o conteudo com The FreeBSD Documentation
   Project e atua como mantenedor da arvore "www".

   Hat mantido pelos: Webmasters do FreeBSD <www@FreeBSD.org>.

  5.2.9. Gerente de Ports

   O Gerente de Ports atua como uma conexao entre The Ports Subproject e o
   projeto principal, e todas as solicitac,oes do projeto devem ir para o
   gerente de ports.

   Hat mantido pela: Equipe de Gerenciamento de Ports <portmgr@FreeBSD.org>.
   O Capitulo Portmgr.

  5.2.10. Padroes

   O Standards (Padroes) e responsavel por garantir que o FreeBSD cumpra com
   os padroes com os quais esta comprometido, mantendo-se atualizado sobre o
   desenvolvimento desses padroes e notificando os desenvolvedores do FreeBSD
   sobre mudanc,as importantes que lhes permitam assumir um papel proativo e
   diminuir o tempo entre atualizac,ao de padroes e complacencia do FreeBSD.

   Hat atualmente mantido por: Garrett Wollman <wollman@FreeBSD.org>.

  5.2.11. Secretario do Core (do time do Core)

   A principal responsabilidade do Secretario do Core e redigir os drafts e
   publicar os Relatorios finais do Core. O secretario tambem mantem a agenda
   central, assegurando assim que nenhuma bola seja descartada sem soluc,ao.

   Hat atualmente mantido por: Joseph Mingrone <jrm@FreeBSD.org>.

  5.2.12. Bugmeister

   O Bugmeister e responsavel por garantir que o banco de dados de
   manutenc,ao esteja em ordem, que as entradas sejam categorizadas
   corretamente e que nao existam entradas invalidas.

   Hat atualmente mantido pelo: Time Bugmeister <bugmeister@FreeBSD.org>.

  5.2.13. Oficial de Contratos de doac,oes

   A tarefa do oficial de contratos de doac,oes e combinar os desenvolvedores
   com necessidades com pessoas ou organizac,oes dispostas a fazer uma
   doac,ao. A carta de ligac,ao de doac,oes esta disponivel aqui

   Hat mantida pelo: Escritorio de Contratos de Doac,oes
   <donations@FreeBSD.org>.

  5.2.14. Admin

   (Tambem chamado de "Administrador de Cluster do FreeBSD")

   A equipe administrativa consiste nas pessoas responsaveis
   &#8203;&#8203;por administrar os computadores dos quais o projeto depende,
   para que seu trabalho distribuido e comunicac,ao sejam sincronizados.
   Consiste principalmente naquelas pessoas que tem acesso fisico aos
   servidores.

   Hat mantido pela: Equipe de Admin <admin@FreeBSD.org>.

5.3. Hats dependentes de processo

  5.3.1. Criador do relatorio

   A pessoa originalmente responsavel pelo preenchimento de um Relatorio de
   Problemas.

  5.3.2. Bugbuster

   Uma pessoa que ira encontrar a pessoa certa para resolver o problema, ou
   fechar o PR se for uma duplicata ou nao uma interessante.

  5.3.3. Mentor

   Um mentor e um committer que assume a responsabilidade de introduzir um
   novo committer no projeto, tanto em termos de garantir que a nova
   configurac,ao de committers seja valida, que o novo committer conhec,a as
   ferramentas disponiveis necessarias em seu trabalho quanto que o novo
   committer saiba o que se espera dele em termos de comportamento.

  5.3.4. Fornecedor

   A(s) pessoa(s) ou organizac,ao de quem vem o codigo externo e para quem os
   patches sao enviados.

  5.3.5. Revisores

   Pessoas na lista de discussao em que a solicitac,ao de revisao e postada.

                             Capitulo 6. Processos

   Indice

   6.1. Adicionando novos committers e removendo committers antigos

   6.2. Enviando codigo para o projeto (Committing code)

   6.3. Eleic,ao do Core

   6.4. Desenvolvimento de novos recursos

   6.5. Manutenc,ao

   6.6. Relatorio de Problemas

   6.7. Reagindo ao mau comportamento

   6.8. Engenharia de Release (Versao)

   A sec,ao a seguir descrevera os processos definidos do projeto. Questoes
   que nao sao tratadas por esses processos acontecem em uma base ad-hoc com
   base no que era costume fazer em casos semelhantes.

6.1. Adicionando novos committers e removendo committers antigos

   O Core team tem a responsabilidade de fornecer e remover os privilegios de
   commit aos colaboradores. Isso so pode ser feito por meio de votac,ao na
   lista de discussao do core. Os subprojetos de ports e documentac,ao podem
   conceder privilegios de commit a pessoas que trabalham nesses projetos,
   mas ate o momento nao removeram esses privilegios.

   Normalmente, um colaborador e recomendado para o core por um committer.
   Para colaboradores ou pessoas de fora entrar em contato com o core pedindo
   para ser um committer nao e algo bem pensado e geralmente e rejeitado.

   Se a area de interesse particular para o desenvolvedor potencialmente se
   sobrepuser `a area de manutenc,ao de outros committers, a opiniao desses
   commiters mantenedores e solicitada. No entanto, e frequentemente esse
   committer que recomenda o desenvolvedor.

   Quando um colaborador recebe status de committer, ele recebe um mentor. O
   committer que recomendou o novo committer, no caso geral, assumira a
   responsabilidade de ser o novo mentor dos committers.

   Quando um colaborador recebe seu commit bit, um e-mail assinado PGP e
   enviado de Core Secretary, Ports Manager ou nik@freebsd.org para ambos
   admins@freebsd.org, o mentor designado, o novo committer e o core
   confirmando a aprovac,ao de uma nova conta. O mentor entao reune uma
   senha, a chave publica SSH 2 e a chave PGP do novo committer e as envia
   para Admin. Quando a nova conta e criada, o mentor ativa o commit bit e
   orienta o novo committer pelo resto do processo inicial.

   Figura 6.1. Resumo do processo: adicionando um novo committer
   Resumo do processo: adicionando um novo committer

   Quando um colaborador envia uma parte do codigo, o committer que recebe
   pode optar por recomendar que o colaborador receba privilegios de commit.
   Se ele recomendar isso para o core, eles irao votar essa recomendac,ao. Se
   eles votarem a favor, um mentor e designado ao novo committer e o novo
   committer tem que enviar seus dados para os administradores para que uma
   conta seja criada. Depois disso, o novo committer esta pronto para fazer
   seu primeiro commit. Por tradic,ao, isso e feito adicionando seu nome `a
   lista de committers.

   Lembre-se de que um committer e considerado alguem que tenha feito algum
   commit de codigo nos ultimos 12 meses. No entanto, somente apos 18 meses
   de inatividade terem se passado, os privilegios de commit sao qualificados
   para serem revogados. [FreeBSD, 2002H] Nao ha, no entanto, procedimentos
   automaticos para fazer isso. Para reac,oes a consentimentos de privilegios
   de commit nao acionados pelo tempo, veja a sec,ao 1.5.8.

   Figura 6.2. Resumo do processo: removendo um committer
   Resumo do processo: removendo um committer

   Quando o Core decide limpar a lista de committers, eles checam quem nao
   fez um commit nos ultimos 18 meses. Os committers que nao fizeram isso tem
   seus commit bit revogados.

   Tambem e possivel que os committers solicitem que seu commit bit seja
   retirado se, por alguma razao, eles nao estiverem mais se comprometendo
   ativamente com o projeto. Nesse caso, ele tambem pode ser restaurado
   posteriormente pelo core, caso o committer pec,a.

   Func,oes neste processo:

    1. Core team

    2. Contributor

    3. Committer

    4. Maintainership

    5. Mentor

   [FreeBSD, 2000A] [FreeBSD, 2002H] [FreeBSD, 2002I]

6.2. Enviando codigo para o projeto (Committing code)

   O processo de commit de um codigo novo ou modificado e um dos processos
   mais frequentes no projeto FreeBSD e geralmente acontece muitas vezes ao
   dia. O commit do codigo so pode ser feito por um "committer". Committers
   aplicam codigo escrito por eles mesmos, codigo enviado a eles ou codigo
   enviado atraves de um relatorio de problemas.

   Quando o codigo e escrito pelo desenvolvedor que e nao trivial, ele deve
   procurar uma revisao de codigo da comunidade. Isso e feito enviando
   e-mails para a lista relevante solicitando a revisao. Antes de enviar o
   codigo para revisao, ele deve garantir que ele seja compilado corretamente
   com a arvore inteira e que todos os testes relevantes sejam executados.
   Isso e chamado "teste de pre-commit". Quando o codigo contribuido e
   recebido, ele deve ser revisado pelo committer e testado da mesma maneira.

   Quando uma alterac,ao e "committed" em uma parte do codigo fonte que foi
   contribuida por um Vendor externo, o mantenedor deve garantir que o patch
   seja repassado ao fornecedor. Isso esta de acordo com a filosofia de
   codigo aberto e facilita a sincronizac,ao com os projetos externos, pois
   os patches nao precisam ser reaplicados sempre que uma nova versao e
   feita.

   Depois que o codigo estiver disponivel para revisao e nenhuma alterac,ao
   adicional for necessaria, o codigo sera "committed" na branch de
   desenvolvimento, -CURRENT. Se a alterac,ao se aplicar tambem `a branch
   -STABLE ou `as outras branches, uma contagem regressiva de um "Merge From
   Current" ("MFC") sera definida pelo committer. Apos o numero de dias que o
   committer escolheu ao configurar o MFC, um email sera enviado
   automaticamente ao committer, lembrando-o de envia-lo para a branch
   -STABLE (e possivelmente tambem para branches de seguranc,a). Apenas
   alterac,oes criticas de seguranc,a devem ser aplicadas a branch de
   seguranc,a.

   Atrasar o commit para -STABLE e outras branches permite "depurac,ao
   paralela" onde o codigo "committed" e testado em uma ampla gama de
   configurac,oes. Isso faz alterac,oes no -STABLE para conter menos falhas
   e, assim, dar seu nome `a branch.

   Figura 6.3. Resumo do processo: um committer aplica o codigo
   Resumo do processo: um committer aplica o codigo

   Quando um committer escreveu um pedac,o de codigo e quer fazer o seu
   commit, ele primeiro precisa determinar se e trivial o suficiente entrar
   sem uma analise previa ou se deve ser revisado pela comunidade de
   desenvolvedores. Se o codigo e trivial ou foi revisado e o committer nao e
   o mantenedor, ele deve consultar o mantenedor antes de continuar. Se o
   codigo for contribuido por um fornecedor externo, o mantenedor deve criar
   um patch que seja enviado de volta ao fornecedor. O codigo e entao
   confirmado e implantado pelos usuarios. Caso encontrem problemas com o
   codigo, isso sera relatado e o committer podera voltar a escrever um
   patch. Se um fornecedor for afetado, ele pode optar por implementar ou
   ignorar o patch.

   Figura 6.4. Resumo do processo: um colaborador envia o codigo
   Resumo do processo: um colaborador envia o codigo

   A diferenc,a quando um colaborador faz uma contribuic,ao de codigo e que
   ele envia o codigo atraves da interface do Bugzilla. Este relatorio e
   escolhido pelo mantenedor que revisa o codigo e faz o seu commit.

   Hats incluidos neste processo sao:

    1. Committer

    2. Contributor

    3. Vendor

    4. Reviewer

   [FreeBSD, 2001] [Jo/rgensen, 2001]

6.3. Eleic,ao do Core

   As eleic,oes do core sao realizadas pelo menos a cada dois anos. [8] Nove
   membros do core sao eleitos. Novas eleic,oes serao realizadas se o numero
   de membros do core ficar abaixo de sete. Novas eleic,oes tambem podem ser
   realizadas se pelo menos 1/3 dos committers ativos exigirem isso.

   Quando uma eleic,ao e realizada, o core anuncia isso com pelo menos 6
   semanas de antecedencia e nomeia um gerente eleitoral para dirigir as
   eleic,oes.

   Somente committers podem ser eleitos para o core. Os candidatos precisam
   apresentar sua candidatura pelo menos uma semana antes do inicio das
   eleic,oes, mas podem refinar suas declarac,oes ate o inicio da votac,ao.
   Eles sao apresentados na lista de candidatos. Ao escrever suas
   declarac,oes eleitorais, os candidatos devem responder a algumas perguntas
   padroes submetidas pelo gerente eleitoral.

   Durante as eleic,oes, a regra que um committer deve ter feito um commit
   durante os 12 meses passados &#8203;&#8203;e seguida estritamente. Apenas
   esses committers estao qualificados para votar.

   Ao votar, o committer pode votar uma vez em apoio de ate nove candidatos.
   A votac,ao e feita durante um periodo de quatro semanas com lembretes
   sendo postados na lista de discussao "developers" que esta disponivel para
   todos os committers.

   Os resultados das eleic,oes sao divulgados uma semana apos o termino da
   eleic,ao, e a nova equipe do core toma posse uma semana apos o lanc,amento
   dos resultados.

   Se houver um empate de votac,ao, isso sera resolvido pelos novos membros
   do core, eleitos sem ambiguidade.

   Votos e declarac,oes de candidatos sao arquivados, mas os arquivos nao
   estao publicamente disponiveis.

   Figura 6.5. Resumo do processo: Eleic,oes do Core
   Resumo do processo: Eleic,oes do Core

   O Core anuncia a eleic,ao e seleciona um gerente eleitoral. Ele prepara as
   eleic,oes e, quando estiver pronto, os candidatos podem anunciar suas
   candidaturas atraves da apresentac,ao de suas declarac,oes. Os committers
   entao votam. Apos o termino da votac,ao, os resultados das eleic,oes sao
   anunciados e a nova equipe do core toma posse.

   Hats nas eleic,oes do Core sao:

     * Core team

     * Committer

     * Election Manager

   [FreeBSD, 2000A] [FreeBSD, 2002B] [FreeBSD, 2002G]

6.4. Desenvolvimento de novos recursos

   Dentro do projeto existem subprojetos que estao trabalhando em novos
   recursos. Esses projetos geralmente sao feitos por uma pessoa [Jo/rgensen,
   2001]. Todo projeto e livre para organizar o desenvolvimento como achar
   melhor. No entanto, quando e feito o merge do projeto (aplicado) `a branch
   -CURRENT, ele deve seguir as diretrizes do projeto. Quando o codigo foi
   bem testado na branch -CURRENT e considerado estavel o suficiente e
   relevante para a branch -STABLE, ele e mergeado `a branch -STABLE.

   Os requisitos do projeto sao fornecidos como o desenvolvedor desejar,
   solicitac,oes da comunidade em termos de solicitac,oes diretas por
   correio, relatorios de problemas, financiamento comercial para o
   desenvolvimento de recursos ou contribuic,oes da comunidade cientifica. Os
   desejos que estao sob a responsabilidade de um desenvolvedor sao dados
   `aquele desenvolvedor que prioriza seu tempo entre o pedido e seus
   desejos. Uma maneira comum de fazer isso e manter uma lista de tarefas
   mantidas pelo projeto. Itens que nao sao de responsabilidade de alguem sao
   coletados em TODO-lists, a menos que alguem seja voluntario para assumir a
   responsabilidade. Todos os pedidos, sua distribuic,ao e acompanhamento sao
   tratados pela ferramenta Bugzilla.

   A analise de requisitos acontece de duas maneiras. As solicitac,oes que
   entram sao discutidas em listas de discussao, tanto dentro do projeto
   principal quanto no subprojeto ao qual a solicitac,ao pertence ou e gerada
   pela solicitac,ao. Alem disso, os desenvolvedores individuais no
   subprojeto avaliarao a viabilidade das solicitac,oes e determinarao a
   priorizac,ao entre elas. Alem dos arquivos das discussoes que ocorreram,
   nenhum resultado e criado por essa fase que e incorporada ao projeto
   principal.

   Como os pedidos sao priorizados pelos desenvolvedores individuais com base
   em fazer o que eles acham interessante, necessario ou sao financiados para
   fazer, nao ha estrategia geral ou priorizac,ao de solicitac,oes que
   considerem como requisitos e acompanhamento de sua implementac,ao correta.
   No entanto, a maioria dos desenvolvedores tem uma visao compartilhada de
   quais problemas sao mais importantes e podem solicitar diretrizes da
   equipe de engenharia de release.

   A fase de verificac,ao do projeto e dupla. Antes de fazer o commit do
   codigo para a branch atual, os desenvolvedores solicitam que seu codigo
   seja revisado por seus pares. Esta revisao e, na maior parte, feita por
   testes funcionais, mas a revisao de codigo tambem e importante. Quando o
   codigo e "committed" para a branch, um teste funcional mais amplo
   ocorrera, o que pode acionar mais revisoes de codigo e depurac,ao, caso o
   codigo nao se comporte conforme o esperado. Esta segunda forma de
   verificac,ao pode ser considerada como verificac,ao estrutural. Embora os
   proprios subprojetos possam escrever testes formais, como testes de
   unidade, eles geralmente nao sao coletados pelo projeto principal e
   geralmente sao removidos antes que o codigo seja "committed" na branch
   atual. [9]

6.5. Manutenc,ao

   E uma vantagem para o projeto que para cada area do codigo fonte tenha
   pelo menos uma pessoa que conhec,a bem essa area. Algumas partes do codigo
   designaram mantenedores. Outros tem mantenedores de fato, e algumas partes
   do sistema nao possuem mantenedores. O mantenedor e geralmente uma pessoa
   do subprojeto que escreveu e integrou o codigo, ou alguem que o portou da
   plataforma para a qual foi escrito. [10] O trabalho do mantenedor e
   garantir que o codigo esteja em sincronia com o projeto de onde vem o
   codigo, se for um codigo contribuido, e aplicar correc,oes enviadas pela
   comunidade ou escrever correc,oes em problemas descobertos.

   A maior parte do trabalho que e colocado no projeto FreeBSD e a
   manutenc,ao. [Jo/rgensen, 2001] fez uma figura mostrando o ciclo de vida
   das mudanc,as.

   Figura 6.6. O modelo de Jo/rgenssen para integrac,ao de mudanc,as
   O modelo de Jo/rgenssen para integrac,ao de mudanc,as

   Aqui, "desenvolvimento de release (versao)" refere-se a branch -CURRENT,
   enquanto o "release em produc,ao" refere-se a branch -STABLE. O "teste de
   pre-commit" e o teste funcional feito por desenvolvedores de peers quando
   solicitado a faze-lo ou a testar o codigo para determinar o status do
   subprojeto. "Debug paralelo" e o teste funcional que pode acionar mais
   revisoes e debugs quando o codigo e incluido na branch -CURRENT.

   A partir desta escrita, havia 269 committers no projeto. Quando eles fazem
   o commit de uma mudanc,a em uma branch, isso constitui uma nova release
   (versao). E muito comum os usuarios da comunidade rastrearem uma
   determinada branch. A existencia imediata de uma nova release torna as
   mudanc,as amplamente disponiveis imediatamente e permite um feedback
   rapido da comunidade. Isso tambem da `a comunidade o tempo de resposta que
   eles esperam em questoes que sao importantes para eles. Isso torna a
   comunidade mais engajada e, assim, permite mais e melhores feedbacks que
   estimulam mais a manutenc,ao e, por fim, devera criar um produto melhor.

   Antes de fazer alterac,oes no codigo em partes da arvore que tem um
   historico desconhecido para o committer, o committer e obrigado a ler os
   logs de commit para ver porque certos recursos sao implementados da
   maneira que eles estao, para nao cometer erros que foram anteriormente
   pensado ou resolvido.

6.6. Relatorio de Problemas

   Antes do FreeBSD 10, o FreeBSD incluia uma ferramenta de relatorio de
   problemas chamada send-pr. Os problemas incluem relatorios de bugs,
   solicitac,oes de recursos, aprimoramentos de recursos e avisos de novas
   versoes de software externo incluidas no projeto. Embora o send-pr esteja
   disponivel, os usuarios e desenvolvedores sao incentivados a enviar
   problemas usando nosso formulario de relatorio de problemas.

   Os relatorios de problemas sao enviados para um enderec,o de e-mail, onde
   sao inseridos no banco de dados de manutenc,ao de Relatorios de Problemas.
   Um Bugbuster classifica o problema e o envia ao grupo ou mantenedor
   correto dentro do projeto. Depois que alguem assume a responsabilidade
   pelo relatorio, o relatorio estara sendo analisado. Esta analise inclui
   verificar o problema e pensar em uma soluc,ao para o problema. Muitas
   vezes e necessario feedback do criador do relatorio ou ate mesmo da
   comunidade do FreeBSD. Uma vez que um patch para o problema e feito, o
   criador pode ser solicitado a testa-lo. Finalmente, o patch de trabalhado
   e integrado ao projeto e documentado, se aplicavel. Ele passa pelo ciclo
   de manutenc,ao regular, conforme descrito na sec,ao maintenance. Estes sao
   os estados em que um relatorio de problemas pode estar: aberto, analisado,
   feedback, corrigido, suspenso e fechado. O estado suspenso e para quando
   um progresso adicional nao e possivel devido `a falta de informac,ao ou
   quando a tarefa exigiria tanto trabalho que ninguem esta trabalhando nela
   no momento.

   Figura 6.7. Resumo do processo: Relatorio de Pproblemas
   Resumo do processo: Relatorio de Pproblemas

   Um problema e relatado pelo criador do relatorio. E entao classificado por
   um bugbuster e entregue ao mantenedor correto. Ele verifica o problema e
   discute o problema com o criador ate que ele tenha informac,oes
   suficientes para criar um patch de trabalhado. Este patch e entao
   "committed" e o relatorio de problemas e fechado.

   As func,oes incluidas neste processo sao:

    1. Report originator

    2. Maintainership

    3. Bugbuster

   [FreeBSD, 2002C]. [FreeBSD, 2002D]

6.7. Reagindo ao mau comportamento

   [FreeBSD, 2001] tem um numero de regras que os committers devem seguir. No
   entanto, acontece que essas regras sao quebradas. As seguintes regras
   existem para poder reagir ao mau comportamento. Eles especificam quais
   ac,oes resultarao e em quanto tempo sera uma suspensao dos privilegios de
   commit do committer.

     * Fazer um commit durante o code freeze (tempo de congelamento de
       codigo) sem a aprovac,ao da equipe dos Engenheiros de Release - 2 dias

     * Fazer um commit em uma branch de seguranc,a sem aprovac,ao - 2 dias

     * Guerras por causa de commit - 5 dias para todas as partes
       participantes

     * Comportamento deselegante ou inapropriado - 5 dias

   [Lehey, 2002]

   Para que as suspensoes sejam eficientes, qualquer membro do core pode
   implementar uma suspensao antes de discuti-la na lista de discussao
   "core". Os infratores reincidentes podem, com um voto de 2/3 do core,
   receber penalidades mais duras, incluindo a remoc,ao permanente dos
   privilegios de commit. (No entanto, este ultimo e sempre visto como um
   ultimo recurso, devido `a sua tendencia inerente de criar controversia).
   Todas as suspensoes sao postadas na lista de discussao "developers", uma
   lista disponivel apenas para committers.

   E importante que voce nao possa ser suspenso por cometer erros tecnicos.
   Todas as penalidades vem de quebrar a etiqueta social.

   Hats envolvidos neste processo:

     * Core team

     * Committer

6.8. Engenharia de Release (Versao)

   O projeto FreeBSD possui uma equipe de Engenharia de Release com um
   engenheiro de release principal responsavel por criar versoes do FreeBSD
   que podem ser trazidas para a comunidade de usuarios atraves da rede ou
   vendidas em lojas de varejo. Como o FreeBSD esta disponivel em varias
   plataformas e as releases para as diferentes arquiteturas sao
   disponibilizadas ao mesmo tempo, a equipe tem uma pessoa responsavel por
   cada arquitetura. Alem disso, ha cargos na equipe responsavel por
   coordenar os esforc,os de garantia de qualidade, construir um conjunto de
   pacotes e ter um conjunto atualizado de documentos. Ao se referir ao
   engenheiro de release, um representante da equipe de engenharia de release
   e indicado.

   Quando uma versao esta chegando, o projeto do FreeBSD muda de forma um
   pouco. Um cronograma de lanc,amento e feito contendo congelamentos de
   recursos e codigos, liberac,ao de versoes intermediarias e a versao final.
   Um congelamento de recursos significa que nenhum novo recurso pode ser
   aplicado na branch sem o consentimento explicito dos engenheiros de
   release. O congelamento de codigo significa que nenhuma alterac,ao no
   codigo (como bugs-fixes) pode ser aplicada sem o consentimento explicito
   dos engenheiros de release. Esse congelamento de recurso e codigo e
   conhecido como estabilizac,ao. Durante o processo de lanc,amento, o
   engenheiro de release tem a autoridade total para reverter para versoes
   mais antigas de codigo e, assim, "desfazer" as alterac,oes, caso ache que
   as alterac,oes nao sao adequadas para serem incluidas na versao.

   Existem tres tipos diferentes de releases:

    1. Releases .0 sao o primeiro lanc,amento de uma versao principal. Eles
       sao branches da branch -CURRENT e tem um ciclo de engenharia de
       release significativamente maior devido `a natureza instavel da branch
       -CURRENT

    2. As versoes .X sao releases da branch -STABLE. Elas estao programadas
       para sair a cada 4 meses.

    3. As versoes .X.Y sao versoes de seguranc,a que seguem a branch .X. Eles
       saem somente quando correc,oes de seguranc,a suficientes foram feito
       aplicadas desde o ultimo release nessa branch. Novos recursos
       raramente sao incluidos e a equipe de seguranc,a esta muito mais
       envolvida nesses recursos do que em releases regulares.

   Para releases da branch -STABLE, o processo de release inicia 45 dias
   antes da data de lanc,amento prevista. Durante a primeira fase, os
   primeiros 15 dias, os desenvolvedores aplicam as alterac,oes que tiveram
   no -CURRENT e que desejam ter na versao para a branch do release. Quando
   esse periodo terminar, o codigo entra em um congelamento de codigo de 15
   dias, no qual apenas correc,oes de bugs, atualizac,oes de documentac,ao,
   correc,oes relacionadas `a seguranc,a e pequenas alterac,oes de driver de
   dispositivo sao permitidas. Essas alterac,oes devem ser aprovadas pelo
   engenheiro de release com antecedencia. No inicio do ultimo periodo de 15
   dias, um candidato a rec,ease e criado para testes generalizados. E menos
   provavel que as atualizac,oes sejam permitidas durante esse periodo,
   exceto por importantes correc,oes de bugs e atualizac,oes de seguranc,a.
   Neste periodo final, todos os releases sao considerados candidatos a
   release. No final do processo de release, uma release e criada com o novo
   numero da versao, incluindo distribuic,oes binarias em sites e a criac,ao
   de imagens em CD-ROM. No entanto, a release nao e considerado "realmente
   liberado" ate que uma mensagem PGP-assinada afirmando exatamente isso,
   seja enviada para a lista de discussao freebsd-announce; Qualquer coisa
   rotulada como "release" antes disso pode estar em processo e sujeita a
   alterac,oes antes do envio da mensagem assinada pelo PGP. [11].

   Os lanc,amentos da branch -CURRENT (ou seja, todas as releases que
   terminam com ".0") sao muito semelhantes, mas com o dobro do prazo.
   Comec,a 8 semanas antes do lanc,amento com o anuncio da linha do tempo da
   release. Duas semanas apos o processo de release, o congelamento de
   recursos e iniciado e os ajustes de desempenho devem ser mantidos ao
   minimo. Quatro semanas antes do lanc,amento, uma versao beta oficial e
   disponibilizada. Duas semanas antes do lanc,amento, o codigo e
   oficialmente transformado em uma nova versao. Esta versao recebe status de
   release candidate e, como na engenharia de release do -STABLE, o
   congelamento de codigo do release candidate e endurecido. No entanto, o
   desenvolvimento na branch principal de desenvolvimento pode continuar.
   Alem dessas diferenc,as, os processos de engenharia de release sao
   semelhantes.

   Releases .0 vao para o seu propria branch e sao destinadas principalmente
   a adoc,oes primarias. A branch passa por um periodo de estabilizac,ao, e
   nao e ate que o Release Engineering Team decida que as demandas de
   estabilidade foram satisfeitas e de que o branch se torna -STABLE e
   -CURRENT segmenta a proxima versao principal. Enquanto isso para a maioria
   tem sido com versoes .1, isso nao e uma demanda.

   A maioria das versoes sao feitas quando uma determinada data e considerada
   longa o suficiente desde o lanc,amento anterior. Uma data destino e
   definida para ter grandes releases a cada 18 meses e versoes menores a
   cada 4 meses. A comunidade de usuarios deixou bem claro que a seguranc,a e
   a estabilidade nao podem ser sacrificadas por prazos auto impostos e datas
   de lanc,amento desejadas. Por um lapso de tempo para nao se tornar muito
   longo no que diz respeito a questoes de seguranc,a e estabilidade, e
   necessaria uma disciplina extra ao aplicar alterac,oes na -STABLE.

   Figura 6.8. Resumo do processo: engenharia de release
   Resumo do processo: engenharia de release

   Estas sao as etapas do processo de engenharia de release. Varios
   candidatos a release podem ser criados ate que a versao seja considerada
   estavel o suficiente para ser liberada.

   [FreeBSD, 2002E]

     ----------------------------------------------------------------------

   [8] A primeira eleic,ao do core foi realizada em setembro de 2000

   [9] No entanto, mais e mais testes sao executados ao construir o sistema
   ("make world"). Esses testes sao, no entanto, uma adic,ao muito nova e
   ainda nao foi criada nenhuma estrutura sistematica para esses testes.

   [10] sendmail e named sao exemplos de codigo que foi feito merge (aplicado
   o codigo) de outras plataformas.

   [11] Muitos fornecedores comerciais usam essas imagens para criar CD-ROMs
   que sao vendidos em lojas de varejo.

                            Capitulo 7. Ferramentas

   Indice

   7.1. Subversion (SVN)

   7.2. Bugzilla

   7.3. Mailman

   7.4. Pretty Good Privacy

   7.5. Secure Shell

   As principais ferramentas de suporte para suportar o processo de
   desenvolvimento sao Bugzilla, Mailman e OpenSSH. Estas sao ferramentas
   desenvolvidas externamente e sao comumente usadas no mundo do codigo
   aberto.

7.1. Subversion (SVN)

   Subversion ("SVN") e um sistema para lidar com multiplas versoes de
   arquivos de texto e rastrear quem aplicou mudanc,as e por que. Um projeto
   vive dentro de um "repositorio" e diferentes versoes sao consideradas
   "branches" diferentes.

7.2. Bugzilla

   O Bugzilla e um banco de dados de manutenc,ao que consiste em um conjunto
   de ferramentas para rastrear bugs em um site central. Ele suporta o
   processo de rastreamento de bugs para envio e tratamento de bugs, alem de
   consultar e atualizar o banco de dados e editar relatorios de bugs. O
   projeto usa sua interface web para enviar "Relatorios de Problemas" para o
   servidor central do Bugzilla. Os committers tambem possuem clientes web e
   de linha de comando.

7.3. Mailman

   Mailman e um programa que automatiza o gerenciamento de listas de
   discussao. O Projeto FreeBSD o utiliza para executar 16 listas gerais, 60
   listas tecnicas, 4 listas limitadas e 5 listas com logs de commit do CVS.
   Tambem e usado para muitas listas de discussao configuradas e usadas por
   outras pessoas e projetos na comunidade FreeBSD. Listas gerais sao listas
   para o publico em geral, listas tecnicas sao principalmente para o
   desenvolvimento de areas especificas de interesse, e listas fechadas sao
   para comunicac,ao interna nao destinadas ao publico em geral. A maior
   parte de toda a comunicac,ao no projeto passa por essas 85 listas,
   [FreeBSD, 2003A, Apendice C].

7.4. Pretty Good Privacy

   Pretty Good Privacy, mais conhecida como PGP, e um sistema criptografico
   que usa uma arquitetura de chave publica para permitir que as pessoas
   assinem e/ou criptografem digitalmente as informac,oes, a fim de garantir
   a comunicac,ao segura entre as duas partes. Uma assinatura e usada ao
   enviar informac,oes a muitos destinatarios, permitindo que eles verifiquem
   se as informac,oes nao foram adulteradas antes de recebe-las. No Projeto
   FreeBSD este e o principal meio de assegurar que a informac,ao tenha sido
   escrita pela pessoa que afirma ter escrito, e nao alterada em transito.

7.5. Secure Shell

   O Secure Shell e um padrao para efetuar login com seguranc,a em um sistema
   remoto e para executar comandos no sistema remoto. Ele permite que outras
   conexoes, chamadas tuneis, sejam estabelecidas e protegidas entre os dois
   sistemas envolvidos. Este padrao existe em duas versoes primarias, e
   somente a versao dois e usada para o projeto FreeBSD. A implementac,ao
   mais comum do padrao e o OpenSSH, que faz parte da distribuic,ao principal
   do projeto. Uma vez que sua fonte e atualizada com mais frequencia do que
   as liberac,oes do FreeBSD, a versao mais recente tambem esta disponivel na
   arvore de ports.

                            Capitulo 8. Sub-projetos

   Indice

   8.1. Subprojeto Ports

   8.2. O projeto de documentac,ao do FreeBSD

   Subprojetos sao formados para reduzir a quantidade de comunicac,ao
   necessaria para coordenar o grupo de desenvolvedores. Quando uma area
   problematica e suficientemente isolada, a maior parte da comunicac,ao
   estaria dentro do grupo, focando no problema, exigindo menos comunicac,ao
   com os grupos com os quais eles se comunicam do que se o grupo nao
   estivesse isolado.

8.1. Subprojeto Ports

   Um "port" e um conjunto de meta-dados e patches que sao necessarios para
   buscar, compilar e instalar corretamente um software externo em um sistema
   FreeBSD. A quantidade de ports cresceu a um ritmo tremendo, como mostra a
   figura a seguir.

   Figura 8.1. Numero de ports adicionados entre 1996 e 2005
   Numero de ports adicionados entre 1996 e 2005

   Figura 8.1, "Numero de ports adicionados entre 1996 e 2005" e obtido do
   site do FreeBSD. Ele mostra o numero de ports disponiveis para o FreeBSD
   no periodo de 1995 a 2005. Parece que a curva cresceu primeiro
   exponencialmente e, desde meados de 2001, cresceu linearmente.

   Como o software externo descrito pelo port geralmente esta em
   desenvolvimento continuo, a quantidade de trabalho necessaria para manter
   os ports ja e grande e esta aumentando. Isso fez com que a parte dos ports
   do projeto FreeBSD ganhasse uma estrutura mais poderosa, e esta se
   tornando cada vez mais um subprojeto do projeto FreeBSD.

   Ports tem seu proprio core team (time principal) com o Ports Manager como
   seu lider, e esta equipe pode indicar committers sem a aprovac,ao do
   FreeBSD Core. Ao contrario do Projeto FreeBSD, onde muitas tarefas de
   manutenc,ao sao frequentemente recompensadas com um commit bit, o
   subprojeto ports contem muitos mantenedores ativos que nao sao committers.

   Ao contrario do projeto principal, a arvore de ports nao e ramificada (tem
   uma branch propria). Cada versao do FreeBSD segue a colec,ao atual de
   ports e, portanto, disponibiliza informac,oes atualizadas sobre onde
   encontrar programas e como construi-los. Isso, no entanto, significa que
   um port que faz dependencias no sistema pode precisar ter variac,oes
   dependendo de qual versao do FreeBSD e executada.

   Com um repositorio de ports nao ramificado (sem branches), nao e possivel
   garantir que qualquer port seja executado em algo diferente de -CURRENT e
   -STABLE, em particular liberac,oes secundarias e antigas. Nao ha
   infraestrutura nem tempo de voluntariado necessario para garantir isso.

   Para eficiencia de comunicac,ao, as equipes que dependem de ports, como a
   equipe de engenharia de release, tem suas proprias conexoes com ports.

8.2. O projeto de documentac,ao do FreeBSD

   O projeto de Documentac,ao do FreeBSD foi iniciado em janeiro de 1995.
   Desde o grupo inicial de um lider de projeto, quatro lideres de equipe e
   16 membros, eles sao agora um total de 44 committers. A lista de discussao
   de documentac,ao tem pouco menos de 300 membros, indicando que ha uma
   grande comunidade em torno dela.

   O objetivo do projeto de Documentac,ao e fornecer uma documentac,ao boa e
   util do projeto FreeBSD, facilitando assim que novos usuarios se
   familiarizem com o sistema e detalhando recursos avanc,ados para os
   usuarios.

   As principais tarefas no projeto de Documentac,ao sao trabalhar em
   projetos atuais no "Conjunto de Documentac,ao do FreeBSD", e traduzir a
   documentac,ao para outros idiomas.

   Como o Projeto FreeBSD, a documentac,ao e dividida nas mesmas branches.
   Isso e feito para que sempre haja uma versao atualizada da documentac,ao
   de cada versao. Apenas erros de documentac,ao sao corrigidos nas branches
   de seguranc,a.

   Como o sub-projeto ports, o projeto de Documentac,ao pode indicar
   committers de documentac,ao sem a aprovac,ao do FreeBSD Core. [FreeBSD,
   2003B].

   O projeto de Documentac,ao possui uma cartilha. Isso e usado para
   apresentar novos membros de projeto `as ferramentas e sintaxes padrao e
   atua como referencia ao trabalhar no projeto.

                                  Referencias

   [Brooks, 1995] Frederick P. Brooks. Copyright (c) 1975, 1995 Pearson
   Education Limited. 0201835959. Addison-Wesley Pub Co. The Mythical
   Man-Month. Essays on Software Engineering, Anniversary Edition (2nd
   Edition).

   [Saers, 2003] Niklas Saers. Copyright (c) 2003. Um modelo de projeto para
   o projeto FreeBSD. Tese de Candidatus Scientiarum.
   http://niklas.saers.com/thesis.

   [Jo/rgensen, 2001] Niels Jo/rgensen. Copyright (c) 2001. Colocando tudo no
   porta-malas. Desenvolvimento Incremental de Software no Projeto Open
   Source do FreeBSD.
   http://www.dat.ruc.dk/~nielsj/research/papers/freebsd.pdf.

   [PMI, 2000] Instituto de Gerenciamento de Projeto. Copyright (c) 1996,
   2000 Instituto de Gerenciamento de Projetos. 1-880410-23-0. Instituto de
   Gerenciamento de Projetos. Newtown Square Pennsylvania USA . Guia PMBOK. A
   Guide to the Project Management Body of Knowledge, 2000 Edition.

   [FreeBSD, 2000A] Copyright (c) 2002 O projeto FreeBSD. Estatuto do Core.
   https://www.freebsd.org/internal/bylaws.html.

   [FreeBSD, 2002A] Copyright (c) 2002 O Projeto de Documentac,ao do FreeBSD.
   Manual do desenvolvedor do FreeBSD.
   https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/.

   [FreeBSD, 2002B] Copyright (c) 2002 O projeto FreeBSD. Eleic,ao da equipe
   do Core em 2002. http://election.uk.freebsd.org/candidates.html.

   [FreeBSD, 2002C] Dag-Erling Smo/rgrav e Hiten Pandya. Copyright (c) 2002 O
   Projeto de Documentac,ao do FreeBSD. O projeto de documentac,ao do
   FreeBSD. Diretrizes para manuseio de Relatorios de Problemas.
   https://www.freebsd.org/doc/en/articles/pr-guidelines/article.html.

   [FreeBSD, 2002D] Dag-Erling Smo/rgrav. Copyright (c) 2002 O Projeto de
   Documentac,ao do FreeBSD. O projeto de documentac,ao do FreeBSD.
   Escrevendo Relatorios de Problemas do FreeBSD.
   https://www.freebsd.org/doc/en/articles/problem-reports/article.html.

   [FreeBSD, 2001] Copyright (c) 2001 O Projeto de Documentac,ao do FreeBSD.
   O projeto de documentac,ao do FreeBSD. Guia para Commiters.
   https://www.freebsd.org/doc/en/articles/committers-guide/article.html.

   [FreeBSD, 2002E] Murray Stokely. Copyright (c) 2002 O Projeto de
   Documentac,ao do FreeBSD. O projeto de documentac,ao do FreeBSD.
   Engenharia de Release do FreeBSD.
   https://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.html.

   [FreeBSD, 2003A] Projeto de Documentac,ao do FreeBSD. Manual do FreeBSD.
   https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook.

   [FreeBSD, 2002F] Copyright (c) 2002 O Projeto de Documentac,ao do FreeBSD.
   O projeto de documentac,ao do FreeBSD. Colaboradores para o FreeBSD.
   https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/article.html.

   [FreeBSD, 2002G] Copyright (c) 2002 O projeto FreeBSD. O projeto FreeBSD.
   Eleic,oes da equipe do Core em 2002. http://election.uk.freebsd.org.

   [FreeBSD, 2002H] Copyright (c) 2002 O projeto FreeBSD. O projeto FreeBSD.
   Politica de expirac,ao de commit bit. 2002/04/06 15:35:30.
   https://www.freebsd.org/internal/expire-bits.html.

   [FreeBSD, 2002I] Copyright (c) 2002 O projeto FreeBSD. O projeto FreeBSD.
   Novo procedimento de criac,ao de conta. 2002/08/19 17:11:27.
   https://www.freebsd.org/internal/new-account.html.

   [FreeBSD, 2003B] Copyright (c) 2002 O Projeto de Documentac,ao do FreeBSD.
   O projeto de documentac,ao do FreeBSD. Capitulo da Equipe do DocEng do
   FreeBSD. 2003/03/16 12:17. https://www.freebsd.org/internal/doceng.html.

   [Lehey, 2002] Greg Lehey. Copyright (c) 2002 Greg Lehey. Greg Lehey. Dois
   anos nas trincheiras. A evoluc,ao de um projeto de software.
   http://www.lemis.com/grog/In-the-trenches.pdf.
