path: root/pt_BR.ISO8859-1/books/dev-model/book.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE book PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN" "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd" [
<!ENTITY % chapters SYSTEM "chapters.ent">
<!-- $FreeBSD$ --><!--!ENTITY chap.references	SYSTEM "references.xml"-->]>
<!--
  - Copyright (c) 2002-2005 Niklas Saers
  - All rights reserved.
  -
  - Redistribution and use in source and binary forms, with or without
  - modification, are permitted provided that the following conditions
  - are met:
  - 1. Redistributions of source code must retain the above copyright
  - notice, this list of conditions and the following disclaimer.
  - 2. Redistributions in binary form must reproduce the above copyright
  - notice, this list of conditions and the following disclaimer in the
  - documentation and/or other materials provided with the distribution.
  -
  - THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
  - ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  - IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  - ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
  - FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  - DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  - OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  - HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  - LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  - OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  - SUCH DAMAGE.
  -
  - $FreeBSD$
  -->
<book xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:its="http://www.w3.org/2005/11/its" version="5.0" xml:lang="pt_BR">
     <info><title>Um modelo de projeto para o projeto FreeBSD</title>
        
        <author><personname><firstname>Niklas</firstname><surname>Saers</surname></personname></author>
        <copyright><year>2002-2005</year> <holder>Niklas Saers</holder></copyright>
	<revhistory>
	  <revision><revnumber>1.5</revnumber> <date>October, 2014</date> <revremark>Remove mention of GNATS which is no longer used by the project.</revremark></revision>
	  <revision><revnumber>1.4</revnumber> <date>September, 2013</date> <revremark>Remove mention of CVS and CVSup which are no longer used by the project.</revremark></revision>
	  <revision><revnumber>1.3</revnumber> <date>October, 2012</date> <revremark>Removido funções de pessoas especificas, isso é documentado em outro lugar.</revremark></revision>
            <revision><revnumber>1.2</revnumber> <date>April, 2005</date> <revremark>Update one year of changes, replace statistics with those of 2004</revremark></revision>
            <revision><revnumber>1.1</revnumber> <date>July, 2004</date> <revremark>First update within the FreeBSD tree</revremark></revision>
            <revision><revnumber>1.0</revnumber> <date>December 4th, 2003</date> <revremark>Ready for commit to FreeBSD Documentation</revremark></revision>
            <revision><revnumber>0.7</revnumber> <date>April 7th, 2003</date> <revremark>Release for review by the Documentation team</revremark></revision>
            <revision><revnumber>0.6</revnumber> <date>March 1st, 2003</date> <revremark>Incorporated corrections noted by interviewees and reviewers</revremark></revision>
            <revision><revnumber>0.5</revnumber> <date>February 1st, 2003</date> <revremark>Initial review by interviewees</revremark></revision>
        </revhistory>

	<releaseinfo>$FreeBSD$</releaseinfo>
    </info>
    <preface xml:id="foreword">

        <title>Prefácio</title>
        <para>Até agora, o projeto FreeBSD lançou várias técnicas descritas para fazer diferentes partes do trabalho. No entanto, um modelo de projeto resumindo como o projeto é estruturado é necessário devido à quantidade crescente de membros do projeto. <footnote>
                <para>Isso vai de mãos dadas com a lei de Brooks onde <quote>adicionar outra pessoa a um projeto atrasado irá atrasa-lo ainda mais</quote> pois irá aumentar as necessidades de comunicação <xref linkend="brooks"/>. Um modelo de projeto é uma ferramenta para reduzir as necessidades de comunicação.</para>
            </footnote> Este artigo fornecerá esse modelo de projeto e será doado ao projeto de Documentação do FreeBSD, onde ele poderá evoluir junto com o projeto, de modo que ele possa, a qualquer momento, refletir a maneira como o projeto funciona. É baseado em <citation><xref linkend="thesis"/></citation>.</para>

        <para>Gostaria de agradecer às pessoas a seguir por dedicarem tempo para explicar coisas que não estavam claras para mim e por revisar o documento.</para>
            <itemizedlist>
                <listitem><para>Andrey A. Chernov <email>ache@freebsd.org</email></para></listitem>
                <listitem><para>Bruce A. Mah <email>bmah@freebsd.org</email></para></listitem>
                <listitem><para>Dag-Erling Smørgrav <email>des@freebsd.org</email></para></listitem>
                <listitem><para>Giorgos Keramidas<email>keramida@freebsd.org</email></para></listitem>
                <listitem><para>Ingvil Hovig <email>ingvil.hovig@skatteetaten.no</email></para></listitem>
                <listitem><para>Jesper Holck<email>jeh.inf@cbs.dk</email></para></listitem>
                <listitem><para>John Baldwin <email>jhb@freebsd.org</email></para></listitem>
                <listitem><para>John Polstra <email>jdp@freebsd.org</email></para></listitem>
                <listitem><para>Kirk McKusick <email>mckusick@freebsd.org</email></para></listitem>
                <listitem><para>Mark Linimon <email>linimon@freebsd.org</email></para></listitem>
                <listitem><para>Marleen Devos</para></listitem>
                <listitem><para>Niels Jørgenssen<email>nielsj@ruc.dk</email></para></listitem>
                <listitem><para>Nik Clayton <email>nik@freebsd.org</email></para></listitem>
                <listitem><para>Poul-Henning Kamp <email>phk@freebsd.org</email></para></listitem>
                <listitem><para>Simon L. Nielsen <email>simon@freebsd.org</email></para></listitem>
            </itemizedlist>

    </preface>

    <chapter xml:id="overview">
        <title>Visão geral</title>


        <para>Um modelo de projeto é um meio de reduzir a sobrecarga de comunicações em um projeto. Conforme mostrado por <citation><xref linkend="brooks"/></citation>, aumentar o número de participantes do projeto aumenta exponencialmente a comunicação no projeto. O FreeBSD tem aumentado nos últimos anos tanto sua massa de usuários ativos quanto de committers, e a comunicação no projeto aumentou de acordo com esse crescimento. Esse modelo de projeto servirá para reduzir essa sobrecarga, fornecendo uma descrição atualizada do projeto.</para>

        <para>Durante as eleições do Core em 2002, Mark Murray declarou: <quote>Me oponho a um longo livro de regras, pois isso satisfaz tendências de advogados e é contrário ao tecnocentrismo de que o projeto tanto necessita.</quote> <citation><xref linkend="bsd-election2002"/></citation>. Este modelo de projeto não pretende ser uma ferramenta para justificar a criação de imposições para desenvolvedores, mas como uma ferramenta para facilitar a coordenação. Isso tem significado como uma descrição do projeto, com uma visão geral de como os diferentes processos são executados. É uma introdução ao funcionamento do projeto FreeBSD.</para>

        <para>O modelo do projeto FreeBSD será descrito a partir de 1º de julho de 2004. É baseado no paper de Niels Jørgensen <citation><xref linkend="jorgensen2001"/></citation>, documentos oficiais do FreeBSD, discussões em listas de discussão do FreeBSD e entrevistas com os desenvolvedores.</para>

        <para>Depois de fornecer as definições dos termos usados, este documento delineará a estrutura organizacional (incluindo descrições de funções e linhas de comunicação), discutirá o modelo de metodologia e, depois de apresentar as ferramentas usadas para controle de processos, apresentará os processos definidos. Finalmente, ele delineará os principais subprojetos do projeto FreeBSD.</para>

        <para><citation><xref linkend="freebsd-developer-handbook"/>, Seção 1.2 e 1.3</citation> fornece a visão e as diretrizes arquitetônicas do projeto. A visão é <quote>Produzir o melhor pacote de sistema operacional semelhante ao UNIX, respeitando a ideologia das ferramentas de software originais, bem como usabilidade, desempenho e estabilidade.</quote> As diretrizes de arquitetura ajudam a determinar se um problema que alguém quer que seja resolvido está dentro do escopo do projeto</para>
</chapter>

        <chapter xml:id="definitions">
            <title>Definições</title>

            <section xml:id="ref-activity" xreflabel="">
                <title>Atividade</title>

                <para>Uma <quote>atividade</quote> é um elemento do trabalho realizado durante o curso de um projeto <citation><xref linkend="ref-pmbok"/></citation>. Ele tem uma saída e leva a um resultado. Tal saída pode ser uma entrada para outra atividade ou parte da entrega do processo.</para>


            </section>

            <section xml:id="def-process" xreflabel="">
                <title>Processo</title>

                <para>Um <quote>processo</quote> é uma série de atividades que levam a um resultado específico. Um processo pode consistir em um ou mais subprocessos. Um exemplo de um processo é o design de software.</para>

            </section>

            <section xml:id="ref-hat" xreflabel="Hat">
                <title>Hat (Definição/função especifica para algumas pessoas)</title>

                <para>Uma <quote>hat</quote> é um sinônimo de função. Uma hat tem certas responsabilidades em um processo e para o resultado do processo. O hat executa atividades. Está bem definido por quais problemas o hat deve ser contatado pelos membros do projeto e pessoas fora do projeto.</para>

            </section>

            <section xml:id="ref-outcome" xreflabel="Outcome">
                <title>Resultado</title>

                <para>Um <quote>resultado</quote> é a finalização do processo. Isso é sinônimo de entrega, que é definido como <quote>qualquer finalização mensurável, tangível, verificável ou item que deve ser produzido para concluir um projeto ou parte de um projeto. Frequentemente usado de forma mais restrita em referência a uma entrega externa, que é uma entrega sujeita à aprovação do patrocinador ou cliente do projeto</quote>, por <citation><xref linkend="ref-pmbok"/></citation>. Exemplos de resultados são um software, uma decisão tomada ou um relatório escrito.</para>

            </section>


            <section xml:id="ref-freebsd" xreflabel="">
                <title>FreeBSD</title>

                <para>Ao dizer <quote>FreeBSD</quote> queremos dizer o sistema operacional FreeBSD derivativo do BSD semelhante ao UNIX, enquanto ao dizer <quote>o projeto FreeBSD</quote> queremos dizer a organização do projeto.</para>
            </section>
        </chapter>

        <chapter xml:id="model-orgstruct">
            <title>Estrutura organizacional</title>

            <para>Enquanto ninguém assume a propriedade do FreeBSD, a organização do FreeBSD é dividida em core, committers e colaboradores e isso faz parte da comunidade do FreeBSD que vive em torno dele.</para>
            <para>
                <figure>
                    <title>A estrutura do projeto FreeBSD</title>
                    <mediaobject><imageobject><imagedata fileref="orghierarchy"/></imageobject></mediaobject>
                </figure>
            </para>

            <para>O número de committers foi determinado passando pelos logs do CVS de 1º de janeiro de 2004 a 31 de dezembro de 2004 e pelos colaboradores, passando pela lista de contribuições e relatórios de problemas.</para>

            <para>O principal recurso na comunidade do FreeBSD são seus desenvolvedores: os committers e colaboradores. É com suas contribuições que o projeto pode avançar. Desenvolvedores regulares são referidos como colaboradores. Até 1º de janeiro de 2003, havia uma estimativa de 5500 colaboradores no projeto.</para>

            <para>Os committers são desenvolvedores com o privilégio de poder aplicar mudanças (fazer commit). Geralmente, são os desenvolvedores mais ativos que estão dispostos a gastar seu tempo não apenas integrando seu próprio código, mas integrando o código enviado pelos desenvolvedores que não têm esse privilégio. Eles também são os desenvolvedores que elegem a equipe principal (core) e têm acesso a discussões fechadas.</para>

            <para>O projeto pode ser agrupado em quatro partes separadas distintas, e a maioria dos desenvolvedores focará seu envolvimento em uma parte do FreeBSD. As quatro partes são desenvolvimento de kernel, desenvolvimento de userland, ports e documentação. Ao se referir ao sistema base, nos referimos tanto o kernel quanto o userland.</para>

            <para>Esta divisão muda nosso triângulo para ficar assim:</para>
            <para>
                <figure>
                    <title>A estrutura do Projeto FreeBSD com committers em categorias</title>
                    <mediaobject><imageobject><imagedata fileref="orghierarchy2"/></imageobject></mediaobject>
                </figure>
            </para>
            <para>O número de committers por área 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 várias áreas, fazendo com que o número total seja maior que o número real de committers. O número total de committers naquele momento era 269.</para>

            <para>Os committers se enquadram em três grupos: committers que estão preocupados apenas com uma área do projeto (por exemplo, sistemas de arquivos), committers que estão envolvidos apenas com um subprojeto e committers que se comprometem com partes diferentes do código, incluindo subprojetos. Como alguns committers trabalham em partes diferentes, o número total na seção commiters do triângulo é maior que no triângulo acima.</para>

            <para>O kernel é o principal bloco de construção do FreeBSD. Enquanto os aplicativos em userland são protegidos contra falhas em outros aplicativos do userland, todo o sistema é vulnerável a erros no kernel. Isso, combinado com a grande quantidade de dependências no kernel e que não é fácil ver todas as consequências de uma mudança no kernel, exige que os desenvolvedores tenham uma compreensão relativamente completa do kernel. Múltiplos esforços de desenvolvimento no kernel também requerem uma coordenação mais próxima do que os aplicativos em userland requerem.</para>

            <para>Os principais utilitários, conhecidos como userland, fornecem a interface que identifica o FreeBSD, interface do usuário, bibliotecas compartilhadas e interfaces externas para conectar clientes. Atualmente, 162 pessoas estão envolvidas no desenvolvimento e manutenção da userland, muitas delas sendo mantenedoras de sua própria parte do código. A manutenção será discutida na seção <xref linkend="role-maintainer"/>.</para>

            <para>A documentação é tratada por <xref linkend="sub-project-documentation"/> e inclui todos os documentos em torno do projeto FreeBSD, incluindo as páginas web. Durante o ano de 2004, 101 pessoas fizeram commits para o Projeto de Documentação do FreeBSD.</para>

            <para>Ports é a coleção de meta-dados necessários para fazer com que os pacotes de software sejam compilados corretamente no FreeBSD. Um exemplo de port é o port do navegador Mozilla. Ele contém informações sobre onde buscar o código fonte, quais correções aplicar e como o pacote deve ser instalado no sistema. Isso permite que ferramentas automatizadas busquem, criem e instalem o pacote. Até esta data, existem mais de 12600 ports disponíveis. <footnote>
                    <para>As estatísticas são geradas contando o número de entradas no arquivo buscado pelo portsdb até 1 de abril de 2005. portsdb é uma parte do port sysutils/portupgrade.</para>
                </footnote>, variando de servidores web a jogos, linguagens de programação e a maioria dos tipos de aplicativos que estão em uso em computadores modernos. Os ports serão discutidos em mais detalhes na seção <xref linkend="sub-project-ports"/>.</para>

        </chapter>

        <chapter xml:id="methodology-model">
            <title>Modelo de metodologia</title>

            <section xml:id="development-model"><title>Modelo de desenvolvimento</title>

                <para>Não existe um modelo definido para como as pessoas escrevem código no FreeBSD. No entanto, Niels Jørgenssen sugeriu um modelo de como o código escrito é integrado ao projeto.</para>

                <para>
                    <figure>
                        <title>O modelo de Jørgenssen para integração de mudanças</title>
                        <mediaobject><imageobject><imagedata fileref="maintenance"/></imageobject></mediaobject>
                    </figure>
                </para>

                <para>A <quote>versão de desenvolvimento</quote> é a branch (ramificação) FreeBSD-CURRENT ("-CURRENT") e a <quote>versão de produção </quote> é a branch (ramificação) FreeBSD-STABLE ("-STABLE") <citation><xref linkend="jorgensen2001"/></citation>.</para>

                <para>Este é um modelo para uma mudança e mostra que, após a codificação, os desenvolvedores buscam a revisão da comunidade e tentam integrá-la com seus próprios sistemas. Depois de integrar a mudança na versão de desenvolvimento, chamada FreeBSD-CURRENT, ela é testada por muitos usuários e desenvolvedores na comunidade FreeBSD. Depois de passar por testes suficientes, é feito o merge (aplicado) na versão de produção, chamada FreeBSD-STABLE. A menos que cada estágio seja concluído com êxito, o desenvolvedor precisa voltar e fazer modificações no código e reiniciar o processo. Integrar uma mudança com -CURRENT ou -STABLE é chamado de fazer um commit.</para>

                <para>Jørgensen descobriu que a maioria dos desenvolvedores do FreeBSD trabalha individualmente, o que significa que este modelo é usado em paralelo por muitos desenvolvedores nos diferentes esforços de desenvolvimento em andamento. Um desenvolvedor também pode estar trabalhando em várias alterações, de modo que, enquanto ele aguarda revisão ou que pessoas testem uma ou mais de suas alterações, ele pode estar escrevendo outra alteração.</para>

                <para>Como cada commit representa um incremento, este é um modelo massivamente incremental. Os commits são tão freqüentes que durante um ano <footnote>
                        <para>O período de 1º de janeiro de 2004 a 31 de dezembro de 2004 foi examinado para encontrar esse número.</para>
                    </footnote>, 85427 commits foram feitos, fazendo uma média diária de 233 commits.</para>

                <para>Dentro do processo <quote>code</quote> na figura de Jørgensen, cada programador tem seu próprio estilo de trabalho e segue seus próprios modelos de desenvolvimento. O suporte poderia muito bem ter sido chamado de <quote>desenvolvimento</quote>, pois inclui coleta e análise de requisitos, sistema e projeto detalhados, implementação e verificação. No entanto, a única saída desses estágios é o código-fonte ou a documentação do sistema.</para>


                <para>Da perspectiva de um modelo em etapas (como o modelo em cascata), os outros suportes podem ser vistos como verificação adicional e integração do sistema. Essa integração do sistema também é importante para ver se uma alteração é aceita pela comunidade. Até que o código seja "committed", o desenvolvedor é 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 não descobertas possam ser recuperadas), o tempo mínimo que um "commit" deve estar no -CURRENT antes de fazer o merge (aplicar o código) para -STABLE é de 3 dias. Esse merge (aplicação) é referido como um MFC (Merge From Current).</para>

                <para>É importante notar a palavra <quote>change (mudança)</quote>. A maioria dos commits não contém novos recursos radicais, mas são atualizações de manutenção.</para>

                <para>As únicas exceções desse modelo são correções de segurança e alterações nos recursos que estão obsoletos na branch (ramificação) -CURRENT. Nesses casos, as alterações podem ser "committed" diretamente na branch -STABLE.</para>

                <para>Além de muitas pessoas trabalhando no projeto, há muitos projetos relacionados ao Projeto FreeBSD. Estes são projetos desenvolvendo novos recursos, subprojetos ou projetos cujo resultado é incorporado ao FreeBSD <footnote>
                        <para>Por exemplo, o desenvolvimento da pilha Bluetooth começou como um subprojeto até ser considerada estável o suficiente para ser feito o merge (aplicado) na branch -CURRENT. Agora é parte do sistema principal do FreeBSD.</para>
                    </footnote>. Esses projetos se encaixam no Projeto FreeBSD, assim como os esforços regulares de desenvolvimento: eles produzem código que são integrados ao Projeto FreeBSD. No entanto, alguns deles (como Ports e Documentação) têm o privilégio de serem aplicáveis ​​às duas branchs (ramificações) ou de commit diretamente na -CURRENT e na -STABLE.</para>

                <para>Não há padrões para como o design deve ser feito, nem o design é coletado em um repositório centralizado. O design principal é o do 4.4BSD. <footnote>
                        <para>De acordo com Kirk McKusick, depois de 20 anos desenvolvendo sistemas operacionais UNIX, as interfaces são, na maioria das vezes, resolvidas. Portanto, não há necessidade de muito design. No entanto, novas aplicações do sistema e novo hardware levam a algumas implementações sendo mais benéficas do que aquelas que costumavam ser ter preferencia. Um exemplo é a introdução da navegação Web que tornou a conexão TCP/IP normal uma sequência curta de dados, em vez de um fluxo contínuo durante um período de tempo mais longo.</para>
                    </footnote> Como o design é parte do processo <quote>Code (Código)</quote> no modelo de Jørgenssen, cabe a cada desenvolvedor ou sub-projeto como isso deve ser feito. Mesmo que o projeto deva ser armazenado em um repositório central, a saída dos estágios do projeto seria de uso limitado, pois as diferenças de metodologias as desvalorizariam se de alguma forma interoperáveis. Para o design geral do projeto, o projeto conta com os subprojetos para negociar interfaces adequadas entre si, em vez de ditar interfaces.</para>

            </section>

            <section xml:id="release-branches">
                <title>Lançamento de versões (Release branches)</title>

                <para>Os lançamentos do FreeBSD são melhor ilustrados por uma árvore com muitas branches (ramificações), onde cada branch principal representa uma versão principal. Versões secundárias são representadas por branches das branches maiores.</para>

                <para>Na árvore de versões a seguir, as setas que seguem uma a outra em uma determinada direção representam uma branch. Caixas com linhas completas e encorporadas representam lançamentos oficiais. Caixas com linhas pontilhadas representam a branch de desenvolvimento nesse momento. Branchs de segurança são 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 ramificação). Por exemplo, em 4.0-RELEASE, a branch 4.0-CURRENT é dividida em 4-STABLE e 5.0-CURRENT. No 4.5-RELEASE, a branch retirou uma branch de segurança chamada RELENG_4_5.</para>

                <para>
                    <figure>
                        <title>A árvore de versões (release) do FreeBSD</title>
                        <mediaobject><imageobject><imagedata fileref="branches"/></imageobject></mediaobject>
                    </figure>
                </para>
                <para>A última versão -CURRENT é sempre referida como -CURRENT, enquanto a versão mais recente -STABLE é 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. <citation><xref linkend="freebsd-releng"/></citation></para>

                <para>Um <quote>lançamento principal</quote> é sempre feito a partir da branch -CURRENT. No entanto, a branch -CURRENT não precisa ser feito fork nesse momento, mas pode concentrar-se na estabilização. Um exemplo disso é que, após 3.0-RELEASE, 3.1-RELEASE também era uma continuação da branch -CURRENT, e -CURRENT não se tornou uma branch de desenvolvimento verdadeira até que esta versão fosse lançada e fosse feito o fork da branch 3-STABLE. Quando -CURRENT retorna para se tornar uma branch de desenvolvimento, ele só pode ser seguido por um lançamento principal. Prevê-se que seja feito o fork do 5-STABLE a partir da branch 5.0-CURRENT em torno da 5.3-RELEASE. Não é feito até que seja feito o fork da 5-STABLE, então a branch de desenvolvimento será marcada como 6.0-CURRENT.</para>

                <para>Uma <quote>versão secundária</quote> é feita a partir da branch -CURRENT após uma versão principal ou da branch -STABLE.</para>

                <para>Seguindo e incluindo, 4.3-RELEASE <footnote>
                        <para>A primeira versão onde isso aconteceu foi na 4.5-RELEASE, mas as branches de segurança foram criadas ao mesmo tempo para 4.3-RELEASE e 4.4-RELEASE.</para>
                    </footnote>, quando uma liberação secundária foi feita, ela se torna uma <quote>branch de segurança</quote>. Isso se destina a organizações que não desejam seguir a branch -STABLE e os possíveis recursos novos/alterados que oferece, mas que exigem um ambiente absolutamente estável, atualizando apenas para implementar atualizações de segurança. <footnote>
                        <para>Existe uma terminologia que se sobrepõe à palavra "stable (estável)", o que leva a alguma confusão. A branch -STABLE ainda é uma branch de desenvolvimento, cujo objetivo é ser útil para a maioria das pessoas. Se nunca for aceitável que um sistema obtenha alterações que não são anunciadas no momento em que é implantado, esse sistema deve executar uma branch de segurança.</para>
                    </footnote></para>

                <para>Cada atualização para uma branch de segurança é chamada de <quote>patchlevel (à nível de correção)</quote>. Para cada aprimoramento de segurança que é feito, o número de patchlevel é aumentado, tornando mais fácil para as pessoas rastrearem a branch para ver quais melhorias de segurança implementaram. Nos casos em que houve falhas graves de segurança, uma nova versão inteira pode ser feita a partir de uma branch de segurança. Um exemplo disso é a 4.6.2-RELEASE.</para>

            </section>

            <section xml:id="model-summary">
                <title>Resumo do modelo</title>

                <para>Para resumir, o modelo de desenvolvimento do FreeBSD pode ser visto como a seguinte árvore:</para>

                <para>
                    <figure>
                        <title>O modelo geral de desenvolvimento</title>
                        <mediaobject><imageobject><imagedata fileref="freebsd-code-model"/></imageobject></mediaobject>
                    </figure>
                </para>
                <para>A árvore do desenvolvimento do FreeBSD com esforços contínuos de desenvolvimento e integração contínua.</para>


                <para>A árvore simboliza as versões de lançamento com versões principais gerando novas branchs principais e versões secundárias sendo versões da branch principal. A branch superior é a branch -CURRENT, onde todo o desenvolvimento novo é integrado, e a branch -STABLE é a branch diretamente abaixo dela.</para>

                <para>Nuvens de esforços de desenvolvimento pairam sobre o projeto, onde os desenvolvedores usam os modelos de desenvolvimento que eles acham adequados. O produto de seu trabalho é então integrado em -CURRENT, onde ele é depurado paralelamente e finalmente é feito o merge (aplicado o código) do -CURRENT na -STABLE. As correções de segurança são feitos os merges (aplicado os códigos) da -STABLE para as branches de segurança.</para>

            </section>

        </chapter>

        <chapter xml:id="sect-hats">
            <title>Hats (Funções)</title>

            <para>Muitos committers têm uma área especial de responsabilidade. Esses papéis são chamados de hats. Esses títulos podem ser funções do projeto, como diretor de relações públicas ou mantenedor de uma determinada área do código. Como esse é um projeto em que as pessoas doam voluntariamente seu tempo livre, as pessoas com hats atribuídos nem sempre estão disponíveis. Eles devem, portanto, nomear um substituto que possa desempenhar o cargo de hat em sua ausência. A outra opção é ter o cargo ocupado por um grupo.</para>

            <para>Muitos desses hats não são formalizados. Hats formalizados têm uma carta indicando o propósito exato do hat, juntamente com seus privilégios e responsabilidades. A redação de tais cartas é uma nova parte do projeto e, portanto, ainda não foi concluída para todos os hats. Essas descrições de hats não são uma formalização, e sim um resumo da função com links para a carta quando disponíveis e endereços de contato.</para>


            <section xml:id="general-hats">
                <title>Hats Universais</title>

                <section xml:id="role-contributor" xreflabel="Contributor">
                    <title>Colaborador</title>
                    <para>Um Colaborador contribui para o projeto do FreeBSD como desenvolvedor, como autor, enviando relatórios de problemas ou contribuindo de outras formas para o progresso do projeto. Um colaborador não tem privilégios especiais no projeto do FreeBSD. <citation><xref linkend="freebsd-contributors"/></citation></para>
                </section>

                <section xml:id="role-committer" xreflabel="Committer">
                    <title>Committer</title>
                    <para>Uma pessoa que possui os privilégios necessários para adicionar seu código ou documentação ao repositório. Um committer fez um commit nos últimos 12 meses. <citation><xref linkend="freebsd-bylaws"/></citation> Um committer ativo é um committer que fez uma média de um commit por mês durante esse tempo.</para>

                    <para>Vale a pena notar que não existem barreiras técnicas para impedir que alguém, uma vez tendo ganho privilégios de commit para o main- ou um sub-projeto, de fazer commits em partes do código desse projeto que o committer não obteve permissão especificamente para modificar. No entanto, quando quiser fazer modificações em partes que um committer não tenha participado antes, ele deve ler os logs para ver o que aconteceu nesta área antes, e também ler o arquivo MAINTAINER para ver se o mantenedor desta parte tem quaisquer pedidos especiais sobre como as alterações no código devem ser feitas</para>
                </section>

                <section xml:id="role-core" xreflabel="Core team">
                    <title>Equipe principal (Core Team)</title>


                    <para>A equipe principal é 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 é o mediador final de decisões envolvendo o caminho que o projeto deve seguir. Em 1º de julho de 2004, o core consistia de 9 membros. As eleições são realizadas a cada dois anos.</para>

                </section>

                <section xml:id="role-maintainer" xreflabel="Maintainership">
                    <title>Maintainership</title>

                    <para>Maintainership significa que essa pessoa é responsável pelo que é permitido entrar nessa área do código e tem a palavra final caso ocorram discordâncias sobre o código. Isso envolve trabalho proativo destinado a estimular contribuições e trabalho reativo na revisão de commits.</para>

                    <para>Com o código fonte do FreeBSD vem o arquivo MAINTAINERS que contém um resumo de uma linha de como cada mantenedor gostaria que as contribuições fossem feitas. Ter este aviso e informações de contato permite que os desenvolvedores se concentrem no esforço de desenvolvimento, em vez de ficarem presos em uma correspondência lenta, caso o mantenedor não esteja disponível por algum tempo.</para>

                    <para>Se o mantenedor não estiver disponível por um período de tempo excessivamente longo, e outras pessoas fizerem uma quantidade significativa de trabalho, a manutenção pode ser trocada sem a aprovação do mantenedor. Isto é baseado na postura de que a manutenção deve ser demonstrada, não declarada.</para>

                    <para>A manutenção de uma parte específica do código é um hat que não é mantido como um grupo.</para>



                </section>

            </section>

            <section xml:id="official-hats">
                <title>Hats oficiais (Pessoas com funções definidas)</title>

                <para>Os hats oficiais no Projeto FreeBSD são hats que são mais ou menos formalizados e, principalmente, com funções administrativas. Eles têm autoridade e responsabilidade por sua área. A ilustração a seguir mostra as linhas de responsabilidade. Depois disso segue uma descrição de cada hat, incluindo quem os mantém.</para>

                <para>
                    <figure>
                        <title>Visão geral dos hats (funções) oficiais</title>
                        <mediaobject><imageobject><imagedata fileref="hats-overview"/></imageobject></mediaobject>
                    </figure>
                </para>

                <para>Todas as caixas consistem em grupos de committers, exceto as caixas pontilhadas onde os detentores não são necessariamente committers. Os círculos planificados são subprojetos e consistem em committers e pessoas que não são committers do projeto principal.</para>



                <section xml:id="role-doc-manager" xreflabel="Documentation                     project architect">
                    <title>Gerente de Projetos de Documentação</title>
                    <para><xref linkend="sub-project-documentation"/> é o arquiteto responsável por definir e acompanhar as metas de documentação para os committers no projeto Documentação.</para>

                    <para>Hat mantido pela: Equipe do DocEng <email>doceng@FreeBSD.org</email>. O <link xlink:href="https://www.freebsd.org/internal/doceng.html">Capitulo DocEng</link>.</para>
                </section>

                <section xml:id="role-postmaster" xreflabel="Postmaster">
                    <title>Postmaster</title>
                    <para>O Postmaster é responsável pelo envio correto do email para o endereço de email dos committers. Ele também é responsável por garantir que as listas de discussão funcionem e deve tomar medidas contra possíveis interrupções de correspondência, como filtros de vírus, spam e trolls.</para>
                    <para>Hat atualmente mantido pelo: Time Postmaster <email>postmaster@FreeBSD.org</email>.</para>
                </section>

                <section xml:id="role-release-coordination" xreflabel="Release Coordination">
                    <title>Coordenação de Release (Versões/Lançamentos)</title>

                    <para>As responsabilidades da Equipe de Engenharia de Release são <itemizedlist>
                            <listitem><para>Definir, publicar e seguir um cronograma de lançamento para releases (versões) oficiais</para></listitem>
                            <listitem><para>Documentando e formalizando procedimentos de engenharia da release</para></listitem>
                            <listitem><para>Criação e manutenção de branches de código</para></listitem>
                            <listitem><para>Coordenando com as equipes de Ports e Documentação para ter um conjunto atualizado de pacotes e documentação lançados com as novas releases</para></listitem>
                            <listitem><para>Coordenar com a equipe de segurança para que as versões pendentes não sejam afetadas por vulnerabilidades divulgadas recentemente.</para></listitem>
                        </itemizedlist> Mais informações sobre o processo de desenvolvimento estão disponíveis na seção <xref linkend="process-release-engineering"/>.</para>

                    <para xml:id="role-releng" xreflabel="Release Engineering Team">Hat mantido pela: Equipe de Engenharia de Release <email>re@FreeBSD.org</email>. O <link xlink:href="https://www.freebsd.org/releng/charter.html">Capitulo de Engenharia de Release</link>.</para>
                </section>

                <section xml:id="role-pr-cr" xreflabel="Public Relations &amp; Corporate Liaison">
                    <title>Relações Públicas &amp; Contato Corporativo</title>
                    <para>Relações Publicas &amp; As responsabilidades do contato corporativo são: <itemizedlist>
                            <listitem><para>Fazer declarações de imprensa quando acontecem coisas que são importantes para o projeto FreeBSD.</para></listitem>
                            <listitem><para>Ser a pessoa de contato oficial para corporações que estão trabalhando em estreita colaboração com o Projeto FreeBSD.</para></listitem>
                            <listitem><para>Tomar medidas para promover o FreeBSD tanto na comunidade Open Source quanto no mundo corporativo.</para></listitem>
                            <listitem><para>Lidar com a lista de discussão <quote>freebsd-advocacy</quote>.</para></listitem>
                        </itemizedlist></para>

                    <para>Este hat não está atualmente ocupado.</para>
                </section>

                <section xml:id="role-security-officer" xreflabel="Security Officer">
                    <title>Oficial de segurança</title>
                    <para>A principal responsabilidade do Security Officer (Oficial de Segurança) é coordenar a troca de informações com outras pessoas na comunidade de segurança e no projeto FreeBSD. O agente de segurança também é responsável por tomar medidas quando os problemas de segurança são relatados e promover um comportamento proativo de desenvolvimento quando se trata de segurança.</para>
                    <para>Devido ao receio de que informações sobre vulnerabilidades possam vazar para pessoas com intenções maliciosas antes que um patch esteja disponível, apenas o Oficial de Segurança, composto por um oficial, um adjunto e dois membros do <xref linkend="role-core"/>, recebe informações confidenciais sobre problemas de segurança. No entanto, para criar ou implementar um patch, o Oficial de Segurança tem a equipe de segurança oficial <email>security-team@FreeBSD.org</email> para ajudar no trabalho.</para>
                </section>

                <section xml:id="role-repo-manager" xreflabel="Source Repository Manager">
                    <title>Gerenciador do Repositório de Código Fonte</title>
                    <para>O Source Repository Manager (Gerenciador do Repositório de Código Fonte) é o único que tem permissão para modificar diretamente o repositório sem usar a ferramenta <xref linkend="tool-svn"/>. É sua responsabilidade garantir que os problemas técnicos que surgem no repositório sejam resolvidos rapidamente. O gerenciador do repositório de código fonte possui a autoridade para voltar commits, se isso for necessário para resolver um problema técnico do SVN.</para>
                    <para>Hat mantido pelo: Source Repository Manager <email>clusteradm@FreeBSD.org</email>.</para>
                </section>

                <section xml:id="role-election-manager" xreflabel="Election Manager">
                    <title>Gerente de Eleições</title>
                    <para>O Gerente de Eleições é responsável pelo processo <xref linkend="process-core-election"/>. O gerente é responsável por executar e manter o sistema eleitoral, e é a autoridade final caso eventos imprevistos menores ocorram no processo eleitoral. Grandes imprevistos devem ser discutidos com o <xref linkend="role-core"/></para>
                    <para>Hat realizado apenas durante as eleições.</para>
                </section>

                <section xml:id="role-webmaster" xreflabel="Web site Management">
                    <title>Gerenciamento de sites</title>
                    <para>O hat Web site Management é responsável por coordenar o lançamento de páginas Web atualizadas em espelhos ao redor do mundo, pela estrutura geral do site principal e pelo sistema em que está sendo executado. O gerenciamento precisa coordenar o conteúdo com <xref linkend="sub-project-documentation"/> e atua como mantenedor da árvore <quote>www</quote>.</para>
                    <para>Hat mantido pelos: Webmasters do FreeBSD <email>www@FreeBSD.org</email>.</para>
                </section>

                <section xml:id="role-ports-manager" xreflabel="Ports Manager">
                    <title>Gerente de Ports</title>
                    <para>O Gerente de Ports atua como uma conexão entre <xref linkend="sub-project-ports"/> e o projeto principal, e todas as solicitações do projeto devem ir para o gerente de ports.</para>

                    <para>Hat mantido pela: Equipe de Gerenciamento de Ports <email>portmgr@FreeBSD.org</email>. O <link xlink:href="https://www.freebsd.org/portmgr/charter.html">Capitulo Portmgr</link>.</para>
                </section>

                <section xml:id="role-standards" xreflabel="Standards">
                    <title>Padrões</title>
                    <para>O Standards (Padrões) é responsável por garantir que o FreeBSD cumpra com os padrões com os quais está comprometido, mantendo-se atualizado sobre o desenvolvimento desses padrões e notificando os desenvolvedores do FreeBSD sobre mudanças importantes que lhes permitam assumir um papel proativo e diminuir o tempo entre atualização de padrões e complacência do FreeBSD.</para>

                    <para>Hat atualmente mantido por: Garrett Wollman <email>wollman@FreeBSD.org</email>.</para>
                </section>

                <section xml:id="role-core-secretary" xreflabel="Core Secretary">
                    <title>Secretário do Core (do time do Core)</title>
                    <para>A principal responsabilidade do Secretário do Core é redigir os drafts e publicar os Relatórios finais do Core. O secretário também mantém a agenda central, assegurando assim que nenhuma bola seja descartada sem solução.</para>
                    <para>Hat atualmente mantido por: Joseph Mingrone <email>jrm@FreeBSD.org</email>.</para>
                </section>

                <section xml:id="role-bugmeister" xreflabel="Bugmeister">
                    <title>Bugmeister</title>
                    <para>O Bugmeister é responsável por garantir que o banco de dados de manutenção esteja em ordem, que as entradas sejam categorizadas corretamente e que não existam entradas inválidas.</para>
                    <para>Hat atualmente mantido pelo: Time Bugmeister <email>bugmeister@FreeBSD.org</email>.</para>
                </section>

                <section xml:id="role-donations" xreflabel="Donations Liaison Officer">
                    <title>Oficial de Contratos de doações</title>
                    <para>A tarefa do oficial de contratos de doações é combinar os desenvolvedores com necessidades com pessoas ou organizações dispostas a fazer uma doação. A carta de ligação de doações está disponível <link xlink:href="https://www.freebsd.org/donations/">aqui</link></para>
                    <para>Hat mantida pelo: Escritório de Contratos de Doações <email>donations@FreeBSD.org</email>.</para>
                </section>

                <section xml:id="role-admin" xreflabel="Admin">
                    <title>Admin</title>
                    <para>(Também chamado de <quote>Administrador de Cluster do FreeBSD</quote>)</para>

                    <para>A equipe administrativa consiste nas pessoas responsáveis ​​por administrar os computadores dos quais o projeto depende, para que seu trabalho distribuído e comunicação sejam sincronizados. Consiste principalmente naquelas pessoas que têm acesso físico aos servidores.</para>

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

                </section>



            </section>

            <section xml:id="proc-depend-hats">
                <title>Hats dependentes de processo</title>

                <section xml:id="role-problem-originator" xreflabel="Report originator">
                    <title>Criador do relatório</title>
                    <para>A pessoa originalmente responsável pelo preenchimento de um Relatório de Problemas.</para>
                </section>


                <section xml:id="role-bugbuster" xreflabel="Bugbuster">
                    <title>Bugbuster</title>
                    <para>Uma pessoa que irá encontrar a pessoa certa para resolver o problema, ou fechar o PR se for uma duplicata ou não uma interessante.</para>
                </section>

                <section xml:id="role-mentor" xreflabel="Mentor">
                    <title>Mentor</title>
                    <para>Um mentor é um committer que assume a responsabilidade de introduzir um novo committer no projeto, tanto em termos de garantir que a nova configuração de committers seja válida, que o novo committer conheça as ferramentas disponíveis necessárias em seu trabalho quanto que o novo committer saiba o que se espera dele em termos de comportamento.</para>
                </section>
                <section xml:id="role-vendor" xreflabel="Vendor">
                    <title>Fornecedor</title>
                    <para>A(s) pessoa(s) ou organização de quem vem o código externo e para quem os patches são enviados.</para>
                </section>

                <section xml:id="role-reviewer" xreflabel="Reviewer">
                    <title>Revisores</title>
                    <para>Pessoas na lista de discussão em que a solicitação de revisão é postada.</para>
                </section>
            </section>


        </chapter>

        <chapter xml:id="model-processes" xreflabel="processes">
            <title>Processos</title>

            <para>A seção a seguir descreverá os processos definidos do projeto. Questões que não são tratadas por esses processos acontecem em uma base ad-hoc com base no que era costume fazer em casos semelhantes.</para>

            <section xml:id="proc-addrem-committer">
                <title>Adicionando novos committers  e removendo committers  antigos </title>

                <para>O Core team tem a responsabilidade de fornecer e remover os privilégios de commit aos colaboradores. Isso só pode ser feito por meio de votação na lista de discussão do core. Os subprojetos de ports e documentação podem conceder privilégios de commit a pessoas que trabalham nesses projetos, mas até o momento não removeram esses privilégios.</para>

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

                <para>Se a área de interesse particular para o desenvolvedor potencialmente se sobrepuser à área de manutenção de outros committers, a opinião desses commiters mantenedores é solicitada. No entanto, é frequentemente esse committer que recomenda o desenvolvedor.</para>

                <para>Quando um colaborador recebe status de committer, ele recebe um mentor. O committer que recomendou o novo committer, no caso geral, assumirá a responsabilidade de ser o novo mentor dos committers.</para>

                <para>Quando um colaborador recebe seu commit bit, um e-mail assinado <xref linkend="tool-pgp"/> é enviado de <xref linkend="role-core-secretary"/>, <xref linkend="role-ports-manager"/> ou nik@freebsd.org para ambos admins@freebsd.org, o mentor designado, o novo committer e o core confirmando a aprovação de uma nova conta. O mentor então reúne uma senha, a chave pública <xref linkend="tool-ssh2"/> e a chave PGP do novo committer e as envia para <xref linkend="role-admin"/>. Quando a nova conta é criada, o mentor ativa o commit bit e orienta o novo committer pelo resto do processo inicial.</para>

                <para>
                    <figure>
                        <title>Resumo do processo: adicionando um novo committer</title>
                        <mediaobject><imageobject><imagedata fileref="proc-add-committer"/></imageobject></mediaobject>
                    </figure>
                </para>

                <para>Quando um colaborador envia uma parte do código, o committer que recebe pode optar por recomendar que o colaborador receba privilégios de commit. Se ele recomendar isso para o core, eles irão votar essa recomendação. Se eles votarem a favor, um mentor é 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 está pronto para fazer seu primeiro commit. Por tradição, isso é feito adicionando seu nome à lista de committers.</para>

                <para>Lembre-se de que um committer é considerado alguém que tenha feito algum commit de código nos últimos 12 meses. No entanto, somente após 18 meses de inatividade terem se passado, os privilégios de commit são qualificados para serem revogados. <citation><xref linkend="freebsd-expiration-policy"/></citation> Não há, no entanto, procedimentos automáticos para fazer isso. Para reações a consentimentos de privilégios de commit não acionados pelo tempo, veja a <link linkend="process-reactions">seção 1.5.8</link>.</para>

                <para>
                    <figure>
                        <title>Resumo do processo: removendo um committer</title>
                        <mediaobject><imageobject><imagedata fileref="proc-rm-committer"/></imageobject></mediaobject>
                    </figure>
                </para>

                <para>Quando o Core decide limpar a lista de committers, eles checam quem não fez um commit nos últimos 18 meses. Os committers que não fizeram isso têm seus commit bit revogados.</para>

                <para>Também é possível que os committers solicitem que seu commit bit seja retirado se, por alguma razão, eles não estiverem mais se comprometendo ativamente com o projeto. Nesse caso, ele também pode ser restaurado posteriormente pelo core, caso o committer peça.</para>

                <para>Funções neste processo: <orderedlist>
                        <listitem><para>
                                <xref linkend="role-core"/>
                        </para></listitem>
                        <listitem><para>
                                <xref linkend="role-contributor"/>
                        </para></listitem>
                        <listitem><para>
                                <xref linkend="role-committer"/>
                        </para></listitem>
                        <listitem><para>
                                <xref linkend="role-maintainer"/>
                        </para></listitem>
                        <listitem><para>
                                <xref linkend="role-mentor"/>
                        </para></listitem>
                    </orderedlist></para>

                <para>
                    <citation><xref linkend="freebsd-bylaws"/></citation>
                    <citation><xref linkend="freebsd-expiration-policy"/></citation>
                    <citation><xref linkend="freebsd-new-account"/></citation>
                </para>

            </section>

            <section xml:id="committing">
                <title>Enviando código para o projeto (Committing code)</title>

                <para>O processo de commit de um código novo ou modificado é um dos processos mais frequentes no projeto FreeBSD e geralmente acontece muitas vezes ao dia. O commit do código só pode ser feito por um <quote>committer</quote>. Committers aplicam código escrito por eles mesmos, código enviado a eles ou código enviado através de um <link linkend="model-pr">relatório de problemas</link>.</para>

                <para>Quando o código é escrito pelo desenvolvedor que é não trivial, ele deve procurar uma revisão de código da comunidade. Isso é feito enviando e-mails para a lista relevante solicitando a revisão. Antes de enviar o código para revisão, ele deve garantir que ele seja compilado corretamente com a árvore inteira e que todos os testes relevantes sejam executados. Isso é chamado <quote>teste de pré-commit</quote>. Quando o código contribuído é recebido, ele deve ser revisado pelo committer e testado da mesma maneira.</para>

                <para>Quando uma alteração é "committed" em uma parte do código fonte que foi contribuída por um <xref linkend="role-vendor"/> externo, o mantenedor deve garantir que o patch seja repassado ao fornecedor. Isso está de acordo com a filosofia de código aberto e facilita a sincronização com os projetos externos, pois os patches não precisam ser reaplicados sempre que uma nova versão é feita.</para>

                <para>Depois que o código estiver disponível para revisão e nenhuma alteração adicional for necessária, o código será "committed" na branch de desenvolvimento, -CURRENT. Se a alteração se aplicar também à branch -STABLE ou às outras branches, uma contagem regressiva de um <quote>Merge From Current</quote> ("MFC") será definida pelo committer. Após o número de dias que o committer escolheu ao configurar o MFC, um email será enviado automaticamente ao committer, lembrando-o de enviá-lo para a branch -STABLE (e possivelmente também para branches de segurança). Apenas alterações críticas de segurança devem ser aplicadas a branch de segurança.</para>

                <para>Atrasar o commit para -STABLE e outras branches permite <quote>depuração paralela</quote> onde o código "committed" é testado em uma ampla gama de configurações. Isso faz alterações no -STABLE para conter menos falhas e, assim, dar seu nome à branch.</para>

                <para>
                    <figure>
                        <title>Resumo do processo: um committer aplica o código</title>
                        <mediaobject><imageobject><imagedata fileref="proc-commit"/></imageobject></mediaobject>
                    </figure>
                </para>

                <para>Quando um committer escreveu um pedaço de código e quer fazer o seu commit, ele primeiro precisa determinar se é trivial o suficiente entrar sem uma análise prévia ou se deve ser revisado pela comunidade de desenvolvedores. Se o código é trivial ou foi revisado e o committer não é o mantenedor, ele deve consultar o mantenedor antes de continuar. Se o código for contribuído por um fornecedor externo, o mantenedor deve criar um patch que seja enviado de volta ao fornecedor. O código é então confirmado e implantado pelos usuários. Caso encontrem problemas com o código, isso será relatado e o committer poderá voltar a escrever um patch. Se um fornecedor for afetado, ele pode optar por implementar ou ignorar o patch.</para>

                <para>
                    <figure>
                        <title>Resumo do processo: um colaborador envia o código</title>
                        <mediaobject><imageobject><imagedata fileref="proc-contrib"/></imageobject></mediaobject>
                    </figure>
                </para>

                <para>A diferença quando um colaborador faz uma contribuição de código é que ele envia o código através da interface do Bugzilla. Este relatório é escolhido pelo mantenedor que revisa o código e faz o seu commit.</para>

                <para>Hats incluídos neste processo são: <orderedlist>
                        <listitem><para>
                                <xref linkend="role-committer"/>
                        </para></listitem>
                        <listitem><para>
                                <xref linkend="role-contributor"/>
                        </para></listitem>
                        <listitem><para>
                                <xref linkend="role-vendor"/>
                        </para></listitem>
                        <listitem><para>
                                <xref linkend="role-reviewer"/>
                        </para></listitem>
                    </orderedlist></para>

                <para>
                    <citation><xref linkend="freebsd-committer"/></citation>
                    <citation><xref linkend="jorgensen2001"/></citation>
                </para>

            </section>

            <section xml:id="process-core-election" xreflabel="Core election">
                <title>Eleição do Core</title>

                <para>As eleições do core são realizadas pelo menos a cada dois anos. <footnote>
                        <para>A primeira eleição do core foi realizada em setembro de 2000</para>
                    </footnote> Nove membros do core são eleitos. Novas eleições serão realizadas se o número de membros do core ficar abaixo de sete. Novas eleições também podem ser realizadas se pelo menos 1/3 dos committers ativos exigirem isso.</para>

                <para>Quando uma eleição é realizada, o core anuncia isso com pelo menos 6 semanas de antecedência e nomeia um gerente eleitoral para dirigir as eleições.</para>

                <para>Somente committers podem ser eleitos para o core. Os candidatos precisam apresentar sua candidatura pelo menos uma semana antes do início das eleições, mas podem refinar suas declarações até o início da votação. Eles são apresentados na <link xlink:href="http://election.uk.freebsd.org/candidates.html">lista de candidatos</link>. Ao escrever suas declarações eleitorais, os candidatos devem responder a algumas perguntas padrões submetidas pelo gerente eleitoral.</para>

                <para>Durante as eleições, a regra que um committer deve ter feito um commit durante os 12 meses passados ​​é seguida estritamente. Apenas esses committers estão qualificados para votar.</para>

                <para>Ao votar, o committer pode votar uma vez em apoio de até nove candidatos. A votação é feita durante um período de quatro semanas com lembretes sendo postados na lista de discussão <quote>developers</quote> que está disponível para todos os committers.</para>

                <para>Os resultados das eleições são divulgados uma semana após o término da eleição, e a nova equipe do core toma posse uma semana após o lançamento dos resultados.</para>

                <para>Se houver um empate de votação, isso será resolvido pelos novos membros do core, eleitos sem ambiguidade.</para>

                <para>Votos e declarações de candidatos são arquivados, mas os arquivos não estão publicamente disponíveis.</para>

                <para>
                    <figure>
                        <title>Resumo do processo: Eleições do Core</title>
                        <mediaobject><imageobject><imagedata fileref="proc-elections"/></imageobject></mediaobject>
                    </figure>
                </para>

                <para>O Core anuncia a eleição e seleciona um gerente eleitoral. Ele prepara as eleições e, quando estiver pronto, os candidatos podem anunciar suas candidaturas através da apresentação de suas declarações. Os committers então votam. Após o término da votação, os resultados das eleições são anunciados e a nova equipe do core toma posse.</para>

                <para>Hats nas eleições do Core são: <itemizedlist>
                        <listitem><para>
                                <xref linkend="role-core"/>
                        </para></listitem>
                        <listitem><para>
                                <xref linkend="role-committer"/>
                        </para></listitem>
                        <listitem><para>
                                <xref linkend="role-election-manager"/>
                        </para></listitem>

                    </itemizedlist></para>


                <para>
                    <citation><xref linkend="freebsd-bylaws"/></citation>
                    <citation><xref linkend="bsd-election2002"/></citation>
                    <citation><xref linkend="freebsd-election"/></citation>
                </para>
            </section>

            <section xml:id="new-features">
                <title>Desenvolvimento de novos recursos</title>

                <para>Dentro do projeto existem subprojetos que estão trabalhando em novos recursos. Esses projetos geralmente são feitos por uma pessoa <citation><xref linkend="jorgensen2001"/></citation>. Todo projeto é livre para organizar o desenvolvimento como achar melhor. No entanto, quando é feito o merge do projeto (aplicado) à branch -CURRENT, ele deve seguir as diretrizes do projeto. Quando o código foi bem testado na branch -CURRENT e considerado estável o suficiente e relevante para a branch -STABLE, ele é mergeado à branch -STABLE.</para>

                <para>Os requisitos do projeto são fornecidos como o desenvolvedor desejar, solicitações da comunidade em termos de solicitações diretas por correio, relatórios de problemas, financiamento comercial para o desenvolvimento de recursos ou contribuições da comunidade científica. Os desejos que estão sob a responsabilidade de um desenvolvedor são dados àquele desenvolvedor que prioriza seu tempo entre o pedido e seus desejos. Uma maneira comum de fazer isso é manter uma lista de tarefas mantidas pelo projeto. Itens que não são de responsabilidade de alguém são coletados em TODO-lists, a menos que alguém seja voluntário para assumir a responsabilidade. Todos os pedidos, sua distribuição e acompanhamento são tratados pela ferramenta <xref linkend="tool-bugzilla"/>.</para>

                <para>A análise de requisitos acontece de duas maneiras. As solicitações que entram são discutidas em listas de discussão, tanto dentro do projeto principal quanto no subprojeto ao qual a solicitação pertence ou é gerada pela solicitação. Além disso, os desenvolvedores individuais no subprojeto avaliarão a viabilidade das solicitações e determinarão a priorização entre elas. Além dos arquivos das discussões que ocorreram, nenhum resultado é criado por essa fase que é incorporada ao projeto principal.</para>

                <para>Como os pedidos são priorizados pelos desenvolvedores individuais com base em fazer o que eles acham interessante, necessário ou são financiados para fazer, não há estratégia geral ou priorização de solicitações que considerem como requisitos e acompanhamento de sua implementação correta. No entanto, a maioria dos desenvolvedores tem uma visão compartilhada de quais problemas são mais importantes e podem solicitar diretrizes da equipe de engenharia de release.</para>

                <para>A fase de verificação do projeto é dupla. Antes de fazer o commit do código para a branch atual, os desenvolvedores solicitam que seu código seja revisado por seus pares. Esta revisão é, na maior parte, feita por testes funcionais, mas a revisão de código também é importante. Quando o código é "committed" para a branch, um teste funcional mais amplo ocorrerá, o que pode acionar mais revisões de código e depuração, caso o código não se comporte conforme o esperado. Esta segunda forma de verificação pode ser considerada como verificação estrutural. Embora os próprios subprojetos possam escrever testes formais, como testes de unidade, eles geralmente não são coletados pelo projeto principal e geralmente são removidos antes que o código seja "committed" na branch atual. <footnote>
                        <para>No entanto, mais e mais testes são executados ao construir o sistema (<quote>make world</quote>). Esses testes são, no entanto, uma adição muito nova e ainda não foi criada nenhuma estrutura sistemática para esses testes.</para>

                    </footnote></para>

            </section>


            <section xml:id="model-maintenance" xreflabel="maintenance">
                <title>Manutenção</title>

                <para>É uma vantagem para o projeto que para cada área do código fonte tenha pelo menos uma pessoa que conheça bem essa área. Algumas partes do código designaram mantenedores. Outros têm mantenedores de fato, e algumas partes do sistema não possuem mantenedores. O mantenedor é geralmente uma pessoa do subprojeto que escreveu e integrou o código, ou alguém que o portou da plataforma para a qual foi escrito. <footnote>
                        <para>sendmail e named são exemplos de código que foi feito merge (aplicado o código) de outras plataformas.</para>
                    </footnote> O trabalho do mantenedor é garantir que o código esteja em sincronia com o projeto de onde vem o código, se for um código contribuído, e aplicar correções enviadas pela comunidade ou escrever correções em problemas descobertos.</para>

                <para>A maior parte do trabalho que é colocado no projeto FreeBSD é a manutenção. <citation><xref linkend="jorgensen2001"/></citation> fez uma figura mostrando o ciclo de vida das mudanças.</para>

                <para>
                    <figure>
                        <title>O modelo de Jørgenssen para integração de mudanças</title>
                        <mediaobject><imageobject><imagedata fileref="maintenance"/></imageobject></mediaobject>
                    </figure>
                </para>

                <para>Aqui, <quote>desenvolvimento de release (versão)</quote> refere-se a branch -CURRENT, enquanto o <quote>release em produção</quote> refere-se a branch -STABLE. O <quote>teste de pré-commit</quote> é o teste funcional feito por desenvolvedores de peers quando solicitado a fazê-lo ou a testar o código para determinar o status do subprojeto. <quote>Debug paralelo</quote> é o teste funcional que pode acionar mais revisões e debugs quando o código é incluído na branch -CURRENT.</para>


                <para>A partir desta escrita, havia 269 committers no projeto. Quando eles fazem o commit de uma mudança em uma branch, isso constitui uma nova release (versão). É muito comum os usuários da comunidade rastrearem uma determinada branch. A existência imediata de uma nova release torna as mudanças amplamente disponíveis imediatamente e permite um feedback rápido da comunidade. Isso também dá à comunidade o tempo de resposta que eles esperam em questões que são importantes para eles. Isso torna a comunidade mais engajada e, assim, permite mais e melhores feedbacks que estimulam mais a manutenção e, por fim, deverá criar um produto melhor.</para>

                <para>Antes de fazer alterações no código em partes da árvore que tem um histórico desconhecido para o committer, o committer é obrigado a ler os logs de commit para ver porque certos recursos são implementados da maneira que eles estão, para não cometer erros que foram anteriormente pensado ou resolvido.</para>

            </section>

            <section xml:id="model-pr">
                <title>Relatório de Problemas</title>

                <para>Antes do FreeBSD 10, o FreeBSD incluía uma ferramenta de relatório de problemas chamada <command>send-pr</command>. Os problemas incluem relatórios de bugs, solicitações de recursos, aprimoramentos de recursos e avisos de novas versões de software externo incluídas no projeto. Embora o <command>send-pr</command> esteja disponível, os usuários e desenvolvedores são incentivados a enviar problemas usando nosso <link xlink:href="https://bugs.freebsd.org/submit/">formulário de relatório de problemas</link>.</para>

                <para>Os relatórios de problemas são enviados para um endereço de e-mail, onde são inseridos no banco de dados de manutenção de Relatórios de Problemas. Um <xref linkend="role-bugbuster"/> classifica o problema e o envia ao grupo ou mantenedor correto dentro do projeto. Depois que alguém assume a responsabilidade pelo relatório, o relatório estará sendo analisado. Esta análise inclui verificar o problema e pensar em uma solução para o problema. Muitas vezes é necessário feedback do criador do relatório ou até mesmo da comunidade do FreeBSD. Uma vez que um patch para o problema é feito, o criador pode ser solicitado a testá-lo. Finalmente, o patch de trabalhado é integrado ao projeto e documentado, se aplicável. Ele passa pelo ciclo de manutenção regular, conforme descrito na seção <xref linkend="model-maintenance"/>. Estes são os estados em que um relatório de problemas pode estar: aberto, analisado, feedback, corrigido, suspenso e fechado. O estado suspenso é para quando um progresso adicional não é possível devido à falta de informação ou quando a tarefa exigiria tanto trabalho que ninguém está trabalhando nela no momento.</para>

                <para>
                    <figure>
                        <title>Resumo do processo: Relatório de Pproblemas</title>
                        <mediaobject><imageobject><imagedata fileref="proc-pr"/></imageobject></mediaobject>
                    </figure>
                </para>

                <para>Um problema é relatado pelo criador do relatório. É então classificado por um bugbuster e entregue ao mantenedor correto. Ele verifica o problema e discute o problema com o criador até que ele tenha informações suficientes para criar um patch de trabalhado. Este patch é então "committed" e o relatório de problemas é fechado.</para>


                <para>As funções incluídas neste processo são: <orderedlist>
                        <listitem><para>
                                <xref linkend="role-problem-originator"/>
                        </para></listitem>
                        <listitem><para>
                                <xref linkend="role-maintainer"/>
                        </para></listitem>
                        <listitem><para>
                                <xref linkend="role-bugbuster"/>
                        </para></listitem>
                    </orderedlist></para>

                <para><citation><xref linkend="freebsd-handle-pr"/></citation>. <citation><xref linkend="freebsd-send-pr"/></citation></para>

            </section>

            <section xml:id="process-reactions" xreflabel="Reacting to misbehavior">
                <title>Reagindo ao mau comportamento</title>

                <para><citation><xref linkend="freebsd-committer"/></citation> tem um número de regras que os committers devem seguir. No entanto, acontece que essas regras são quebradas. As seguintes regras existem para poder reagir ao mau comportamento. Eles especificam quais ações resultarão e em quanto tempo será uma suspensão dos privilégios de commit do committer. <itemizedlist>
                        <listitem><para>Fazer um commit durante o code freeze (tempo de congelamento de código) sem a aprovação da equipe dos Engenheiros de Release - 2 dias</para></listitem>
                        <listitem><para>Fazer um commit em uma branch de segurança sem aprovação - 2 dias</para></listitem>
                        <listitem><para>Guerras por causa de commit - 5 dias para todas as partes participantes</para></listitem>
                        <listitem><para>Comportamento deselegante ou inapropriado - 5 dias</para></listitem>
                    </itemizedlist><citation><xref linkend="ref-freebsd-trenches"/></citation></para>

                <para>Para que as suspensões sejam eficientes, qualquer membro do core pode implementar uma suspensão antes de discuti-la na lista de discussão <quote>core</quote>. Os infratores reincidentes podem, com um voto de 2/3 do core, receber penalidades mais duras, incluindo a remoção permanente dos privilégios de commit. (No entanto, este último é sempre visto como um último recurso, devido à sua tendência inerente de criar controvérsia). Todas as suspensões são postadas na lista de discussão <quote>developers</quote>, uma lista disponível apenas para committers.</para>

                <para>É importante que você não possa ser suspenso por cometer erros técnicos. Todas as penalidades vêm de quebrar a etiqueta social.</para>

                <para>Hats envolvidos neste processo: <itemizedlist>
                        <listitem><para>
                                <xref linkend="role-core"/>
                        </para></listitem>
                        <listitem><para>
                                <xref linkend="role-committer"/>
                        </para></listitem>
                    </itemizedlist></para>
            </section>


            <section xml:id="process-release-engineering" xreflabel="release engineering">
                <title>Engenharia de Release (Versão)</title>

                <para>O projeto FreeBSD possui uma equipe de Engenharia de Release com um engenheiro de release principal responsável por criar versões do FreeBSD que podem ser trazidas para a comunidade de usuários através da rede ou vendidas em lojas de varejo. Como o FreeBSD está disponível em várias plataformas e as releases para as diferentes arquiteturas são disponibilizadas ao mesmo tempo, a equipe tem uma pessoa responsável por cada arquitetura. Além disso, há cargos na equipe responsável por coordenar os esforç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 é indicado.</para>

                <para>Quando uma versão está chegando, o projeto do FreeBSD muda de forma um pouco. Um cronograma de lançamento é feito contendo congelamentos de recursos e códigos, liberação de versões intermediárias e a versão final. Um congelamento de recursos significa que nenhum novo recurso pode ser aplicado na branch sem o consentimento explícito dos engenheiros de release. O congelamento de código significa que nenhuma alteração no código (como bugs-fixes) pode ser aplicada sem o consentimento explícito dos engenheiros de release. Esse congelamento de recurso e código é conhecido como estabilização. Durante o processo de lançamento, o engenheiro de release tem a autoridade total para reverter para versões mais antigas de código e, assim, "desfazer" as alterações, caso ache que as alterações não são adequadas para serem incluídas na versão.</para>

                <para>Existem três tipos diferentes de releases: <orderedlist>
                        <listitem><para>Releases .0 são o primeiro lançamento de uma versão principal. Eles são branches da branch -CURRENT e têm um ciclo de engenharia de release significativamente maior devido à natureza instável da branch -CURRENT</para></listitem>
                        <listitem><para>As versões .X são releases da branch -STABLE. Elas estão programadas para sair a cada 4 meses.</para></listitem>
                        <listitem><para>As versões .X.Y são versões de segurança que seguem a branch .X. Eles saem somente quando correções de segurança suficientes foram feito aplicadas desde o último release nessa branch. Novos recursos raramente são incluídos e a equipe de segurança está muito mais envolvida nesses recursos do que em releases regulares.</para></listitem>
                    </orderedlist></para>

                <para>Para releases da branch -STABLE, o processo de release inicia 45 dias antes da data de lançamento prevista. Durante a primeira fase, os primeiros 15 dias, os desenvolvedores aplicam as alterações que tiveram no -CURRENT e que desejam ter na versão para a branch do release. Quando esse período terminar, o código entra em um congelamento de código de 15 dias, no qual apenas correções de bugs, atualizações de documentação, correções relacionadas à segurança e pequenas alterações de driver de dispositivo são permitidas. Essas alterações devem ser aprovadas pelo engenheiro de release com antecedência. No início do último período de 15 dias, um candidato a reçease é criado para testes generalizados. É menos provável que as atualizações sejam permitidas durante esse período, exceto por importantes correções de bugs e atualizações de segurança. Neste período final, todos os releases são considerados candidatos a release. No final do processo de release, uma release é criada com o novo número da versão, incluindo distribuições binárias em sites e a criação de imagens em CD-ROM. No entanto, a release não é considerado "realmente liberado" até que uma mensagem <xref linkend="tool-pgp"/>-assinada afirmando exatamente isso, seja enviada para a lista de discussão freebsd-announce; Qualquer coisa rotulada como "release" antes disso pode estar em processo e sujeita a alterações antes do envio da mensagem assinada pelo PGP. <footnote>
                        <para>Muitos fornecedores comerciais usam essas imagens para criar CD-ROMs que são vendidos em lojas de varejo.</para>
                    </footnote>.</para>

                <para>Os lançamentos da branch -CURRENT (ou seja, todas as releases que terminam com <quote>.0</quote>) são muito semelhantes, mas com o dobro do prazo. Começa 8 semanas antes do lançamento com o anúncio da linha do tempo da release. Duas semanas após o processo de release, o congelamento de recursos é iniciado e os ajustes de desempenho devem ser mantidos ao mínimo. Quatro semanas antes do lançamento, uma versão beta oficial é disponibilizada. Duas semanas antes do lançamento, o código é oficialmente transformado em uma nova versão. Esta versão recebe status de release candidate e, como na engenharia de release do -STABLE, o congelamento de código do release candidate é endurecido. No entanto, o desenvolvimento na branch principal de desenvolvimento pode continuar. Além dessas diferenças, os processos de engenharia de release são semelhantes.</para>

                <para>Releases .0 vão para o seu própria branch e são destinadas principalmente a adoções primárias. A branch passa por um período de estabilização, e não é até que o <xref linkend="role-releng"/> decida que as demandas de estabilidade foram satisfeitas e de que o branch se torna -STABLE e -CURRENT segmenta a próxima versão principal. Enquanto isso para a maioria tem sido com versões .1, isso não é uma demanda.</para>

                <para>A maioria das versões são feitas quando uma determinada data é considerada longa o suficiente desde o lançamento anterior. Uma data destino é definida para ter grandes releases a cada 18 meses e versões menores a cada 4 meses. A comunidade de usuários deixou bem claro que a segurança e a estabilidade não podem ser sacrificadas por prazos auto impostos e datas de lançamento desejadas. Por um lapso de tempo para não se tornar muito longo no que diz respeito a questões de segurança e estabilidade, é necessária uma disciplina extra ao aplicar alterações na -STABLE.</para>


                <para>
                    <figure>
                        <title>Resumo do processo: engenharia de release</title>
                        <mediaobject><imageobject><imagedata fileref="proc-releng"/></imageobject></mediaobject>
                    </figure>
                </para>

                <para>Estas são as etapas do processo de engenharia de release. Vários candidatos a release podem ser criados até que a versão seja considerada estável o suficiente para ser liberada.</para>


                <para>
                    <citation><xref linkend="freebsd-releng"/></citation>
                </para>

            </section>


        </chapter>




        <chapter xml:id="tools">
            <title>Ferramentas</title>

            <para>As principais ferramentas de suporte para suportar o processo de desenvolvimento são Bugzilla, Mailman e OpenSSH. Estas são ferramentas desenvolvidas externamente e são comumente usadas no mundo do código aberto.</para>

            <section xml:id="tool-svn" xreflabel="SVN">
                <title>Subversion (SVN)</title>
                <para>Subversion (<quote>SVN</quote>) é um sistema para lidar com múltiplas versões de arquivos de texto e rastrear quem aplicou mudanças e por quê. Um projeto vive dentro de um <quote>repositório</quote> e diferentes versões são consideradas <quote>branches</quote> diferentes.</para>
            </section>

            <section xml:id="tool-bugzilla" xreflabel="Bugzilla">
                <title>Bugzilla</title>
                <para>O Bugzilla é um banco de dados de manutenção 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, além de consultar e atualizar o banco de dados e editar relatórios de bugs. O projeto usa sua interface web para enviar <quote>Relatórios de Problemas</quote> para o servidor central do Bugzilla. Os committers também possuem clientes web e de linha de comando.</para>
            </section>

            <section xml:id="model-mailman" xreflabel="[model, Mailman]">
                <title>Mailman</title>
                <para>Mailman é um programa que automatiza o gerenciamento de listas de discussão. O Projeto FreeBSD o utiliza para executar 16 listas gerais, 60 listas técnicas, 4 listas limitadas e 5 listas com logs de commit do CVS. Também é usado para muitas listas de discussão configuradas e usadas por outras pessoas e projetos na comunidade FreeBSD. Listas gerais são listas para o público em geral, listas técnicas são principalmente para o desenvolvimento de áreas específicas de interesse, e listas fechadas são para comunicação interna não destinadas ao público em geral. A maior parte de toda a comunicação no projeto passa por essas 85 listas, <citation><xref linkend="ref-bsd-handbook"/>, Apêndice C</citation>.</para>
            </section>

            <section xml:id="tool-pgp" xreflabel="PGP">
                <title>Pretty Good Privacy</title>
                <para>Pretty Good Privacy, mais conhecida como PGP, é um sistema criptográfico que usa uma arquitetura de chave pública para permitir que as pessoas assinem e/ou criptografem digitalmente as informações, a fim de garantir a comunicação segura entre as duas partes. Uma assinatura é usada ao enviar informações a muitos destinatários, permitindo que eles verifiquem se as informações não foram adulteradas antes de recebê-las. No Projeto FreeBSD este é o principal meio de assegurar que a informação tenha sido escrita pela pessoa que afirma ter escrito, e não alterada em trânsito.</para>
            </section>

            <section xml:id="tool-ssh2" xreflabel="SSH 2">
                <title>Secure Shell</title>
                <para>O Secure Shell é um padrão para efetuar login com segurança em um sistema remoto e para executar comandos no sistema remoto. Ele permite que outras conexões, chamadas túneis, sejam estabelecidas e protegidas entre os dois sistemas envolvidos. Este padrão existe em duas versões primárias, e somente a versão dois é usada para o projeto FreeBSD. A implementação mais comum do padrão é o OpenSSH, que faz parte da distribuição principal do projeto. Uma vez que sua fonte é atualizada com mais frequência do que as liberações do FreeBSD, a versão mais recente também está disponível na árvore de ports.</para>
            </section>

        </chapter>

        <chapter xml:id="sub-projects">
            <title>Sub-projetos</title>

            <para>Subprojetos são formados para reduzir a quantidade de comunicação necessária para coordenar o grupo de desenvolvedores. Quando uma área problemática é suficientemente isolada, a maior parte da comunicação estaria dentro do grupo, focando no problema, exigindo menos comunicação com os grupos com os quais eles se comunicam do que se o grupo não estivesse isolado.</para>

            <section xml:id="sub-project-ports" xreflabel="The Ports Subproject">
                <title>Subprojeto Ports</title>

                <para>Um <quote>port</quote> é um conjunto de meta-dados e patches que são necessários 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.</para>

                <para>
                    <figure xml:id="fig-ports">
                        <title>Número de ports adicionados entre 1996 e 2005</title>
                        <mediaobject><imageobject><imagedata fileref="portsstatus"/></imageobject></mediaobject>
                    </figure>
                </para>

                <para><xref linkend="fig-ports"/> é obtido do <link xlink:href="https://www.freebsd.org/ports/growth/status.png">site do FreeBSD</link>. Ele mostra o número de ports disponíveis para o FreeBSD no período de 1995 a 2005. Parece que a curva cresceu primeiro exponencialmente e, desde meados de 2001, cresceu linearmente.</para>

                <para>Como o software externo descrito pelo port geralmente está em desenvolvimento contínuo, a quantidade de trabalho necessária para manter os ports já é grande e está aumentando. Isso fez com que a parte dos ports do projeto FreeBSD ganhasse uma estrutura mais poderosa, e está se tornando cada vez mais um subprojeto do projeto FreeBSD.</para>

                <para>Ports tem seu próprio core team (time principal) com o <xref linkend="role-ports-manager"/> como seu líder, e esta equipe pode indicar committers sem a aprovação do FreeBSD Core. Ao contrário do Projeto FreeBSD, onde muitas tarefas de manutenção são frequentemente recompensadas com um commit bit, o subprojeto ports contém muitos mantenedores ativos que não são committers.</para>

                <para>Ao contrário do projeto principal, a árvore de ports não é ramificada (tem uma branch própria). Cada versão do FreeBSD segue a coleção atual de ports e, portanto, disponibiliza informações atualizadas sobre onde encontrar programas e como construí-los. Isso, no entanto, significa que um port que faz dependências no sistema pode precisar ter variações dependendo de qual versão do FreeBSD é executada.</para>

                <para>Com um repositório de ports não ramificado (sem branches), não é possível garantir que qualquer port seja executado em algo diferente de -CURRENT e -STABLE, em particular liberações secundárias e antigas. Não há infraestrutura nem tempo de voluntariado necessário para garantir isso.</para>

                <para>Para eficiência de comunicação, as equipes que dependem de ports, como a equipe de engenharia de release, têm suas próprias conexões com ports.</para>


            </section>


            <section xml:id="sub-project-documentation" xreflabel="The FreeBSD                 Documentation Project">
                <title>O projeto de documentação do FreeBSD</title>

                <para>O projeto de Documentação do FreeBSD foi iniciado em janeiro de 1995. Desde o grupo inicial de um líder de projeto, quatro líderes de equipe e 16 membros, eles são agora um total de 44 committers. A lista de discussão de documentação tem pouco menos de 300 membros, indicando que há uma grande comunidade em torno dela.</para>

                <para>O objetivo do projeto de Documentação é fornecer uma documentação boa e útil do projeto FreeBSD, facilitando assim que novos usuários se familiarizem com o sistema e detalhando recursos avançados para os usuários.</para>

                <para>As principais tarefas no projeto de Documentação são trabalhar em projetos atuais no <quote>Conjunto de Documentação do FreeBSD</quote>, e traduzir a documentação para outros idiomas.</para>

                <para>Como o Projeto FreeBSD, a documentação é dividida nas mesmas branches. Isso é feito para que sempre haja uma versão atualizada da documentação de cada versão. Apenas erros de documentação são corrigidos nas branches de segurança.</para>

                <para>Como o sub-projeto ports, o projeto de Documentação pode indicar committers de documentação sem a aprovação do FreeBSD Core. <citation><xref linkend="freebsd-doceng-charter"/></citation>.</para>

                <para>O projeto de Documentação possui uma cartilha. Isso é usado para apresentar novos membros de projeto às ferramentas e sintaxes padrão e atua como referência ao trabalhar no projeto.</para>

            </section>


    </chapter>

<bibliography xml:id="bibliography">
        <title>Referências</title>

  <biblioentry xml:id="brooks" xreflabel="Brooks, 1995">
    <authorgroup>
      <author><personname><firstname>Frederick P.</firstname><surname>Brooks</surname></personname></author>
    </authorgroup>
    <copyright><year>1975</year><year>1995</year> <holder>Pearson Education Limited</holder></copyright>
    <biblioid class="isbn">0201835959</biblioid>
    <publisher>
      <publishername>Addison-Wesley Pub Co</publishername>
    </publisher>
    <citetitle>The Mythical Man-Month</citetitle>
    <subtitle>Essays on Software Engineering, Anniversary Edition (2nd Edition)</subtitle>
  </biblioentry>

        <biblioentry xml:id="thesis" xreflabel="Saers, 2003">
            <authorgroup>
                <author><personname><firstname>Niklas</firstname><surname>Saers</surname></personname></author>
            </authorgroup>
            <copyright><year>2003</year></copyright>
            <citetitle>Um modelo de projeto para o projeto FreeBSD</citetitle>
            <subtitle>Tese de Candidatus Scientiarum</subtitle>
            <bibliomisc xlink:href="http://niklas.saers.com/thesis">http://niklas.saers.com/thesis</bibliomisc>
        </biblioentry>


        <biblioentry xml:id="jorgensen2001" xreflabel="Jørgensen, 2001">
            <authorgroup>
                <author><personname><firstname>Niels</firstname><surname>Jørgensen</surname></personname></author>
            </authorgroup>
            <copyright><year>2001</year></copyright>
            <citetitle>Colocando tudo no porta-malas</citetitle>
            <subtitle>Desenvolvimento Incremental de Software no Projeto Open Source do FreeBSD</subtitle>
            <bibliomisc xlink:href="http://www.dat.ruc.dk/~nielsj/research/papers/freebsd.pdf">http://www.dat.ruc.dk/~nielsj/research/papers/freebsd.pdf</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="ref-pmbok" xreflabel="PMI, 2000">
            <authorgroup>
                <author><personname><surname>Instituto de Gerenciamento de Projeto</surname></personname></author>
            </authorgroup>
            <copyright><year>1996</year><year>2000</year> <holder>Instituto de Gerenciamento de Projetos</holder></copyright>
            <biblioid class="isbn">1-880410-23-0</biblioid>
            <publisher>
                <publishername>Instituto de Gerenciamento de Projetos</publishername>
                <address>
                    <street>Newtown Square</street>
                    <city>Pennsylvania</city>
                    <country>USA</country>
                </address>
            </publisher>
            <citetitle>Guia PMBOK</citetitle>
            <subtitle>A Guide to the Project Management Body of Knowledge, 2000 Edition</subtitle>
        </biblioentry>



        <biblioentry xml:id="freebsd-bylaws" xreflabel="FreeBSD, 2000A">
            <copyright><year>2002</year> <holder>O projeto FreeBSD</holder></copyright>
            <citetitle>Estatuto do Core</citetitle>
            <bibliomisc xlink:href="https://www.freebsd.org/internal/bylaws.html">https://www.freebsd.org/internal/bylaws.html</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="freebsd-developer-handbook" xreflabel="FreeBSD, 2002A">
            <copyright><year>2002</year> <holder>O Projeto de Documentação do FreeBSD</holder></copyright>
            <citetitle>Manual do desenvolvedor do FreeBSD</citetitle>
            <bibliomisc xlink:href="https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/">https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="bsd-election2002" xreflabel="FreeBSD, 2002B">
            <copyright><year>2002</year> <holder>O projeto FreeBSD</holder></copyright>
            <citetitle>Eleição da equipe do Core em 2002</citetitle>
            <bibliomisc xlink:href="http://election.uk.freebsd.org/candidates.html">http://election.uk.freebsd.org/candidates.html</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="freebsd-handle-pr" xreflabel="FreeBSD, 2002C">
            <authorgroup>
                <author><personname><firstname>Dag-Erling</firstname><surname>Smørgrav</surname></personname></author>
                <author><personname><firstname>Hiten</firstname><surname>Pandya</surname></personname></author>
            </authorgroup>
            <copyright><year>2002</year> <holder>O Projeto de Documentação do FreeBSD</holder></copyright>
            <publisher>
                <publishername>O projeto de documentação do FreeBSD</publishername>
            </publisher>
            <citetitle>Diretrizes para manuseio de Relatórios de Problemas</citetitle>
            <bibliomisc xlink:href="https://www.freebsd.org/doc/en/articles/pr-guidelines/article.html">https://www.freebsd.org/doc/en/articles/pr-guidelines/article.html</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="freebsd-send-pr" xreflabel="FreeBSD, 2002D">
            <authorgroup>
                <author><personname><firstname>Dag-Erling</firstname><surname>Smørgrav</surname></personname></author>
            </authorgroup>
            <copyright><year>2002</year> <holder>O Projeto de Documentação do FreeBSD</holder></copyright>
            <publisher>
                <publishername>O projeto de documentação do FreeBSD</publishername>
            </publisher>
            <citetitle>Escrevendo Relatórios de Problemas do FreeBSD</citetitle>
            <bibliomisc xlink:href="https://www.freebsd.org/doc/en/articles/problem-reports/article.html">https://www.freebsd.org/doc/en/articles/problem-reports/article.html</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="freebsd-committer" xreflabel="FreeBSD, 2001">
            <copyright><year>2001</year> <holder>O Projeto de Documentação do FreeBSD</holder></copyright>
            <publisher>
                <publishername>O projeto de documentação do FreeBSD</publishername>
            </publisher>
            <!-- Version 1.146 -->
            <citetitle>Guia para Commiters</citetitle>
            <bibliomisc xlink:href="https://www.freebsd.org/doc/en/articles/committers-guide/article.html">https://www.freebsd.org/doc/en/articles/committers-guide/article.html</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="freebsd-releng" xreflabel="FreeBSD, 2002E">
            <authorgroup>
                <author><personname><firstname>Murray</firstname><surname>Stokely</surname></personname></author>
            </authorgroup>
            <copyright><year>2002</year> <holder>O Projeto de Documentação do FreeBSD</holder></copyright>
            <!-- Version 1.42 -->
            <publisher>
                <publishername>O projeto de documentação do FreeBSD</publishername>
            </publisher>
            <citetitle>Engenharia de Release do FreeBSD</citetitle>
            <bibliomisc xlink:href="https://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.html">https://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.html</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="ref-bsd-handbook" xreflabel="FreeBSD, 2003A">
            <authorgroup>
                <author><personname><surname>Projeto de Documentação do FreeBSD</surname></personname></author>
            </authorgroup>
            <citetitle>Manual do FreeBSD</citetitle>
            <bibliomisc xlink:href="https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook">https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="freebsd-contributors" xreflabel="FreeBSD, 2002F">
            <copyright><year>2002</year> <holder>O Projeto de Documentação do FreeBSD</holder></copyright>
            <publisher>
                <publishername>O projeto de documentação do FreeBSD</publishername>
            </publisher>
            <citetitle>Colaboradores para o FreeBSD</citetitle>
            <bibliomisc xlink:href="https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/article.html">https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/article.html</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="freebsd-election" xreflabel="FreeBSD, 2002G">
            <copyright><year>2002</year> <holder>O projeto FreeBSD</holder></copyright>
            <publisher>
                <publishername>O projeto FreeBSD</publishername>
            </publisher>
            <citetitle>Eleições da equipe do Core em 2002</citetitle>
            <bibliomisc xlink:href="http://election.uk.freebsd.org">http://election.uk.freebsd.org</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="freebsd-expiration-policy" xreflabel="FreeBSD, 2002H">
            <copyright><year>2002</year> <holder>O projeto FreeBSD</holder></copyright>
            <publisher>
                <publishername>O projeto FreeBSD</publishername>
            </publisher>
            <citetitle>Política de expiração de commit bit</citetitle>
            <subtitle>2002/04/06 15:35:30</subtitle>
            <bibliomisc xlink:href="https://www.freebsd.org/internal/expire-bits.html">https://www.freebsd.org/internal/expire-bits.html</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="freebsd-new-account" xreflabel="FreeBSD, 2002I">
            <copyright><year>2002</year> <holder>O projeto FreeBSD</holder></copyright>
            <publisher>
                <publishername>O projeto FreeBSD</publishername>
            </publisher>
            <citetitle>Novo procedimento de criação de conta</citetitle>
            <subtitle>2002/08/19 17:11:27</subtitle>
            <bibliomisc xlink:href="https://www.freebsd.org/internal/new-account.html">https://www.freebsd.org/internal/new-account.html</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="freebsd-doceng-charter" xreflabel="FreeBSD, 2003B">
            <copyright><year>2002</year> <holder>O Projeto de Documentação do FreeBSD</holder></copyright>
            <publisher>
                <publishername>O projeto de documentação do FreeBSD</publishername>
            </publisher>
            <citetitle>Capitulo da Equipe do DocEng do FreeBSD</citetitle>
            <subtitle>2003/03/16 12:17</subtitle>
            <bibliomisc xlink:href="https://www.freebsd.org/internal/doceng.html">https://www.freebsd.org/internal/doceng.html</bibliomisc>
        </biblioentry>

        <biblioentry xml:id="ref-freebsd-trenches" xreflabel="Lehey, 2002">
            <authorgroup>
                <author><personname><firstname>Greg</firstname><surname>Lehey</surname></personname></author>
            </authorgroup>
            <copyright><year>2002</year> <holder>Greg Lehey</holder></copyright>
            <publisher>
                <publishername>Greg Lehey</publishername>
            </publisher>
            <citetitle>Dois anos nas trincheiras</citetitle>
            <subtitle>A evolução de um projeto de software</subtitle>
            <bibliomisc xlink:href="http://www.lemis.com/grog/In-the-trenches.pdf">http://www.lemis.com/grog/In-the-trenches.pdf</bibliomisc>
        </biblioentry>
    </bibliography>

</book>