                              Guia dos Committers

  Projeto de Documentac,ao do FreeBSD

   Revisao: 5102a4f9ad

   Copyright (c) 1999-2020 Projeto de Documentac,ao do FreeBSD

   FreeBSD is a registered trademark of the FreeBSD Foundation.

   Coverity is a registered trademark; Coverity Extend, Coverity Prevent and
   Coverity Prevent SQS are trademarks of Coverity, Inc.

   IBM, AIX, OS/2, PowerPC, PS/2, S/390, and ThinkPad are trademarks of
   International Business Machines Corporation in the United States, other
   countries, or both.

   Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium,
   Pentium, and Xeon are trademarks or registered trademarks of Intel
   Corporation or its subsidiaries in the United States and other countries.

   SPARC, SPARC64, and UltraSPARC are trademarks of SPARC International, Inc
   in the United States and other countries. SPARC International, Inc owns
   all of the SPARC trademarks and under licensing agreements allows the
   proper use of these trademarks by its members.

   Many of the designations used by manufacturers and sellers to distinguish
   their products are claimed as trademarks. Where those designations appear
   in this document, and the FreeBSD Project was aware of the trademark
   claim, the designations have been followed by the "(TM)" or the "(R)"
   symbol.

   2020-11-22 20:53:41 +0000 por Danilo G. Baio.
   Resumo

   Este documento fornece informac,oes para a comunidade de committers do
   FreeBSD. Todos os novos committers devem ler este documento antes de
   comec,ar, e os committers existentes sao fortemente encorajados a
   revisa-lo de tempos em tempos.

   Quase todos os desenvolvedores do FreeBSD possuem direitos de commit para
   um ou mais repositorios. No entanto, alguns desenvolvedores nao tem, e
   algumas das informac,oes aqui se aplicam a eles tambem. (Por exemplo,
   algumas pessoas so tem direitos para trabalhar com o banco de dados do
   Relatorio de Problemas). Por favor, veja Sec,ao 21, "Problemas Especificos
   para Desenvolvedores Que Nao Sao Committers" para mais informac,oes.

   Este documento tambem pode ser de interesse para os membros da comunidade
   FreeBSD que querem aprender mais sobre como o projeto funciona.

   [ Documento HTML em partes / Documento HTML completo ]

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

   Indice

   1. Detalhes Administrativos

   2. Chaves OpenPGP para o FreeBSD

   3. Kerberos e LDAP Web Password para o cluster do FreeBSD

   4. Tipos de Commit Bits

   5. Subversion Primer

   6. Configurac,ao, Convenc,oes e Tradic,oes

   7. Revisao pre-commit

   8. Mensagens de Log de Commit

   9. Licenc,a preferida para novos arquivos

   10. Acompanhando as Licenc,as Concedidas ao Projeto FreeBSD

   11. Relac,oes entre os Desenvolvedores

   12. Se em duvida...

   13. Bugzilla

   14. Phabricator

   15. Quem e quem

   16. Guia de inicio rapido do SSH

   17. Disponibilidade do Coverity(R) para os Committers do FreeBSD

   18. A Grande Lista de Regras dos Committers do FreeBSD

   19. Suporte para Varias Arquiteturas

   20. FAQ especifico dos Ports

   21. Problemas Especificos para Desenvolvedores Que Nao Sao Committers

   22. Informac,oes sobre o Google Analytics

   23. Perguntas Diversas

   24. Beneficios e vantagens para os Commiters do FreeBSD

1. Detalhes Administrativos

   Metodos de      ssh(1),_apenas no protocolo 2                              
   login           
   Servidor                                                                   
   Principal de    freefall.FreeBSD.org
   Shell           
   Servidor SMTP   smtp.FreeBSD.org:587 (veja tambem Sec,ao 6.2.1,            
                   "Configurac,ao de acesso SMTP").                           
   Raiz do         svn+ssh://repo.FreeBSD.org/base (veja tambem Sec,ao 5.2.2, 
   Subversion para "Branches RELENG_* e Layout Geral").                       
   o src/          
   Raiz do         svn+ssh://repo.FreeBSD.org/doc (veja tambem Sec,ao 5.2.3,  
   Subversion para "Branches e Layout do Projeto de Documentac,ao do          
   o doc/          FreeBSD").                                                 
   Raiz do         svn+ssh://repo.FreeBSD.org/ports (veja tambem              
   Subversion para Sec,ao 5.2.4, "Branches e Layout da Arvore de Ports do     
   o ports/        FreeBSD").                                                 
                   developers (tecnicamente chamada de all-developers),       
                   doc-developers, doc-committers, ports-developers,          
                   ports-committers, src-developers, src-committers. (cada    
   Listas de       repositorio do projeto tem as suas proprias listas de      
   Discussao       discussao -developers e -committers. Os arquivos destas    
   Internas        listas podem ser encontrados nos arquivos                  
                   /local/mail/repository-name-developers-archive e           
                   /local/mail/repository-name-committers-archive no cluster  
                   FreeBSD.org.)                                              
   Relatorios      Disponiveis no diretorio /home/core/public/monthly-reports 
   mensais do Core do cluster FreeBSD.org.                                    
   Team            
   Relatorios      Disponiveis no diretorio                                   
   mensais da      /home/portmgr/public/monthly-reports do cluster            
   Equipe de       FreeBSD.org.                                               
   Gestao do Ports 
   Branchs SVN do                                                             
   src/ dignas de  stable/n (n-STABLE), head (-CURRENT)
   atenc,ao        

   O ssh(1) e necessario para se conectar aos servidores do projeto. Para
   mais informac,oes, veja Sec,ao 16, "Guia de inicio rapido do SSH".

   Links Uteis:

     * Paginas Internas do Projeto FreeBSD

     * Servidores do Projeto FreeBSD

     * Grupos Administrativos do Projeto FreeBSD

2. Chaves OpenPGP para o FreeBSD

   O projeto FreeBSD utiliza chaves criptograficas em conformidade com o
   padrao OpenPGP (Pretty Good Privacy) para autenticar os committers.
   Mensagens contendo informac,oes importantes como chaves publicas SSH podem
   ser assinadas com uma chave OpenPGP para provar que elas vieram realmente
   do committer. Veja PGP & GPG: Email for the Practical Paranoid by Michael
   Lucas e http://en.wikipedia.org/wiki/Pretty_Good_Privacy para maiores
   informac,oes.

  2.1. Criando uma chave

   As chaves existentes podem ser usadas, mas elas devem ser obtidas com o
   doc/head/share/pgpkeys/checkkey.sh primeiro. Neste caso, certifique-se que
   a chave contenha um ID de usuario FreeBSD.

   Para quem ainda nao tem uma chave OpenPGP, ou precisa de uma nova chave
   para atender aos requisitos de seguranc,a do FreeBSD, nesta sec,ao iremos
   mostrar como gerar uma.

    1. Instale o security/gnupg. Digite estas linhas no ~/.gnupg/gpg.conf
       para definir padroes minimos aceitaveis:

 fixed-list-mode
 keyid-format 0xlong
 personal-digest-preferences SHA512 SHA384 SHA256 SHA224
 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
 use-agent
 verify-options show-uid-validity
 list-options show-uid-validity
 sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g
 cert-digest-algo SHA512

    2. Gere uma chave:

 % gpg --full-gen-key
 gpg (GnuPG) 2.1.8; Copyright (C) 2015 Free Software Foundation, Inc.
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.

 Warning: using insecure memory!
 Please select what kind of key you want:
    (1) RSA and RSA (default)
    (2) DSA and Elgamal
    (3) DSA (sign only)
    (4) RSA (sign only)
 Your selection? 1
 RSA keys may be between 1024 and 4096 bits long.
 What keysize do you want? (2048) 2048  1
 Requested keysize is 2048 bits
 Please specify how long the key should be valid.
          0 = key does not expire
       <n>  = key expires in n days
       <n>w = key expires in n weeks
       <n>m = key expires in n months
       <n>y = key expires in n years
 Key is valid for? (0) 3y  2
 Key expires at Wed Nov  4 17:20:20 2015 MST
 Is this correct? (y/N) y

 GnuPG needs to construct a user ID to identify your key.

 Real name: Chucky Daemon 3
 Email address: notreal@example.com
 Comment:
 You selected this USER-ID:
     "Chucky Daemon <notreal@example.com>"

 Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
 You need a Passphrase to protect your secret key.

       1 Chaves de 2048-bit com uma expirac,ao de 3 anos proveem uma          
         protec,ao adequada nos dias de hoje (2013-12). O artigo              
         http://danielpocock.com/rsa-key-sizes-2048-or-4096-bits descreve a   
         situac,ao em mais detalhes.                                          
       2 Tres anos e um tempo de vida para a chave que e curto o suficiente   
         para tornar obsoletas as chaves enfraquecidas pelo avanc,o do poder  
         computacional, mas e tempo suficiente para reduzir os principais     
         problemas de gerenciamento.                                          
       3 Use o seu nome real, preferencialmente o mesmo que consta do seu     
         documento de identificac,ao (ID) emitido pelo seu governo para       
         tornar mais facil para as outras pessoas confirmarem sua identidade. 
         Voce pode inserir um texto adicional para ajudar outras pessoas a    
         identificar voce na sec,ao Comment.                                  

       Depois que o enderec,o de e-mail e inserido, uma senha e solicitada.
       Os metodos de criac,ao de uma frase secreta segura sao controversos.
       Em vez de sugerir um unico caminho, aqui estao alguns links para sites
       que descrevem varios
       metodos:http://world.std.com/~reinhold/diceware.html,
       http://www.iusmentis.com/security/passphrasefaq/, http://xkcd.com/936/
       e http://en.wikipedia.org/wiki/Passphrase.

   Proteja a chave privada e a frase secreta. Se a chave privada ou a frase
   secreta pode ter sido comprometida ou exposta, notifique imediatamente
   <accounts@FreeBSD.org> e revogue a chave.

   O processo para commit da nova chave e mostrado em Procedimento 1, "Etapas
   para os novos committers".

3. Kerberos e LDAP Web Password para o cluster do FreeBSD

   O cluster do FreeBSD requer uma senha do Kerberos para acessar certos
   servic,os. A senha do Kerberos tambem serve como a senha LDAP para a web,
   ja que o LDAP faz um proxy para o Kerberos no cluster. Alguns dos
   servic,os que exigem isso incluem:

     * Bugzilla

     * Jenkins

   Para criar uma nova conta do Kerberos no cluster do FreeBSD, ou para
   redefinir uma senha do Kerberos para uma conta existente usando um gerador
   de senha aleatoria:

 % ssh kpasswd.freebsd.org

  Nota:

   Isto deve ser feito a partir de uma maquina fora do cluster do
   FreeBSD.org.

   Uma senha do Kerberos tambem pode ser definida manualmente, para isto
   logue no servidor freefall.FreeBSD.org e execute:

 % kpasswd

  Nota:

   A menos que os servic,os autenticados por Kerberos do cluster do
   FreeBSD.org tenham sido usados anteriormente, o erro Client unknownsera
   exibido. Este erro significa que o metodo ssh kpasswd.freebsd.org mostrado
   acima deve ser usado primeiro para inicializar a conta Kerberos.

4. Tipos de Commit Bits

   O repositorio do FreeBSD possui um numero de componentes que, quando
   combinados, suportam os fontes basicos do sistema operacional, a
   documentac,ao, a infraestrutura de ports de aplicativos de terceiros e
   varios utilitarios mantidos. Quando os commit bits do FreeBSD sao
   alocados, as areas da arvore onde o bit pode ser usado sao especificadas.
   Geralmente, as areas associadas a um bit refletem quem autorizou a
   alocac,ao do bit de commit. Areas adicionais de autoridade podem ser
   adicionadas em uma data posterior: quando isso ocorre, o committer deve
   seguir procedimentos normais de atribuic,ao de bits de confirmac,ao para
   essa area da arvore, buscando a aprovac,ao da entidade apropriada e
   possivelmente obtendo um mentor para essa area por algum periodo de tempo.

   Tipo de Committer   Responsavel   Componentes da Arvore                    
   src                 core@         src/, doc/ sujeito a revisao apropriada  
   doc                 doceng@       doc/, ports/, src/ documentac,ao         
   ports               portmgr@      ports/                                   

   Os commit bits alocados antes do desenvolvimento da noc,ao de areas de
   autoridade podem ser apropriados para uso em muitas partes da arvore. No
   entanto, o senso comum determina que um committer que nao tenha trabalhado
   anteriormente em uma area da arvore busque alguem para realizar uma
   revisao antes de realizar o commit, busque a aprovac,ao da parte
   responsavel apropriada e/ou trabalhe com um mentor. Uma vez que as regras
   relativas `a manutenc,ao de codigo diferem por area da arvore, isso e
   tanto para o beneficio do committer trabalhando em uma area de menos
   familiar quanto para as outras pessoas trabalhando na arvore.

   Committers sao encorajados a buscar revisao do seu trabalho como parte do
   processo normal de desenvolvimento, independentemente da area da arvore
   onde o trabalho esta ocorrendo.

  4.1. Politica para atividade de Committers em outras arvores

     * Todos os committers podem modificar
       base/head/share/misc/committers-*.dot,
       base/head/usr.bin/calendar/calendars/calendar.freebsd, e
       ports/head/astro/xearth/files.

     * os doc committers podem efetuar commits de alterac,oes na
       documentac,ao sob src, tal como man pages, READMEs, banco de dados do
       fortune, arquivos de calendarios, e comentar correc,oes sem aprovac,ao
       de um src committer, sujeito aos cuidados normais necessarios para um
       commit seguro.

     * Qualquer committer pode fazer alterac,oes em qualquer outra arvore com
       um "Approved by" de um committer que nao esteja sob mentoria e que
       tenha o bit apropriado.

     * Os committers podem adquirir um bit adicional pelo processo usual de
       encontrar um mentor que os propora ao core, doceng ou portmgr,
       conforme apropriado. Quando aprovados, eles serao adicionados ao
       'access' e o periodo normal de mentoria ira ocorrer, o que envolvera a
       continuidade do uso do "Approved by" por um periodo.

     * O "Approved by" so e aceitavel vindo de src committers que nao estejam
       sob mentoria - os committers mentorados podem fornecer um "Reviewed
       by" mas nao um "Approved by".

5. Subversion Primer

   Supoe-se que novos committers ja estejam familiarizados com a operac,ao
   basica do Subversion. Se nao, comece lendo o Subversion Book.

  5.1. Introduc,ao

   O repositorio de codigo fonte do FreeBSD mudou do CVS para o Subversion em
   31 de maio de 2008. O primeiro commit real no SVN e o r179447.

   O repositorio do FreeBSD doc/www foi migrado do CVS para o Subversion em
   19 de Maio de 2012. O primeiro commit real no SVN foi o r38821.

   O repositorio da colec,ao de ports do FreeBSD foi migrado do CVS para o
   Subversion em 14 de Julho 2012. O primeiro commit real no SVN foi o
   r300894.

   O Subversion pode ser instalado a partir da Colec,ao de Ports do FreeBSD,
   executando o comando:

 # pkg install subversion

  5.2. Primeiros Passos

   Existem algumas maneiras de obter uma copia de trabalho da arvore do
   Subversion. Esta sec,ao ira explica-las.

    5.2.1. Checkout direto

   O primeiro e fazer check-out diretamente do repositorio principal. Para a
   arvore src, use:

 % svn checkout svn+ssh://repo.freebsd.org/base/head /usr/src

   Para a arvore doc, use:

 % svn checkout svn+ssh://repo.freebsd.org/doc/head /usr/doc

   Para a arvore da colec,ao de ports, use:

 % svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports

  Nota:

   Embora os exemplos restantes neste documento tenham sido escritos tendo o
   workflow de trabalho com a arvore src em mente, os conceitos basicos sao
   os mesmos para se trabalhar com o doc e com a arvore dos ports. Os ports
   relacionados `as operac,oes do Subversion estao listados em Sec,ao 20,
   "FAQ especifico dos Ports".

   O comando acima ira fazer o checkout da arvore de codigo-fonte CURRENT
   como /usr/src/, o qual pode ser qualquer diretorio de destino no sistema
   de arquivos local. Omitir o argumento final desse comando faz com que a
   copia de trabalho, neste caso, seja nominada como "head", mas ela podera
   ser renomeada com seguranc,a.

   O svn+ssh significa que o protocolo SVN sera tunelado sobre o SSH. O nome
   do servidor e repo.freebsd.org, e base e o caminho para o repositorio, e
   head e o subdiretorio dentro do repositorio.

   Se seu nome de login no projeto FreeBSD for diferente do nome de login
   usado na sua maquina local, inclua-o na URL (por exemplo
   svn+ssh://jarjar@repo.freebsd.org/base/head) ou adicione uma entrada no
   arquivo ~/.ssh/config no formato:

 Host repo.freebsd.org
         User jarjar

   Este e o metodo mais simples, mas e dificil dizer quanta carga ele ira
   colocar no repositorio.

  Nota:

   O svn diff nao requer acesso ao servidor pois o SVN armazena uma copia de
   referencia de todos os arquivos na copia de trabalho. Isto, no entanto,
   significa que as copias de trabalho do Subversion sao muito grandes em
   tamanho.

    5.2.2. Branches RELENG_* e Layout Geral

   No svn+ssh://repo.freebsd.org/base, base refere-se `a arvore de codigo
   fonte. Similarmente, ports refere-se `a arvore de ports e assim por
   diante. Estes sao repositorios separados com suas proprias sequ:encias de
   numeros de mudanc,a, controles de acesso e email de commit.

   Para o repositorio base, HEAD refere-se a arvore -CURRENT. Por exemplo,
   head/bin/ls e o que entraria como /usr/src/bin/ls em uma release. Alguns
   locais importantes sao:

     * /head/ que corresponde a HEAD, tambem conhecido como -CURRENT.

     * /stable/n que corresponde a RELENG_n.

     * /releng/n.n que corresponde a RELENG_n_n.

     * /release/n.n.n que corresponde a RELENG_n_n_n_RELEASE.

     * /vendor* e uma area de trabalho para importar branches de vendors.
       Este diretorio em si nao contem branches, no entanto, os seus
       subdiretorios contem. Isso contrasta com os diretorios stable, releng
       e release.

     * /projects e /user sao areas de trabalho de branch. Como acima, o
       diretorio /user nao contem branches em si.

    5.2.3. Branches e Layout do Projeto de Documentac,ao do FreeBSD

   no svn+ssh://repo.freebsd.org/doc, doc refere-se `a raiz do repositorio da
   arvore de codigo fonte.

   Em geral, a maior parte do trabalho do Projeto de Documentac,ao do FreeBSD
   sera feito dentro do branch head/ da arvore com os arquivos fontes da
   documentac,ao.

   A documentac,ao do FreeBSD e escrita e/ou traduzida para varios idiomas,
   cada um em um diretorio separado no branch head/.

   Cada conjunto de traduc,ao contem varios subdiretorios para as varias
   partes do Projeto de Documentac,ao do FreeBSD. Alguns diretorios notaveis
   sao:

     * /articles/ contem o codigo fonte para artigos escritos por varios
       colaboradores do FreeBSD.

     * /books/ contem o codigo fonte para os diferentes livros, como o
       Handbook do FreeBSD.

     * /htdocs/ contem o codigo-fonte do website do FreeBSD.

    5.2.4. Branches e Layout da Arvore de Ports do FreeBSD

   No svn+ssh: //repo.freebsd.org/ports, ports refere-se `a raiz do
   repositorio da arvore de ports.

   Em geral, a maior parte do trabalho na colec,ao de ports do FreeBSD sera
   feito dentro da branch head/ da arvore de ports, que e a arvore de ports
   real usada para instalar software. Alguns outros locais importantes sao:

     * /branches/RELENG_n_n_n que corresponde a RELENG_n_n_n e e usado para
       mesclar atualizac,oes de seguranc,a em preparac,ao para uma release.

     * /tags/RELEASE_n_n_n que corresponde a RELEASE_n_n_n e representa uma
       tag de release da arvore de ports.

     * /tags/RELEASE_n_EOL representa o tag de end of life de um branch
       especifico do FreeBSD.

  5.3. Uso diario

   Esta sec,ao explicara como realizar operac,oes comuns do dia-a-dia com o
   Subversion.

    5.3.1. Ajuda

   O SVN traz em si uma documentac,ao interna de ajuda. Ela pode ser acessada
   digitando:

 % svn help

   Informac,oes adicionais podem ser encontradas no Subversion Book.

    5.3.2. Checkout

   Como visto anteriormente, para fazer o checkout da branch principal (head)
   do FreeBSD:

 % svn checkout svn+ssh://repo.freebsd.org/base/head /usr/src

   Em algum momento, provavelmente sera util ter uma copia de trabalho mais
   do que apenas do HEAD, por exemplo, ao mesclar as alterac,oes para
   stable/7. Portanto, pode ser util ter uma verificac,ao parcial da arvore
   completa (um check-out completo seria muito doloroso).

   Para fazer isso, primeiro confira a raiz do repositorio:

 % svn checkout --depth=immediates svn+ssh://repo.freebsd.org/base

   Isso vai obter o base com todos os arquivos que ele contem (no momento da
   escrita, apenas o ROADMAP.txt) e subdiretorios vazios para head, stable,
   vendor e assim por diante.

   E possivel expandir a copia de trabalho. Basta alterar a profundidade dos
   varios subdiretorios:

 % svn up --set-depth=infinity base/head
 % svn up --set-depth=immediates base/release base/releng base/stable

   O comando acima ira baixar uma copia completa do head, alem de copias
   vazias de cada tag de release, de cada branch de releng, e de cada branch
   stable.

   Se numa data posterior voce tiver necessidade de mesclar algo, por
   exemplo, com a 7-STABLE, expanda a copia de trabalho:

 % svn up --set-depth=infinity base/stable/7

   As subarvores nao precisam ser expandidas completamente. Por exemplo, para
   expandir apenas o stable/7/sys e depois expandir o resto do stable/7:

 % svn up --set-depth=infinity base/stable/7/sys
 % svn up --set-depth=infinity base/stable/7

   Atualizar a arvore com svn update ira apenas atualizar o que foi pedido
   anteriormente (neste caso, head e stable/7), ele nao ira puxar a arvore
   inteira.

    5.3.3. Checkout Anonimo

   E possivel efetuar o checkout anonimo o repositorio Subversion do FreeBSD.
   Isso dara acesso a uma arvore somente leitura que pode ser atualizada, mas
   que nao podera ser enviada de volta para o repositorio principal por meio
   de um commit. Para fazer isso, use:

 % svn co https://svn.FreeBSD.org/base/head /usr/src

   Mais detalhes sobre o uso do Subversion podem ser encontrados emUsando o
   Subversion.

    5.3.4. Atualizando a Arvore

   Para atualizar uma copia de trabalho para a revisao mais recente ou uma
   revisao especifica:

 % svn update
 % svn update -r12345

    5.3.5. Status

   Para ver as alterac,oes locais que foram feitas na copia de trabalho:

 % svn status

   Para mostrar alterac,oes locais e arquivos que estao desatualizados,
   execute:

 % svn status --show-updates

    5.3.6. Editando e efetuando o commit

   O SVN nao precisa ser avisado com antecedencia sobre a edic,ao de
   arquivos.

   Para efetuar o commit de todas as alterac,oes no diretorio atual e em
   todos os seus subdiretorios:

 % svn commit

   Para efetuar o commit de todas as alterac,oes, por exemplo, nos arquivos
   lib/libfetch/ e usr/bin/fetch/ em uma unica operac,ao, execute:

 % svn commit lib/libfetch usr/bin/fetch

   Tambem existe um wrapper de commit para a arvore de ports para manipular
   as propriedades e para verificar a sanidade das mudanc,as:

 % /usr/ports/Tools/scripts/psvn commit

    5.3.7. Adicionando e Removendo Arquivos

  Nota:

   Antes de adicionar arquivos, obtenha uma copia do auto-props.txt (ha
   tambem um versao especifica da arvore de ports) e adicione-o ao
   ~/.subversion/config seguindo as instruc,oes contidas no arquivo. Se voce
   adicionou algo antes de ler isto, use o comando svn rm --keep-local para
   apenas os arquivos adicionados, corrija seu arquivo de configurac,ao e
   adicione-os novamente. O arquivo de configurac,ao inicial e criado quando
   voce executa um comando svn pela primeira vez, ate mesmo algo tao simples
   quanto svn help.

   Os arquivos sao adicionados a um SVN repositorio com svn add. Para
   adicionar um arquivo chamado foo, edite-o e depois execute:

 % svn add foo

  Nota:

   A maioria dos novos arquivos fonte deve incluir uma string $FreeBSD$
   proxima ao inicio do arquivo. Ao efetuar o commit, o svn expandira a
   string $FreeBSD$, adicionando o caminho do arquivo, o numero da revisao, a
   data e a hora da confirmac,ao e o nome de usuario do committer. Arquivos
   que nao podem ser modificados podem ser enviados sem a string $FreeBSD$.

   Os arquivos podem ser removidos com svn remove:

 % svn remove foo

   O subversion nao requer a exclusao do arquivo antes de usaramos o comando
   svn rm e, de fato, ele reclama se isso acontecer.

   E possivel adicionar diretorios com svn add:

 % mkdir bar
 % svn add bar

   Apesar que o svn mkdir torna isso mais facil, combinando a criac,ao do
   diretorio e a adic,ao dele:

 % svn mkdir bar

   Como arquivos, os diretorios sao removidos com svn rm. Nao existe um
   comando separado especificamente para remover diretorios.

 % svn rm bar

    5.3.8. Copiando e Movendo Arquivos

   Este comando cria uma copia do arquivo foo.c nomeado bar.c, com o novo
   arquivo tambem sob controle de versao e com o historico completo de foo.c:

 % svn copy foo.c bar.c

   Geralmente e preferivel copiar desta forma ao inves de copiar o arquivo
   com comando cp e adicionando-o ao repositorio com svn add porque desta
   forma o novo arquivo nao herda a historia do original.

   Para mover e renomear um arquivo:

 % svn move foo.c bar.c

    5.3.9. Logs e Anotac,oes

   O svn log mostra revisoes e mensagens de commit, as mais recentes sao
   exibidas primeiro, para arquivos ou diretorios. Quando usado em um
   diretorio, todas as revisoes que afetaram o diretorio e os arquivos nesse
   diretorio sao mostradas.

   O svn annotate , ou igualmente o svn praise ou svn blame, mostra o numero
   de revisao mais recente e quem fez o commit dessa revisao para cada linha
   de um arquivo.

    5.3.10. Diffs

   O svn diff exibe alterac,oes na copia de trabalho. Diffs gerado por SVN
   sao unificados e incluem novos arquivos por padrao na saida do diff.

   O svn diff pode mostrar as mudanc,as entre duas revisoes do mesmo arquivo:

 % svn diff -r179453:179454 ROADMAP.txt

   Ele tambem pode mostrar todas as alterac,oes para um changeset especifico.
   Este comando mostra quais alterac,oes foram feitas no diretorio atual e em
   todos os subdiretorios do changeset 179454:

 % svn diff -c179454 .

    5.3.11. Revertendo

   Mudanc,as locais (incluindo adic,oes e delec,oes) podem ser revertidas
   usando svn revert. Ele nao atualiza arquivos desatualizados, apenas os
   substitui por copias originais da versao original.

    5.3.12. Conflitos

   Se um svn update resultou em um conflito de mesclagem, o Subversion ira
   lembrar quais arquivos tem conflitos e se recusara a fazer o commit de
   quaisquer alterac,oes nesses arquivos ate que seja explicitamente
   informado que os conflitos foram resolvidos. O procedimento simples, ainda
   nao obsoleto, e:

 % svn resolved foo

   No entanto, o procedimento preferido e:

 % svn resolve --accept=working foo

   Os dois exemplos sao equivalentes. Os valores possiveis para --accept sao:

     * working: use a versao em seu diretorio de trabalho (a qual se presume
       que foi editada para resolver os conflitos).

     * base: usar uma copia original da versao que voce tinha antes do svn
       update, descartando suas proprias alterac,oes, as mudanc,as
       conflitantes e possivelmente outras mudanc,as intervenientes tambem.

     * mine-full: use o que voce tinha antes do svn update, incluindo suas
       proprias mudanc,as, mas descartando as mudanc,as conflitantes, e
       possivelmente outras mudanc,as intervenientes tambem.

     * theirs-full: use a versao que foi recuperada quando voce fez o svn
       update, descartando as suas proprias mudanc,as.

  5.4. Uso Avanc,ado

    5.4.1. Checkouts dispersos

   O SVN permite sparse, ou checkouts parciais de um diretorio adicionando
   --depth a um svn checkout.

   Os argumentos validos para --depth sao:

     * empty: o proprio diretorio sem qualquer conteudo.

     * files: o diretorio e quaisquer arquivos nele contidos.

     * immediates: o diretorio e quaisquer arquivos e diretorios contidos
       nele, mas nenhum dos conteudos dos subdiretorios.

     * infinity: qualquer coisa.

   A opc,ao --depth se aplica a muitos outros comandos, incluindo svn commit,
   svn revert e o svn diff.

   Como o parametro --depth utilizado e persistente, existe uma opc,ao
   --set-depth para o svn update que ira mudar a profundidade selecionada.
   Assim, dada a copia de trabalho produzida pelo exemplo anterior:

 % cd ~/freebsd
 % svn update --set-depth=immediates .

   O comando acima ira popular a copia de trabalho em ~/freebsd com
   ROADMAP.txt e subdiretorios vazios, e nada acontecera quando svn update
   for executado nos subdiretorios. No entanto, esse comando definira a
   profundidade para head (nesse caso) como infinito e o populara totalmente:

 % svn update --set-depth=infinity head

    5.4.2. Operac,ao Direta

   Certas operac,oes podem ser realizadas diretamente no repositorio sem
   tocar na copia de trabalho. Especificamente, isso se aplica a qualquer
   operac,ao que nao exija a edic,ao de um arquivo, incluindo:

     * log, diff

     * mkdir

     * remove, copy, rename

     * propset, propedit, propdel

     * merge

   A criac,ao de uma branch e muito rapida. Este comando seria usado para
   criar a branch RELENG_8:

 % svn copy svn+ssh://repo.freebsd.org/base/head svn+ssh://repo.freebsd.org/base/stable/8

   Isso equivale a esses comandos, que levam minutos e horas, em vez de
   segundos, dependendo da sua conexao de rede:

 % svn checkout --depth=immediates svn+ssh://repo.freebsd.org/base
 % cd base
 % svn update --set-depth=infinity head
 % svn copy head stable/8
 % svn commit stable/8

    5.4.3. Mesclando com SVN

   Esta sec,ao lida com o merge de codigo de um branch para outro
   (normalmente, do head para um brach stable).

  Nota:

   Em todos os exemplos abaixo, $FSVN refere-se `a localizac,ao do
   repositorio Subversion do FreeBSD, svn+ssh://repo.freebsd.org/base .

      5.4.3.1. Sobre o acompanhamento de mesclagem

   Do ponto de vista do usuario, informac,oes de acompanhamento de mesclagem
   (ou mergeinfo) sao armazenadas em uma propriedade chamada svn:mergeinfo,
   que e uma lista separada por virgulas de revisoes e intervalos de revisoes
   que foram mescladas. Quando definido em um arquivo, ele se aplica somente
   a esse arquivo. Quando definido em um diretorio, ele se aplica a esse
   diretorio e seus descendentes (arquivos e diretorios), exceto aqueles que
   possuem o seu proprio svn:mergeinfo.

   Ele nao e herdado. Por exemplo, stable/6/contrib/openpam/ nao herda
   implicitamente o mergeinfo de stable/6/, ou do stable/6/contrib/. Isso
   faria com que os checkouts parciais fossem dificeis de gerenciar. Em vez
   disso, o mergeinfo e explicitamente propagado pela arvore. Para mesclar
   algo em branch/foo/bar/, estas regras se aplicam:

    1. Se branch/foo/bar/ ainda nao tiver um registro mergeinfo, mas um
       ancestral direto (por exemplo, branch/foo/) tem, entao esse registro
       sera propagado para abaixo ate branch/foo/bar/ antes que as
       informac,oes sobre a mesclagem atual sejam registradas.

    2. As informac,oes sobre a mesclagem atual nao serao propagadas para o
       ancestral.

    3. Se um descendente direto de branch/foo/bar/ (por exemplo,
       branch/foo/bar/baz/) ja tiver um registro mergeinfo, as informac,oes
       sobre a mesclagem atual serao propagadas para ele.

   Se voce considerar o caso em que uma revisao altera varias partes
   separadas da arvore (por exemplo, branch/foo/bar/ e branch/foo/quux/), mas
   voce so deseja mesclar alguns deles (por exemplo, branch/foo/bar/), voce
   vera que essas regras fazem sentido. Se mergeinfo fosse propagado,
   pareceria que a revisao tambem foi mesclada com branch/foo/quux/, quando
   na verdade nao foi.

      5.4.3.2. Selecionando a branch de origem e de destino ao mesclar

   Mesclagens para as branches stable/ devem originar-se da head/. Por
   exemplo:

 % svn merge -c r123456 ^/head/ stable/11
 % svn commit stable/11

   Mesclagens para as branches releng/ devem sempre se originar da branch
   stable/ correspondente. Por exemplo:

 % svn merge -c r123456 ^/stable/11  releng/11.0
 % svn commit releng/11.0

  Nota:

   Os committers so podem se efetuar um commit para as branches releng/
   durante um ciclo de release apos receber aprovac,ao da Equipe de
   Engenharia de Release, apos o qual somente o Security Officer pode efetuar
   commits para o branch releng/ para um Aviso de Seguranc,a ou Aviso de
   Errata.

   Todas as mesclagens sao mescladas e enviadas por commit a partir da raiz
   da branch. Todas as mesclagens se parecem com:

 % svn merge -c r123456 ^/head/ checkout
 % svn commit checkout

   Observe que checkout deve ser uma verificac,ao completa da branch na qual
   a mesclagem ocorre.

 % svn merge -c r123456 ^/stable/10 releng/10.0

      5.4.3.3. Preparando o Alvo de Mesclagem (Merge Target)

   Devido aos problemas de propagac,ao do mergeinfo descritos anteriormente,
   e muito importante nunca mesclar as alterac,oes em uma copia de trabalho
   esparsa. Sempre use um checkout completo do branch que esta sendo
   mesclado. Por exemplo, ao mesclar de HEAD para 7, use um checkout completo
   de stable/7:

 % cd stable/7
 % svn up --set-depth=infinity

   O diretorio de destino tambem deve estar atualizado e nao deve conter
   alterac,oes que ainda nao foram enviadas por commit ou arquivos perdidos.

      5.4.3.4. Identificando Revisoes

   Identificar revisoes a serem mescladas e uma obrigac,ao. Se o alvo ja
   tiver mergeinfo completo, solicite uma lista para o SVN:

 % cd stable/6/contrib/openpam
 % svn mergeinfo --show-revs=eligible $FSVN/head/contrib/openpam

   Se o destino nao tiver mergeinfo completo, verifique o log da origem de
   mesclagem.

      5.4.3.5. Mesclando

   Agora vamos comec,ar a mesclar!

        5.4.3.5.1. Os principios

   Por exemplo, para mesclar:

     * revisao $R

     * no diretorio $target na branch stable $B

     * a partir do diretorio $source no head

     * $FSVN e o svn+ssh://repo.freebsd.org/base

   Supondo que as revisoes $P e $Q ja tenham sido mescladas e que o diretorio
   atual seja uma copia de trabalho atualizada de stable/$B, a mergeinfo
   existente sera semelhante a:

 % svn propget svn:mergeinfo -R $target
 $target - /head/$source:$P,$Q

   A mesclagem e feita assim:

 % svn merge -c$R $FSVN/head/$source $target

   E possivel verificar os resultados disso com um svn diff.

   O svn:mergeinfo agora se parece com:

 % svn propget svn:mergeinfo -R $target
 $target - head/$source:$P,$Q,$R

   Se os resultados nao forem exatamente como os mostrados, voce pode
   precisar de assistencia antes de efetuar o commit pois erros podem ter
   sido cometidos, ou pode haver algo errado com o mergeinfo existente, ou
   pode haver um bug no Subversion.

        5.4.3.5.2. Exemplo Pratico

   Como um exemplo pratico, considere este cenario. As alterac,oes no
   netmap.4 no r238987 devem ser mescladas do CURRENT para o 9-STABLE. O
   arquivo reside em head/share/man/man4. De acordo com o Sec,ao 5.4.3,
   "Mesclando com SVN", tambem e onde devemos fazer a mesclagem. Note que
   neste exemplo todos os caminhos sao relativos ao topo do repositorio svn.
   Para obter mais informac,oes sobre o layout do diretorio, consulte
   Sec,ao 5.2.2, "Branches RELENG_* e Layout Geral".

   O primeiro passo e inspecionar o mergeinfo existente.

 % svn propget svn:mergeinfo -R stable/9/share/man/man4

   Tome uma nota rapida de como ele se parece antes de avanc,ar para o
   proximo passo; fazendo a mesclagem real:

 % svn merge -c r238987 svn+ssh://repo.freebsd.org/base/head/share/man/man4 stable/9/share/man/man4
 --- Merging r238987 into 'stable/9/share/man/man4':
 U    stable/9/share/man/man4/netmap.4
 --- Recording mergeinfo for merge of r238987 into
 'stable/9/share/man/man4':
  U   stable/9/share/man/man4

   Verifique se o numero de revisao da revisao mesclada foi adicionado.
   Quando isso for verificado, a unica coisa que resta e o commit em si.

 % svn commit stable/9/share/man/man4

      5.4.3.6. Precauc,oes antes de efetuar o commit

   Como sempre, fac,a um build world (ou as partes apropriadas dele).

   Verifique as mudanc,as com o svn diff e svn stat. Certifique-se de que
   todos os arquivos que deveriam ter sido adicionados ou excluidos foram de
   fato adicionados ou excluidos.

   De uma olhada mais de perto em qualquer mudanc,a de propriedade (marcada
   por um M na segunda coluna do svn stat). Normalmente, nenhuma propriedade
   svn:mergeinfo deve estar em qualquer lugar, exceto o diretorio (ou
   diretorios) de destino.

   Se algo parecer suspeito, pec,a ajuda.

      5.4.3.7. Fazendo o commit

   Certifique-se de efetuar o commit de um diretorio de nivel superior para
   incluir tambem o mergeinfo. Nao especifique arquivos individuais na linha
   de comando. Para mais informac,oes sobre como submeter arquivos em geral,
   veja a sec,ao relevante deste manual.

    5.4.4. Importac,oes de fornecedores com SVN

  Importante:

   Por favor, leia toda esta sec,ao antes de iniciar uma importac,ao de
   fornecedores.

  Nota:

   Os patches para o codigo do fornecedor se enquadram em duas categorias:

     * Patches do fornecedor: sao patches que foram emitidos pelo fornecedor
       ou que foram extraidos do sistema de controle de versao do fornecedor,
       que abordam problemas que nao podem esperar ate a proxima versao do
       fornecedor.

     * Patches do FreeBSD: sao patches que modificam o codigo do fornecedor
       para resolver problemas especificos do FreeBSD.

   A natureza de um patch determina para onde ele deve ser enviado por
   commit:

     * Os patches do fornecedor devem ser enviados por commit para o branch
       do fornecedor e mesclados a partir dele. Se o patch resolver um
       problema em uma nova versao que esta sendo importada atualmente, ele
       nao deve ser enviado por commit junto com a nova versao: a versao deve
       ser importada e marcada primeiro, entao a correc,ao pode ser aplicada
       e o commit efetuado. Nao ha necessidade de marcar novamente as fontes
       do fornecedor depois de confirmar o patch.

     * Patches do FreeBSD sao enviados diretamente para o head.

      5.4.4.1. Preparando a Arvore

   Se estiver importando pela primeira vez apos a mudanc,a para o Subversion,
   e necessario achatar e limpar a arvore do fornecedor, bem como inicializar
   o historico de mesclagem na arvore principal.

        5.4.4.1.1. Achatamento

   Durante a conversao do CVS para o Subversion, as branches do fornecedor
   foram importadas com o mesmo layout da arvore principal. Isso significa
   que as fontes do fornecedor pf foram armazenadas originalmente em
   vendor/pf/dist/contrib/pf. O codigo fonte do fornecedor fica melhor se
   armazenado diretamente em vendor/pf/dist.

   Para achatar a arvore do pf:

 % cd vendor/pf/dist/contrib/pf
 % svn mv $(svn list) ../..
 % cd ../..
 % svn rm contrib
 % svn propdel -R svn:mergeinfo .
 % svn commit

   O bit propdel e necessario porque, comec,ando com 1.5, o Subversion
   adicionara svn:mergeinfo em qualquer diretorio que seja copiado ou movido.
   Nesse caso, como nada esta sendo mesclado da arvore excluida, eles apenas
   atrapalham.

   As tags tambem podem ser achatadas (3, 4, 3.5 etc.); o procedimento e
   exatamente o mesmo, mudando apenas dist para 3.5 ou similar, e aguardando
   para executar o svn commit apenas no final do processo.

        5.4.4.1.2. Limpando

   A arvore dist pode ser limpa conforme necessario. A desativac,ao da
   expansao de palavras-chave e recomendada, pois nao faz sentido no codigo
   do fornecedor nao modificado e, em alguns casos, pode ate mesmo ser
   prejudicial. O OpenSSH, por exemplo, inclui dois arquivos que se
   originaram do FreeBSD e ainda contem as tags da versao original. Para
   fazer isso:

 % svn propdel svn:keywords -R .
 % svn commit

        5.4.4.1.3. Bootstrapping o historico de mesclagem

   Se estiver importando pela primeira vez apos a mudanc,a para o Subversion,
   fac,a o bootstrap do svn:mergeinfo no diretorio de destino da arvore
   principal para a revisao que corresponde `a ultima alterac,ao relacionada
   `a arvore do fornecedor, antes de importar novos fontes:

 % cd head/contrib/pf
 % svn merge --record-only svn+ssh://repo.freebsd.org/base/vendor/pf/dist@180876 .
 % svn commit

      5.4.4.2. Importando Novas Fontes

   Com dois commits - um para a importac,ao em si e outro para a tag - essa
   etapa pode ser opcionalmente repetida para cada release upstream entre a
   ultima importac,ao e a importac,ao atual.

        5.4.4.2.1. Preparando os fontes do fornecedor

   O Subversion e capaz de armazenar uma distribuic,ao completa na arvore do
   fornecedor. Portanto, importe tudo, mas mescle apenas o que e necessario.

   Um svn add e necessario para adicionar quaisquer arquivos que foram
   adicionados desde a ultima importac,ao do fornecedor, e o svn rm e
   necessario para remover todos os que foram removidos desde entao.
   Recomenda-se a preparac,ao de listas ordenadas do conteudo da arvore do
   fornecedor e das fontes que serao importadas, para facilitar o processo.

 % cd vendor/pf/dist
 % svn list -R | grep -v '/$' | sort >../old
 % cd ../pf-4.3
 % find . -type f | cut -c 3- | sort >../new

   Com esses dois arquivos, o comm -23 ../old ../new listara os arquivos
   removidos (arquivos somente em old), enquanto comm -13 .. /old ../new
   listara os arquivos adicionados somente no new.

        5.4.4.2.2. Importando para a Arvore do Fornecedor

   Agora, os fontes devem ser copiados para dist e os comandos svn add e svn
   rm sao usados conforme necessario:

 % cd vendor/pf/pf-4.3
 % tar cf - . | tar xf - -C ../dist
 % cd ../dist
 % comm -23 ../old ../new | xargs svn rm
 % comm -13 ../old ../new | xargs svn add --parents

   Se algum diretorio foi removido, ele tera que ser removido manualmente com
   o svn rm. Nada vai quebrar se eles nao forem, mas eles permanecerao na
   arvore.

   Verifique as propriedades em qualquer novo arquivo. Todos os arquivos de
   texto devem ter o svn:eol-style definido como native. Todos os arquivos
   binarios devem ter o svn:mime-type configurado para
   application/octet-stream , a menos que haja um tipo de midia mais
   apropriado. Arquivos executaveis devem ter svn:executable definido como *.
   Nenhuma outra propriedade deve existir em qualquer arquivo da arvore.

   Agora e possivel fazer o commit. No entanto, e uma boa pratica
   certificar-se de que tudo esta correto, usando os comandos svn stat e svn
   diff.

        5.4.4.2.3. Marcac,ao (Tagging)

   Depois de realizado o commit, as versoes do fornecedor sao marcadas para
   referencia futura. A melhor e mais rapida maneira de fazer isso e
   diretamente no repositorio:

 % svn cp svn+ssh://repo.freebsd.org/base/vendor/pf/dist svn+ssh://repo.freebsd.org/base/vendor/pf/4.3

   Quando isso estiver concluido, execute o svn up para a copia de trabalho
   do vendor/pf para obter a nova tag, embora isso raramente seja necessario.

   Se voce criar a tag na copia de trabalho da arvore, os resultados do
   svn:mergeinfo deverao ser removidos:

 % cd    vendor/pf
 % svn cp dist 4.3
 % svn propdel svn:mergeinfo -R 4.3

      5.4.4.3. Mesclagem para o Head

 % cd head/contrib/pf
 % svn up
 % svn merge --accept=postpone svn+ssh://repo.freebsd.org/base/vendor/pf/dist .

   O --accept=postpone diz ao Subversion para nao reclamar sobre conflitos de
   mesclagem, pois eles serao manipulados manualmente.

  Dica:

   A mudanc,a do cvs2svn ocorreu em 3 de junho de 2008. Ao realizar
   mesclagens de fornecedores para pacotes que ja estavam presentes e
   convertidos pelo processo cvs2svn, o comando usado para mesclar
   /vendor/package_name/dist para /head/package_location (por exemplo,
   head/contrib/sendmail) deve usar -c REV para indicar a revisao a ser
   mesclada a partir da arvore /vendor. Por exemplo:

 % svn checkout svn+ssh://repo.freebsd.org/base/head/contrib/sendmail
 % cd sendmail
 % svn merge -c r261190 '^/vendor/sendmail/dist' .

   ^ e um alias para o caminho do repositorio.

  Nota:

   Se estiver usando o shell Zsh, o ^ deve ser escapado com \ ou entre aspas.

   E necessario resolver quaisquer conflitos de mesclagem.

   Certifique-se de que todos os arquivos adicionados ou removidos na arvore
   do fornecedor tenham sido adicionados ou removidos corretamente na arvore
   principal. Para verificar os diffs com relac,ao ao branch do fornecedor:

 % svn diff --no-diff-deleted --old=svn+ssh://repo.freebsd.org/base/vendor/pf/dist --new=.

   O --no-diff-deleted diz ao Subversion para nao reclamar sobre os arquivos
   que estao na arvore do fornecedor, mas que nao estao na arvore principal.
   Coisas que teriam sido removidas antes da importac,ao do fornecedor, como
   os makefiles do fornecedor e os scripts de configurac,ao.

   Usando o CVS, uma vez que um arquivo estava fora do branch do fornecedor,
   ele nao podia ser colocado de volta. Com o Subversion, nao ha nenhum
   conceito dentro ou fora do branch do fornecedor. Se um arquivo que
   anteriormente tinha modificac,oes locais, para fazer com que ele nao
   aparec,a em diffs na arvore do fornecedor, tudo o que tem que ser feito e
   remover qualquer sobra como as tags de versoes do FreeBSD, o que e muito
   mais facil.

   Se alguma mudanc,a for necessaria para o "world" compilar com os novos
   fontes, fac,a-as agora e continue testando ate que tudo seja compilado e
   executado perfeitamente.

      5.4.4.4. Fazendo o commit da Importac,ao de Fornecedores

   Agora e possivel fazer o commit! O commit deve ser feito de tudo de uma so
   vez. Se feito corretamente, a arvore passara de um estado consistente com
   o codigo antigo para um estado consistente com o novo codigo.

      5.4.4.5. A partir do zero

        5.4.4.5.1. Importando para a Arvore do Fornecedor

   Esta sec,ao e um exemplo de importac,ao e marcac,ao do byacc no head.

   Primeiro, prepare o diretorio em vendor:

 % svn co --depth immediates $FSVN/vendor
 % cd vendor
 % svn mkdir byacc
 % svn mkdir byacc/dist

   Agora, importe os fontes para o diretorio dist. Uma vez que os arquivos
   estiverem no lugar, fac,a o svn add dos novos, e entao fac,a o svn commit
   e aplique a tag na versao importada. Para poupar tempo e largura de banda,
   e possivel efetuar diretamente o commit e as marcac,oes de forma remota:

 % svn cp -m "Tag byacc 20120115" $FSVN/vendor/byacc/dist $FSVN/vendor/byacc/20120115

        5.4.4.5.2. Mesclando para o head

   Devido a este ser um novo arquivo, copie-o para a mesclagem:

 % svn cp -m "Import byacc to contrib" $FSVN/vendor/byacc/dist $FSVN/head/contrib/byacc

   Ainda e possivel trabalhar normalmente nos fontes recem importados.

    5.4.5. Revertendo um Commit

   A reversao de um commit para uma versao anterior e bem facil:

 % svn merge -r179454:179453 ROADMAP.txt
 % svn commit

   Alterar a sintaxe do numero, com o negativo significando a reversao de uma
   mudanc,a, tambem pode ser usado:

 % svn merge -c -179454 ROADMAP.txt
 % svn commit

   Isso tambem pode ser feito diretamente no repositorio:

 % svn merge -r179454:179453 svn+ssh://repo.freebsd.org/base/ROADMAP.txt

  Nota:

   E importante assegurar que o mergeinfo esteja correto ao reverter um
   arquivo para permitir que o svn mergeinfo --eligible funcione como
   esperado.

   A reversao da exclusao de um arquivo e um pouco diferente. E necessario
   copiar a versao do arquivo que antecede a exclusao. Por exemplo, para
   restaurar um arquivo que foi excluido na revisao N, restaure a versao N-1:

 % svn copy svn+ssh://repo.freebsd.org/base/ROADMAP.txt@179454
 % svn commit

   ou, igualmente:

 % svn copy svn+ssh://repo.freebsd.org/base/ROADMAP.txt@179454 svn+ssh://repo.freebsd.org/base

   Simplesmente nao recrie o arquivo manualmente e o adicione com o svn add -
   isso fara com que o historico seja perdido.

    5.4.6. Corrigindo Erros

   Por mais que possamos realizar uma cirurgia em uma emergencia, nao planeje
   ou corrija erros por baixo dos panos. Planos para erros permanecem nos
   registros para sempre. Certifique-se de verificar a saida do svn status e
   do svn diff antes de enviar o commit.

   Erros acontecerao, mas eles geralmente podem ser corrigidos sem perturbar.

   No caso de adicionar um arquivo no local errado. A coisa certa a fazer e
   usar o svn move e mover o arquivo para o local correto e fazer o commit.
   Isso altera apenas algumas linhas de metadados no journal do repositorio,
   e os logs serao todos conectados corretamente.

   A coisa errada a fazer e apagar o arquivo e, em seguida, usar svn add para
   adicionar uma copia independente no local correto. Em vez de algumas
   linhas de texto, o repositorio journal cria uma nova copia inteira do
   arquivo. Isso e um desperdicio.

    5.4.7. Usando um Espelho do Subversion

   Ha uma seria desvantagem neste metodo: toda vez que for feito o commit de
   algo, tera que executar um svn relocate no repositorio principal, nao
   esquecendo de executar o svn relocate de volta para o mirror apos o
   commit. Alem disso, como o svn relocate so funciona entre os repositorios
   que possuem o mesmo UUID, algum hacking do UUID do repositorio local deve
   ocorrer antes que seja possivel comec,ar a usa-lo.

      5.4.7.1. Checkout a partir de um Mirror

   Fac,a o checkout de uma copia de trabalho a partir de um mirror
   substituindo a URL do mirror por svn+ssh://repo.freebsd.org/base. Este
   pode ser um mirror oficial ou um mirror mantido usando o svnsync.

      5.4.7.2. Configurando um Mirror svnsync

   Evite configurar um mirror svnsync a menos que haja uma boa razao para
   isso. Na maioria das vezes, um mirror git e uma alternativa melhor.
   Comec,ar um novo mirror do zero leva muito tempo. Espere um minimo de 10
   horas para conectividade de alta velocidade. Se o trafego for passar por
   links internacionais, espere que isso leve de quatro a dez vezes mais.

   Uma maneira de limitar o tempo necessario e pegar um arquivo de seed. Ele
   e grande (~1GB), mas consome menos trafego de rede e leva menos tempo para
   baixar do que o svnsync.

   Extraia o arquivo e o atualize:

 % tar xf svnmirror-base-r261170.tar.xz
 % svnsync sync file:///home/svnmirror/base

   Agora, configure isso para executar a partir do cron(8), fac,a checkouts
   localmente, configure um servidor svnserve para as maquinas locais com as
   quais conversar, etc.

   O mirror seed esta definido para buscar o conteudo a partir de
   svn://svn.freebsd.org/base. A configurac,ao para o mirror e armazenada em
   revprop 0 no mirror local. Para ver a configurac,ao, tente:

 % svn proplist -v --revprop -r 0 file:///home/svnmirror/base

   Use svn propset para mudar as coisas.

    5.4.8. Fazendo commit de dados HighASCII

   Os arquivos que possuem bits high-ASCII sao considerados arquivos binarios
   no SVN, portanto, as verificac,oes de pre-commit falham e indicam que a
   propriedade mime-type deve ser definida como application/octet-stream. No
   entanto, o uso deste e desencorajado, por isso, nao o defina. A melhor
   maneira e sempre evitar dados high-ASCII, para que possam ser lidos em
   qualquer lugar com qualquer editor de texto, mas se nao for possivel
   evitar, em vez de alterar o mime-type, defina a propriedade fbsd:notbinary
   com o propset:

 % svn propset fbsd:notbinary yes foo.data

    5.4.9. Mantendo um branch de projeto

   Uma branch de projeto e aquela que esta sincronizada com o head (ou outra
   branch) e e usada para desenvolver um projeto e, em seguida, fazer o seu
   commit de volta para o head. No SVN, o branch "dolphin" e usado para isso.
   Uma branch "dolphin" e aquela que diverge por um tempo e e finalmente
   enviada de volta ao branch original. Durante a migrac,ao do codigo de
   desenvolvimento em uma direc,ao (do head para o branch apenas). Nao e
   feito o commit de nenhum codigo de volta ao head ate o final. Depois que e
   feito o commit da branch no final, ela estara morta (embora uma nova
   branch com o mesmo nome possa ser criada depois que a que esta morta e
   excluida).

   Como explicado em https://people.FreeBSD.org/~peter/svn_notes.txt, o
   trabalho que destina-se a ser mesclado de volta para o HEAD deve estar em
   base/projects/. Se o trabalho e benefico para a comunidade do FreeBSD de
   alguma forma, mas nao se destina a ser mesclado diretamente no HEAD, entao
   o local apropriado e base/user/username/. Esta pagina contem mais
   detalhes.

   Para criar um branch de projeto:

 % svn copy svn+ssh://repo.freebsd.org/base/head svn+ssh://repo.freebsd.org/base/projects/spif

   Para mesclar as alterac,oes do HEAD de volta ao branch de projeto:

 % cd copy_of_spif
 % svn merge svn+ssh://repo.freebsd.org/base/head
 % svn commit

   E importante resolver quaisquer conflitos de mesclagem antes de fazer o
   commit.

  5.5. Algumas dicas

   Nos logs de commit, etc., "rev 179872" e soletrado "r179872" conforme a
   convenc,ao.

   E possivel acelerar o svn adicionando estas entradas ao ~/.ssh/config:

 Host *
 ControlPath ~/.ssh/sockets/master-%l-%r@%h:%p
 ControlMaster auto
 ControlPersist yes

   e depois digitando

 mkdir ~/.ssh/sockets

   Fazer o check-out de uma copia de trabalho com um cliente Subversion
   padrao sem patches especificos do FreeBSD (OPTIONS_SET=FREEBSD_TEMPLATE)
   significara que as tags $FreeBSD$ nao serao expandidas. Uma vez que a
   versao correta foi instalada, engane o Subversion para expandi-las da
   seguinte forma:

 % svn propdel -R svn:keywords .
 % svn revert -R .

   Isso eliminara os patches para os quais ainda nao foi feito o commit.

   E possivel preencher automaticamente os campos de log de commit "Sponsored
   by" e "MFC after" configurando os campos "freebsd-sponsored-by" e
   "freebsd-mfc-after" na sec,ao "[miscellany]" do arquivo de configurac,ao
   ~/.subversion/config. Por exemplo:

 freebsd-sponsored-by = The FreeBSD Foundation
 freebsd-mfc-after = 2 weeks

6. Configurac,ao, Convenc,oes e Tradic,oes

   Existe uma serie de coisas para fazer como um novo desenvolvedor. O
   primeiro conjunto de etapas e especifico apenas para os committers. Essas
   etapas devem ser feitas por um mentor para aqueles que nao sao committers.

  6.1. Para novos committers

   Aqueles que receberam direitos de commit para os repositorios do FreeBSD
   devem seguir estes passos.

     * Obtenha a aprovac,ao do seu mentor antes de fazer o commit de cada uma
       dessas mudanc,as!

     * Os arquivos .ent e .xml mencionados abaixo existem no repositorio SVN
       do Projeto de Documentation do FreeBSD em
       svn+ssh://repo.FreeBSD.org/doc/.

     * Novos arquivos que nao possuem a propriedade FreeBSD=%H svn:keywords
       serao rejeitados quando voce tentar fazer o commit dos mesmos para o
       repositorio. Certifique-se de ler Sec,ao 5.3.7, "Adicionando e
       Removendo Arquivos" sobre como adicionar e remover arquivos. Verifique
       se o ~/.subversion/config contem as entradas necessarias de
       "auto-props" do auto-props.txt mencionado la.

     * Todos os commits do src vao para o FreeBSD-CURRENT antes de serem
       mesclados para o FreeBSD-STABLE. A branch do FreeBSD-STABLE deve
       manter a compatibilidade de ABI e de API com as versoes anteriores
       dessa branch. Nao mescle as alterac,oes que quebram essa
       compatibilidade.

   Procedimento 1. Etapas para os novos committers
    1. Adicione uma entidade de autor

       doc/head/share/xml/authors.ent - Adicione uma entidade de autor.
       Etapas posteriores dependem dessa entidade, e a falta dessa etapa fara
       com que a compilac,ao do doc/ falhe. Essa e uma tarefa relativamente
       facil, mas continua sendo um bom primeiro teste de habilidades no
       controle de versao.

    2. Atualize a lista de desenvolvedores e colaboradores

       doc/head/en_US.ISO8859-1/articles/contributors/contrib.committers.xml
       - Adicione uma entrada `a sec,ao "Desenvolvedores" da Lista de
       Contribuidores. As entradas sao classificadas pelo sobrenome.

       doc/head/en_US.ISO8859-1/articles/contributors/contrib.additional.xml
       - Remova a entrada da sec,ao "Contribuidores Adicionais". As entradas
       sao classificadas pelo primeiro nome.

    3. Adicione um item de noticias

       doc/head/share/xml/news.xml - Adicione uma entrada. Procure por outras
       entradas que anunciam novos committers e siga o formato. Use a data do
       email de aprovac,ao do <core@FreeBSD.org> para o commit bit.

    4. Adicione uma chave PGP

       doc/head/share/pgpkeys/pgpkeys.ent e
       doc/head/share/pgpkeys/pgpkeys-developers.xml - Adicione a sua chave
       PGP ou GnuPG. Aqueles que ainda nao tem uma chave devem ver
       Sec,ao 2.1, "Criando uma chave".

       O Dag-Erling Smo/rgrav <des@FreeBSD.org> escreveu um script de shell
       (doc/head/share/pgpkeys/addkey.sh) para tornar isto mais facil.
       Consulte o arquivo README para obter mais informac,oes.

       Use o doc/head/share/pgpkeys/checkkey.sh para verificar se as chaves
       atendem aos padroes minimos das boas praticas recomendadas.

       Depois de adicionar e verificar uma chave, adicione os dois arquivos
       atualizados ao controle de versao do codigo fonte, e em seguida fac,a
       o commit. As entradas neste arquivo sao classificadas pelo sobrenome.

  Nota:

       E muito importante ter uma chave PGP/GnuPG atualizada no repositorio.
       A chave pode ser necessaria para a identificac,ao positiva de um
       committer. Por exemplo, os Administradores do FreeBSD
       <admins@FreeBSD.org >podem precisar dela para a recuperac,ao da conta.
       Um chaveiro completo dos usuarios do FreeBSD.org esta disponivel para
       download em https://www.FreeBSD.org/doc/pgpkeyring.txt.

    5. Atualize as informac,oes do Mentor e do Mentee

       base/head/share/misc/committers-repository.dot - Adicione uma entrada
       `a sec,ao committers atuais, onde repository e doc, ports, ou src,
       dependendo dos privilegios de commit concedidos.

       Adicione uma entrada para cada relacionamento adicional de
       mentor/mentee na sec,ao inferior.

    6. Gere uma senha do Kerberos

       Veja Sec,ao 3, "Kerberos e LDAP Web Password para o cluster do
       FreeBSD" para gerar ou definir um Kerberos para uso com outros
       servic,os do FreeBSD, como o banco de dados de rastreamento de bugs.

    7. Opcional: Ative a sua conta na Wiki

       Conta no Wiki do FreeBSD - Uma conta no wiki permite que compartilhe
       projetos e ideias. Aqueles que ainda nao tem uma conta podem seguir as
       instruc,oes da Pagina Sobre a Wiki para obter uma. Entre em contato
       com <wikiadmin@FreeBSD.org> se precisar de ajuda com sua conta no
       Wiki.

    8. Opcional: Atualize informac,oes do Wiki

       Informac,oes do Wiki - Depois de obter acesso ao wiki, algumas pessoas
       adicionam entradas nas paginas How We Got Here, IRC Nicks e Dogs of
       FreeBSD paginas.

    9. Opcional: Atualize o Ports com as suas Informac,oes Pessoais

       ports/astro/xearth/files/freebsd.committers.markers e
       src/usr.bin/calendar/calendars/calendar.freebsd - Algumas pessoas
       adicionam entradas para elas nestes arquivos para mostrar onde estao
       localizadas ou a data de seu aniversario.

   10. Opcional: Evite Correspondencias Duplicadas

       Assinantes das listas svn-src-all, svn-ports-all ou da svn-doc-all
       podem desejar cancelar a assinatura para evitar receber copias
       duplicadas de mensagens de commit e de followups.

  6.2. Para todos

    1. Apresente-se aos outros desenvolvedores, caso contrario, ninguem fara
       a menor ideia de quem voce e ou no que voce esta trabalhando. A
       introduc,ao nao precisa ser uma biografia abrangente, basta escrever
       um paragrafo ou dois sobre quem voce e, em que voce planeja trabalhar
       como desenvolvedor no FreeBSD e quem sera seu mentor. Envie os
       paragrafos por e-mail para a lista de discussao dos desenvolvedores do
       FreeBSD e voce estara a caminho!

    2. Entre na freefall.FreeBSD.org e crie um arquivo /var/forward/user (no
       qual user e seu nome de usuario) contendo o enderec,o de e-mail para o
       qual voce deseja que o correio enderec,ado para
       yourusername@FreeBSD.org seja encaminhado. Isto inclui todas as
       mensagens de commit assim como qualquer outro email enderec,ado `a
       lista de discussao dos committers do FreeBSD e `a lista de discussao
       dos desenvolvedores do FreeBSD. Caixas de correio realmente grandes
       que tenham residencia permanente na freefall podem ser truncadas sem
       aviso se o espac,o precisar ser liberado, entao encaminhe suas
       mensagens ou salve-as em outro lugar.

  Nota:

       Se o seu sistema de e-mail usa SPF com regras estritas, voce deve
       colocar o host mx2.FreeBSD.org na whitelist de verificac,oes do SPF.

       Devido ao load severo imposto aos servidores centrais que fazem o
       processamento da lista de discussao devido ao grande volume de SPAMs,
       o servidor de front-end faz algumas verificac,oes basicas e descarta
       algumas mensagens com base nessas verificac,oes. No momento, as
       informac,oes de DNS adequadas para o host de conexao sao a unica
       verificac,ao ativa, mas isso pode mudar. Algumas pessoas culpam estas
       verificac,oes por rejeitar e-mails validos. Para que essas
       verificac,oes sejam desativadas no seu email, crie um arquivo chamado
       ~/.spam_lover no servidor freefall.FreeBSD.org.

  Nota:

   Aqueles que sao desenvolvedores, mas nao sao committers, nao serao
   inscritos nas listas de discussao de desenvolvedores ou de committers. As
   assinaturas sao derivadas dos direitos de acesso.

    6.2.1. Configurac,ao de acesso SMTP

   Para aqueles dispostos a enviar mensagens de e-mail atraves da
   infraestrutura do FreeBSD.org, siga as instruc,oes abaixo:

    1. Aponte seu cliente de e-mail para smtp.FreeBSD.org:587.

    2. Habilite o STARTTLS.

    3. Assegure-se de que seu enderec,o From: esteja configurado para
       yourusername@FreeBSD.org.

    4. Para autenticac,ao, voce pode usar o seu nome de usuario e a sua senha
       do Kerberos no cluster do FreeBSD (veja Sec,ao 3, "Kerberos e LDAP Web
       Password para o cluster do FreeBSD"). O principal yourusername/mail e
       o preferido, pois e valido apenas para autenticac,ao dos recursos de
       correio.

  Nota:

       Nao inclua @FreeBSD.org ao digitar seu nome de usuario.

  Notas Adicionais:

     * Aceitara apenas mensagens de yourusername@FreeBSD.org. Se voce for
       autenticado como um usuario, nao tera permissao para enviar e-mails
       como outro.

     * Um cabec,alho sera anexado com o nome de usuario do SASL:
       (Authenticated sender: username).

     * O host possui varios limites de taxa para reduzir as tentativas de
       forc,a bruta.

      6.2.1.1. Usando um MTA Local para Encaminhar Emails para o Servic,o SMTP
      do FreeBSD.org

   Tambem e possivel usar um MTA local para encaminhar emails enviados
   localmente para os servidores SMTP do FreeBSD.org.

   Exemplo 1. Usando o Postfix

   Para dizer a uma instancia local do Postfix que qualquer email de
   yourusername@FreeBSD.org deve ser encaminhado para os servidores do
   FreeBSD.org, adicione isto ao seu main.cf:

 sender_dependent_relayhost_maps = hash:/usr/local/etc/postfix/relayhost_maps
 smtp_sasl_auth_enable = yes
 smtp_sasl_security_options = noanonymous
 smtp_sasl_password_maps = hash:/usr/local/etc/postfix/sasl_passwd
 smtp_use_tls = yes

   Crie /usr/local/etc/postfix/relayhost_maps com o seguinte conteudo:

 yourusername@FreeBSD.org  [smtp.freebsd.org]:587

   Crie /usr/local/etc/postfix/sasl_passwd com o seguinte conteudo:

 [smtp.freebsd.org]:587          yourusername:yourpassword

   Se o servidor de email for usado por outras pessoas, talvez voce queira
   impedir que elas enviem emails do seu enderec,o. Para configurar isso,
   adicione estas entradas ao seu main.cf:

 smtpd_sender_login_maps = hash:/usr/local/etc/postfix/sender_login_maps
 smtpd_sender_restrictions = reject_known_sender_login_mismatch

   Crie /usr/local/etc/postfix/sender_login_maps com o seguinte conteudo:

 yourusername@FreeBSD.org yourlocalusername

   Onde yourlocalusername e o usuario SASL utilizado para conectar na
   instancia local do Postfix.

  6.3. Mentores

   Todos os novos desenvolvedores tem um mentor atribuido a eles nos
   primeiros meses. Um mentor e responsavel por ensinar ao aprendiz as regras
   e convenc,oes do projeto e orientar seus primeiros passos na comunidade de
   desenvolvedores. O mentor tambem e pessoalmente responsavel pelas ac,oes
   do aprendiz durante este periodo inicial.

   Para committers: nao fac,a nenhum commit sem antes obter a aprovac,ao do
   seu mentor. Documente essa aprovac,ao com uma linha Approved by: na
   mensagem de commit.

   Quando o mentor decide que um aprendiz ja aprendeu o necessario e esta
   pronto para fazer commits por conta propria, o mentor anuncia o fato com
   um commit no conf/mentors. Este arquivo esta na branch svnadmin de cada
   repositorio:

   src   base/svnadmin/conf/mentors  
   doc   doc/svnadmin/conf/mentors   
   ports ports/svnadmin/conf/mentors 

   Os novos committers devem ter como objetivo realizar commits o suficiente
   para que seu mentor se sinta confortavel em libera-los da mentoria no
   primeiro ano. Se eles ainda estiverem sob orientac,ao, o corpo gerencial
   apropriado (core, doceng ou portmgr) deve tentar garantir que nao haja
   barreiras que impec,am a conclusao. Se o committer nao for capaz de
   satisfazer seu mentor de prontidao por um ano e meio, seu commit bit pode
   ser convertido para membro do projeto.

7. Revisao pre-commit

   A revisao de codigo e uma maneira de aumentar a qualidade do software. As
   seguintes diretrizes se aplicam a commits na ramificac,ao head (-CURRENT)
   do repositorio src. Outras ramificac,oes e as arvores do ports e do docs
   tem suas proprias politicas de revisao, mas essas diretrizes geralmente se
   aplicam a commits que exigem revisao:

     * Todas as alterac,oes nao triviais devem ser revisadas antes de serem
       cometidas no repositorio.

     * As revisoes podem ser conduzidas por e-mail, pelo Bugzilla, pelo
       Phabricator ou por outro mecanismo. Sempre que possivel, as revisoes
       devem ser publicas.

     * O desenvolvedor responsavel por uma mudanc,a de codigo tambem e
       responsavel por fazer todas as alterac,oes necessarias relacionadas `a
       revisao.

     * A revisao de codigo pode ser um processo iterativo, que continua ate
       que o patch esteja pronto para o commit. Especificamente, uma vez que
       um patch e enviado para revisao, ele deve receber um explicito "looks
       good" antes que o commit possa ser feito. Desde que a aprovac,ao seja
       explicita, ela pode ser formalizada de qualquer forma que fac,a
       sentido para o metodo de revisao.

     * Timeouts nao sao um substituto para revisao.

   As vezes, as revisoes de codigo demoram mais tempo do que voce esperaria,
   especialmente para recursos maiores. As formas aceitas de acelerar os
   tempos de revisao dos seus patches sao:

     * Revise os patches de outras pessoas. Se voce ajudar, todos estarao
       mais dispostos a fazer o mesmo por voce; A boa vontade e a nossa
       moeda.

     * Ping o patch. Se for urgente, fornec,a as razoes pelas quais e
       importante para voce finaliza-lo e fac,a o ping a cada dois dias. Se
       nao for urgente, a frequencia adequada de ping e de uma vez por
       semana. Lembre-se de que voce esta pedindo um tempo valioso de outros
       desenvolvedores profissionais.

     * Pec,a ajuda em listas de discussao, IRC, etc. Outros podem ajuda-lo
       diretamente ou sugerir um revisor.

     * Dividir seu patch em varios patches pequenos os quais se aplicam uns
       sobre os outros. Quanto menor o seu patch, maior a probabilidade de
       alguem dar uma rapida olhada nele.

       Ao fazer grandes mudanc,as, e util ter isso em mente desde o inicio do
       esforc,o, pois quebrar grandes alterac,oes em pequenas e geralmente
       dificil depois que estao prontas.

   Os desenvolvedores devem participar de revisoes de codigo fazendo revisoes
   e recebendo revisoes. Se alguem tiver a gentileza de revisar seu codigo,
   voce deve devolver o favor a outra pessoa. Observe que, embora qualquer
   pessoa seja bem-vinda para revisar e dar feedback sobre um patch, apenas
   um especialista no assunto apropriado pode aprovar uma alterac,ao.
   Geralmente, este especialista sera um committer que trabalha com o codigo
   em questao regularmente.

   Em alguns casos, nenhum especialista no assunto pode estar disponivel.
   Nesses casos, uma revisao por um desenvolvedor experiente e suficiente
   quando associada a testes apropriados.

8. Mensagens de Log de Commit

   Esta sec,ao contem algumas sugestoes e tradic,oes de como os logs de
   commit sao formatados.

   Alem de incluir uma mensagem informativa com cada commit, algumas
   informac,oes adicionais podem ser necessarias.

   Essas informac,oes consistem em uma ou mais linhas contendo a
   palavra-chave ou frase, dois-pontos, guias para formatac,ao e, em seguida,
   as informac,oes adicionais.

   As palavras ou frases-chave sao:

                  O relatorio do problema (se houver) que e afetado           
   PR:            (normalmente, por estar fechado) por este commit. Varios    
                  PRs podem ser especificados em uma linha, separados por     
                  virgulas ou espac,os.                                       
                  O nome e o enderec,o de e-mail da pessoa que enviou a       
                  correc,ao; para desenvolvedores, apenas o nome de usuario   
                  no cluster do FreeBSD.                                      
                                                                              
   Submitted by:  Se o requisitante for o mantenedor do port que esta sendo   
                  atualizado pelo commit, inclua "(maintainer)" apos o        
                  enderec,o de e-mail.                                        
                                                                              
                  Evite ofuscar o enderec,o de e-mail do remetente, pois isso 
                  adiciona trabalho adicional ao pesquisar os registros.      
                  O nome e o enderec,o de e-mail da pessoa ou pessoas que     
                  revisaram a alterac,ao; para desenvolvedores, apenas o nome 
   Reviewed by:   de usuario no cluster do FreeBSD. Se um patch foi submetido 
                  a uma lista de discussao para revisao e a revisao foi       
                  favoravel, basta incluir o nome da lista.                   
                  O nome e enderec,o de e-mail da pessoa ou pessoas que       
                  aprovaram a alterac,ao; para desenvolvedores, apenas o nome 
                  de usuario no cluster do FreeBSD. E costume obter           
                  aprovac,ao previa para um commit se for para uma area da    
                  arvore na qual voce normalmente nao faz commit. Alem disso, 
                  durante a preparac,ao para uma nova versao, todos os        
                  commits devem ser aprovados pela equipe de engenharia de    
                  release.                                                    
                                                                              
   Approved by:   Enquanto estiver sob orientac,ao, obtenha aprovac,ao do     
                  mentor antes do commit. Digite o nome de usuario do mentor  
                  neste campo e adicione uma nota de que ele e um mentor:     
                                                                              
                  Approved by: username-of-mentor (mentor)                    
                                                                              
                  Se uma equipe aprovou esses commits, inclua o nome da       
                  equipe seguido do nome de usuario do aprovador entre        
                  parenteses. Por exemplo:                                    
                                                                              
                  Approved by: re (username)                                  
   Obtained from: O nome do projeto (se houver) do qual o codigo foi obtido.  
                  Nao use esta linha para o nome de uma pessoa individual.    
                  Organizac,oes patrocinadoras dessa mudanc,a, se houver.     
                  Separe varias organizac,oes com virgulas. Se apenas uma     
                  parte do trabalho foi patrocinada, ou diferentes montantes  
                  de patrocinio foram fornecidos a diferentes autores, por    
                  favor, fornec,a os devidos creditos entre parenteses apos   
   Sponsored by:  cada nome de patrocinador. Por exemplo, Example.com (alice, 
                  refatorac,ao de codigo), Wormulon (bob), Momcorp (cindy)    
                  mostra que Alice foi patrocinada pela Example.com para      
                  refatorac,ao de codigo, enquanto Wormulon patrocinou o      
                  trabalho de Bob e a Momcorp patrocinou o trabalho de Cindy. 
                  Outros autores nao foram patrocinados ou optaram por nao    
                  listar o patrocinio.                                        
                  Para receber um lembrete por e-mail para o MFC em uma data  
   MFC after:     posterior, especifique o numero de dias, semanas ou meses   
                  apos os quais um MFC esta planejado.                        
   MFC to:        Se o commit deve ser mesclado em um subconjunto de branches 
                  estaveis, especifique os nomes das branchs.                 
                  Se o commit deve ser mesclado junto com um commit anterior  
   MFC with:      em um unico MFC (por exemplo, onde o commit corrige um bug  
                  da alterac,ao anterior), especifique o numero de revisao    
                  correspondente.                                             
   Relnotes:      Se a alterac,ao for candidata a inclusao nas notas de       
                  lanc,amento da proxima versao da branch, defina como yes.   
                  Se a alterac,ao estiver relacionada a uma vulnerabilidade   
   Security:      de seguranc,a ou exposic,ao de seguranc,a, inclua uma ou    
                  mais referencias ou uma descric,ao do problema. Se          
                  possivel, inclua um URL VuXML ou um ID CVE.                 
                  Descric,ao para o evento em que essa confirmac,ao foi       
                  feita. Se este for um evento recorrente, adicione o ano ou  
                  ate mesmo o mes. Por exemplo, isso pode ser FooBSDcon 2019  
                  . A ideia por tras dessa linha e dar reconhecimento a       
   Evento:        conferencias, reunioes e outros tipos de reunioes e mostrar 
                  que elas sao uteis. Por favor, nao use a linha Patrocinado  
                  por: para isso, pois isso significa que as organizac,oes    
                  patrocinam determinados recursos ou desenvolvedores que     
                  trabalham neles.                                            
   Differential   A URL completa da revisao do Phabricator. Esta linha deve   
   Revision:      ser a ultima linha . Por exemplo:                           
                  https://reviews.freebsd.org/D1708.                          

   Exemplo 2. Commit Log para um commit baseado em um PR

   O commit e baseado em um patch de um PR enviado por John Smith. Os campos
   da mensagem de commit "PR" e "Submitted by" sao preenchidos.

 ...

             PR:                    12345
             Submitted by:          John Smith <John.Smith@example.com>

   Exemplo 3. Commit log de um commit que precisa de revisao

   O sistema de memoria virtual esta sendo alterado. Depois de enviar os
   patches para a lista de discussao apropriada (neste caso, freebsd-arch) e
   as mudanc,as foram aprovadas.

 ...

             Reviewed by:       -arch

   Exemplo 4. Commit log de um commit que precisa de aprovac,ao

   Commit um port, depois de trabalhar com o MAINTAINER, que disse para ir em
   frente e executar o commit.

 ...

             Approved by:            abc (maintainer)

   No qual o abc e o nome da conta da pessoa que aprovou.

   Exemplo 5. Commit log de um commit que importa codigo do OpenBSD

   Efetuando o commit de codigos baseados no trabalho feito no projeto
   OpenBSD.

 ...

             Obtained from:      OpenBSD

   Exemplo 6. Commit Log para uma mudanc,a no FreeBSD-CURRENT com um commit
   planejado para o FreeBSD-STABLE para seguir em uma data posterior.

   Efetuando o commit de codigos que serao mesclados do FreeBSD-CURRENT na
   branch do FreeBSD-STABLE apos duas semanas.

 ...

 MFC after:      2 weeks

   Onde 2 e o numero de dias, semanas ou meses apos o qual um MFC e
   planejado. A opc,ao weeks pode ser day, dias, semana, semanas, mes, meses.

   Muitas vezes e necessario combinar isso.

   Considere a situac,ao em que um usuario enviou um codigo contendo o PR do
   projeto NetBSD. Olhando para o PR, o desenvolvedor ve que nao e uma area
   da arvore na qual eles normalmente trabalham, entao eles tem a mudanc,a
   revisada pela lista de discussao arch. Como a mudanc,a e complexa, o
   desenvolvedor opta pelo MFC apos um mes para permitir testes adequados.

   A informac,ao extra para incluir no commit seria algo como

   Exemplo 7. Exemplo de log de commit combinado

 PR:                 54321
 Submitted by:       John Smith <John.Smith@example.com>
 Reviewed by:        -arch
 Obtained from:      NetBSD
 MFC after:          1 month
 Relnotes:           yes

9. Licenc,a preferida para novos arquivos

   A politica de licenc,a completa do Projeto FreeBSD pode ser encontrada em
   https://www.FreeBSD.org/internal/software-license.html. O restante desta
   sec,ao destina-se a ajuda-lo a comec,ar. Por via de regra, quando em
   duvida, pergunte. E muito mais facil dar conselhos do que consertar a
   arvore de codigo fonte.

   O Projeto FreeBSD sugere e usa este texto como o esquema de licenc,a
   preferencial:

 /*-
  * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
  *
  * Copyright (c) [year] [your name]
  *
  * 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.
  *
  * [id for your version control system, if any]
  */

   O projeto FreeBSD desencoraja fortemente a chamada "clausula publicitaria"
   no novo codigo. Devido ao grande numero de contribuidores para o projeto
   FreeBSD, o cumprimento desta clausula para muitos fornecedores comerciais
   se tornou dificil. Se voce tiver um codigo na arvore com a clausula de
   publicidade, considere remove-lo. Na verdade, considere usar a licenc,a
   acima para o seu codigo.

   O projeto FreeBSD desencoraja completamente novas licenc,as e variac,oes
   nas licenc,as padroes. Novas licenc,as requerem a aprovac,ao do Core Team
   <core@FreeBSD.org> para residir no repositorio principal. Quanto mais
   licenc,as diferentes forem usadas na arvore, mais problemas isso causara
   para aqueles que desejarem utilizar esse codigo, geralmente de
   consequencias nao intencionais de uma licenc,a mal formulada.

   A politica do projeto determina que o codigo sob algumas licenc,as nao-BSD
   deve ser colocado apenas em sec,oes especificas do repositorio e, em
   alguns casos, a compilac,ao deve ser condicional ou ate mesmo desativada
   por padrao. Por exemplo, o kernel GENERIC deve ser compilado apenas sob
   licenc,as identicas ou substancialmente semelhantes `a licenc,a BSD. O
   software licenciado GPL, APSL, CDDL, etc, nao deve ser compilado no
   GENERIC.

   Os desenvolvedores sao lembrados de que, em codigo aberto, ficar "aberto"
   corretamente e tao importante quanto obter o "fonte" correto, ja que o
   manuseio inadequado da propriedade intelectual tem serias consequencias.
   Quaisquer duvidas ou preocupac,oes devem imediatamente ser levadas `a
   atenc,ao do Core Team.

10. Acompanhando as Licenc,as Concedidas ao Projeto FreeBSD

   Varios softwares ou dados existem nos repositorios onde o projeto FreeBSD
   recebeu uma licenc,a especial para poder usa-los. Um caso em questao sao
   as fontes do Terminus para uso com o vt(4). Aqui, o autor Dimitar Zhekov
   nos permitiu usar a fonte "Terminus BSD Console" sob uma licenc,a BSD de 2
   clausulas, em vez da licenc,a Open Font License que ele normalmente usa.

   E claramente sensivel manter um registro de tais concessoes de licenc,a.
   Para esse fim, o Core Team <core@FreeBSD.org> decidiu manter um arquivo
   delas. Sempre que o projeto FreeBSD receber uma licenc,a especial, nos
   exigimos que o Core Team <core@FreeBSD.org> seja notificado. Qualquer
   desenvolvedor envolvido na obtenc,ao de tal concessao de licenc,a, por
   favor envie os detalhes para o Core Team <core@FreeBSD.org> incluindo:

     * Detalhes de contato para as pessoas ou organizac,oes que concederam a
       licenc,a especial.

     * Quais arquivos, diretorios etc. nos repositorios sao cobertos pela
       concessao da licenc,a, incluindo os numeros de revisao dos commits nos
       quais qualquer material especialmente licenciado tenha sido
       incorporado.

     * A data em que a licenc,a entra em vigor. Salvo acordo em contrario,
       esta sera a data em que a licenc,a foi emitida pelos autores do
       software em questao.

     * O texto da licenc,a.

     * Uma nota de quaisquer restric,oes, limitac,oes ou excec,oes que se
       aplicam especificamente ao uso do material licenciado pelo FreeBSD.

     * Qualquer outra informac,ao relevante.

   Uma vez que o Core Team <core@FreeBSD.org> esteja satisfeito de que todos
   os detalhes necessarios foram reunidos e estao corretos, o secretario
   enviara um aviso de recebimento assinado com o PGP, incluindo os detalhes
   da licenc,a. Esse recibo sera persistentemente arquivado e servira como
   nosso registro permanente da concessao da licenc,a.

   O arquivo de licenc,a deve conter apenas detalhes das concessoes de
   licenc,a; este nao e o lugar para qualquer discussao em torno de
   licenciamento ou outros assuntos. O acesso aos dados dentro do arquivo de
   licenc,a estara disponivel mediante solicitac,ao para o Core Team
   <core@FreeBSD.org>.

11. Relac,oes entre os Desenvolvedores

   Ao trabalhar diretamente em seu proprio codigo ou em um codigo que ja
   esteja bem estabelecido como sua responsabilidade, provavelmente havera
   pouca necessidade de verificar com outros committers antes de entrar com
   um commit. Ao trabalhar em um bug em uma area do sistema que e claramente
   orfa (e existem algumas dessas areas, para nossa vergonha), o mesmo se
   aplica. Ao modificar partes do sistema que sao mantidas, formalmente ou
   informalmente, considere solicitar uma revisao exatamente como um
   desenvolvedor teria de fazer antes de se tornar um committer. Para os
   ports, entre em contato com o MAINTAINER listado no Makefile.

   Para determinar se uma area da arvore e mantida, verifique o arquivo
   MAINTAINERS na raiz da arvore. Se ninguem estiver listado, analise o
   historico de revisoes para ver quem fez o commit de alterac,oes no
   passado. Um script de exemplo que lista cada pessoa que ja fez commit de
   um determinado arquivo junto com o numero de commits que cada pessoa fez
   pode ser encontrado na freefall em ~eadler/bin/whodid. Se as consultas nao
   forem atendidas ou se o committer indicar uma falta de interesse na area
   afetada, va em frente e fac,a o commit.

  Importante:

   Evite enviar e-mails privados para os mantenedores. Outras pessoas podem
   estar interessadas na conversa, nao apenas no resultado final.

   Se houver qualquer duvida sobre um commit por qualquer razao, submeta-o ao
   processo de revisao antes de faze-lo. E melhor fazer com que ele seja
   criticado la e nao quando ele ja fizer parte do repositorio. Se um commit
   resulta em controversia, pode ser aconselhavel considerar a possibilidade
   de fazer o rollback do commit ate que o assunto seja resolvido. Lembre-se,
   com um sistema de controle de versao, podemos sempre altera-lo de volta.

   Nao impugne as intenc,oes dos outros. Se eles veem uma soluc,ao diferente
   para um problema, ou ate um problema diferente, provavelmente nao e porque
   eles sao estupidos, porque eles tem parentesco questionavel, ou porque
   eles estao tentando destruir o trabalho duro, a imagem pessoal ou o
   FreeBSD, mas basicamente porque eles tem uma visao diferente do mundo.
   Diferente e bom.

   Discorde honestamente. Argumente sua posic,ao com base em seus meritos,
   seja honesto quanto a quaisquer deficiencias que possa ter, e esteja
   aberto para ver a soluc,ao deles, ou mesmo a visao deles do problema, com
   uma mente aberta.

   Aceite a correc,ao. Somos todos faliveis. Quando voce cometer um erro,
   pec,a desculpas e continue com a vida. Nao se bata, e certamente nao
   espanque os outros por seu erro. Nao perca tempo com constrangimentos ou
   recriminac,oes, apenas conserte o problema e siga em frente.

   Pec,a por ajuda. Procure (e de) revisoes dos seus pares. Uma das maneiras
   pelas quais o software de codigo aberto deve se sobressair e no numero de
   globos oculares aplicados a ele; isso nao se aplica se ninguem revisar o
   codigo.

12. Se em duvida...

   Quando nao tiver certeza sobre algo, seja um problema tecnico ou uma
   convenc,ao do projeto, nao se esquec,a de perguntar. Se voce ficar em
   silencio, nunca fara progressos.

   Se estiver relacionado a um problema tecnico, pergunte nas listas publicas
   de discussao. Evite a tentac,ao de enviar e-mail para a pessoa que conhece
   a resposta. Dessa forma, todos poderao aprender com a pergunta e a
   resposta.

   Para perguntas especificas ou administrativas do projeto, pergunte na
   seguinte ordem:

     * Seu mentor ou ex-mentor.

     * Um committer experiente no IRC, email, etc.

     * Qualquer equipe com um "hat" (chapeu), uma vez que eles podem lhe dar
       uma resposta definitiva.

     * Se ainda nao tiver certeza, pergunte na lista de discussao dos
       desenvolvedores do FreeBSD.

   Uma vez que sua pergunta seja respondida, se ninguem lhe indicou a
   documentac,ao que soletra a resposta para sua pergunta, documente-a, pois
   outros terao a mesma pergunta no futuro.

13. Bugzilla

   O Projeto FreeBSD utiliza o Bugzilla para rastrear bugs e requisic,oes de
   alterac,ao. Certifique-se de fechar o PR caso voce fac,a o commit de uma
   correc,ao ou sugestao encontrada no banco de dados de PR. Tambem e
   considerada uma boa pratica voce reservar um tempo para fechar qualquer PR
   associado aos seus commits, se apropriado.

   Committers com contas nao-FreeBSD.org no Bugzilla podem ter a conta antiga
   mesclada com a conta FreeBSD.org seguindo estes passos:

    1. Fac,a o login usando sua conta antiga.

    2. Abra um novo bug. Escolha Services como o Produto e Bug Tracker como o
       Componente. Na descric,ao de erros liste as contas que voce deseja
       mesclar.

    3. Fac,a o login usando a conta do FreeBSD.org e poste um comentario no
       bug recem-aberto para confirmar a propriedade. Veja Sec,ao 3,
       "Kerberos e LDAP Web Password para o cluster do FreeBSD" para mais
       detalhes sobre como gerar ou definir uma senha para sua conta
       FreeBSD.org.

    4. Se houver mais de duas contas para mesclar, poste comentarios de cada
       uma delas.

   Voce pode descobrir mais sobre o Bugzilla em:

     * Diretrizes para manuseio de relatorios de problemas

     * https://www.FreeBSD.org/support.html

14. Phabricator

   O projeto FreeBSD utiliza o Phabricator para solicitac,oes de revisao de
   codigo. Veja a pagina CodeReview no wiki para detalhes.

   Committers com contas nao-FreeBSD.org no Phabricator podem ter a conta
   antiga renomeada para a conta FreeBSD.org seguindo estes passos:

    1. Altere o email da conta do Phabricator para o seu email FreeBSD.org.

    2. Abra um novo bug em nosso bug tracker usando sua conta FreeBSD.org,
       veja Sec,ao 13, "Bugzilla" para mais informac,oes. Escolha Services
       como o Produto e Code Review como o Componente. Na descric,ao de bugs,
       solicite que a sua conta do Phabricator seja renomeada e fornec,a um
       link para o usuario do Phabricator. Por exemplo,
       https://reviews.freebsd.org/p/bob_example.com/

  Importante:

   As contas do Phabricator nao podem ser mescladas, por favor, nao abra uma
   nova conta.

15. Quem e quem

   Alem dos repositorios meisters, existem outros membros e equipes do
   projeto FreeBSD que voce provavelmente conhecera no exercicio da sua
   func,ao como committer. Resumidamente, e de forma alguma inclusivamente,
   estes sao:

   Equipe de Engenharia de Documentac,ao <doceng@FreeBSD.org>

           O doceng e o grupo responsavel pela infraestrutura de criac,ao de
           documentac,ao, aprovando de novos committers de documentac,ao e
           garantindo que o website do FreeBSD e a documentac,ao no site FTP
           estao atualizados em relac,ao `a arvore subversion. Nao e um corpo
           de resoluc,ao de conflitos. A grande maioria das discussoes
           relacionadas `a documentac,ao ocorre na lista de discussao do
           projeto de documentac,ao do FreeBSD. Mais detalhes sobre a equipe
           doceng podem ser encontrados em seu charter. Os committers
           interessados em contribuir com a documentac,ao devem se
           familiarizar com o Primer do Projeto de Documentac,ao.

   Glen Barber <gjb@FreeBSD.org>, Konstantin Belousov <kib@FreeBSD.org>,
   Bryan Drewery <bdrewery@FreeBSD.org>, Marc Fonvieille
   <blackend@FreeBSD.org>, Xin Li <delphij@FreeBSD.org>, Colin Percival
   <cperciva@FreeBSD.org> Hiroki Sato <hrs@FreeBSD.org>, Gleb Smirnoff
   <glebius@FreeBSD.org>

           Estes sao os membros da Equipe de Engenharia de Release
           <re@FreeBSD.org>. Essa equipe e responsavel por definir os prazos
           de lanc,amento e por controlar o processo de release. Durante o
           congelamento de codigo, os engenheiros de release tem autoridade
           final sobre todas as alterac,oes no sistema para qualquer branch
           que esteja com status de release pendente. Se ha algo que voce
           deseja mesclar do FreeBSD-CURRENT para o FreeBSD-STABLE (quaisquer
           valores que eles possam ter em um dado momento), estas sao as
           pessoas com quem conversar sobre isso.

   Gordon Tetlow <gordon@FreeBSD.org>

           Gordon Tetlow e o Oficial de Seguranc,a do FreeBSD e supervisiona
           a Equipe Oficial de Seguranc,a <security-officer@FreeBSD.org>.

   Garrett Wollman <wollman@FreeBSD.org>

           Se voce precisar de conselhos sobre aspectos internos obscuros da
           rede ou nao tiver certeza de alguma mudanc,a potencial no
           subsistema de rede que voce tem em mente, Garrett e alguem com
           quem conversar. Garrett tambem e muito conhecedor dos varios
           padroes aplicaveis ao FreeBSD.

   Lista de discussao dos committers do FreeBSD

           svn-src-all, svn-ports-all e svn-doc-all sao as listas de
           discussao que o sistema de controle de versao usa para enviar
           mensagens de commit. Nunca envie e-mail diretamente para essas
           listas. Apenas envie respostas para esta lista quando elas forem
           curtas e estiverem diretamente relacionadas a um commit.

   Lista de discussao dos desenvolvedores do FreeBSD

           Todos os committers estao inscritos na -developers. Esta lista foi
           criada para ser um forum para os problemas da "comunidade" dos
           committers. Exemplos sao a eleic,ao do Core Team, anuncios, etc.

           A lista de discussao dos desenvolvedores do FreeBSD e para uso
           exclusivo dos committers do FreeBSD. Para desenvolver o FreeBSD,
           os committers devem ter a capacidade de discutir abertamente
           assuntos que serao resolvidos antes de serem anunciados
           publicamente. As discussoes francas sobre o trabalho em andamento
           nao sao adequadas para publicac,ao aberta e podem prejudicar o
           FreeBSD.

           Espera-se que todos os committers do FreeBSD nao publiquem ou
           encaminhem mensagens da lista de discussao dos desenvolvedores do
           FreeBSD fora da lista de membros sem a permissao de todos os
           autores. Violadores serao removidos da lista de discussao dos
           desenvolvedores do FreeBSD, resultando em uma suspensao dos
           privilegios de commit. Violac,oes repetidas ou flagrantes podem
           resultar na revogac,ao permanente dos privilegios de commit.

           Nao e a intenc,ao desta lista ser um local para revisoes de codigo
           ou para realizar qualquer discussao tecnica. Na verdade, usa-lo
           como tal prejudica o Projeto FreeBSD, pois da uma sensac,ao de uma
           lista fechada, onde as decisoes gerais que afetam toda a
           comunidade usando o FreeBSD sao feitas sem serem "abertas". Por
           ultimo, mas nao menos importante, nunca, nunca, envie por e-mail a
           lista de discussao dos desenvolvedores do FreeBSD e fac,a CC:/BCC:
           para outra lista do FreeBSD. Nunca, jamais envie email para outra
           lista de emails do FreeBSD e fac,a CC:/BCC: para a lista de
           discussao dos desenvolvedores do FreeBSD. Fazer isso pode diminuir
           muito os beneficios dessa lista.

16. Guia de inicio rapido do SSH

    1. Se voce nao quiser digitar sua senha toda vez que usar o ssh( 1), e
       voce usa chaves para autenticar, o ssh-agent(1) esta la para sua
       conveniencia. Se voce quiser usar o ssh-agent(1), certifique-se de
       executa-lo antes de executar os outros aplicativos. Os usuarios de X,
       por exemplo, geralmente fazem isso a partir do .xsession ou do
       .xinitrc. Veja ssh-agent(1) para detalhes.

    2. Gere um par de chaves usando ssh-keygen(1). O par de chaves sera
       colocado no diretorio $HOME/.ssh/.

  Importante:

       Somente as chaves ECDSA, Ed25519 ou RSA sao suportadas.

    3. Envie sua chave publica ($HOME/.ssh/id_ecdsa.pub,
       $HOME/.ssh/id_ed25519.pub, ou $HOME/.ssh/id_rsa.pub) para a pessoa que
       esta configurando voce como um committer para que ela possa ser
       colocada em yourlogin in /etc/ssh-keys/ na freefall.

   Agora ssh-add(1) pode ser usado para autenticac,ao uma vez por sessao. Ele
   solicita a frase secreta da chave privada e a armazena no agente de
   autenticac,ao (ssh-agent(1)). Use o ssh-add -d para remover as chaves
   armazenadas no agente.

   Teste com um simples comando remoto: ssh freefall.FreeBSD.org ls /usr.

   Para obter mais informac,oes, consulte security/openssh-portable, ssh(1),
   ssh-add(1), ssh-agent(1), ssh-keygen(1), e scp(1).

   Para obter informac,oes sobre como adicionar, alterar ou remover chaves
   ssh(1), consulte este artigo.

17. Disponibilidade do Coverity(R) para os Committers do FreeBSD

   Todos os desenvolvedores do FreeBSD podem obter acesso aos resultados da
   analise do Coverity de todo o software do Projeto FreeBSD. Todos os
   interessados em obter acesso aos resultados de analise das execuc,oes
   automatizadas do Coverity podem se inscrever em Coverity Scan.

   O wiki do FreeBSD inclui um mini-guia para desenvolvedores interessados em
   trabalhar com os relatorios de analise do Coverity(R):
   https://wiki.freebsd.org/CoverityPrevent. Por favor observe que este
   mini-guia so pode ser lido por desenvolvedores do FreeBSD, entao se voce
   nao puder acessar esta pagina, voce tera que pedir a alguem para
   adiciona-lo `a lista de acesso apropriada do Wiki.

   Finalmente, todos os desenvolvedores do FreeBSD que usarao o Coverity(R)
   sao sempre encorajados a pedir mais detalhes e informac,oes sobre o uso,
   publicando quaisquer perguntas na lista de discussao dos desenvolvedores
   do FreeBSD.

18. A Grande Lista de Regras dos Committers do FreeBSD

   Todos os envolvidos com o projeto FreeBSD devem obedecer ao Codigo de
   Conduta disponivel em https:
   //www.FreeBSD.org/internal/code-of-conduct.html. Como committers, voces
   formam a face publica do projeto, e como voce se comporta tem um impacto
   vital na percepc,ao publica disso. Este guia expande as partes do Codigo
   de Conduta especifico para os committers.

    1. Respeite outros committers.

    2. Respeite os outros colaboradores.

    3. Discuta qualquer mudanc,a significativa antes de fazer o commit.

    4. Respeite os mantenedores existentes (se listado no campo MAINTAINER no
       Makefile ou no MAINTAINER no diretorio de nivel superior).

    5. Deve ser feito o rollback de qualquer alterac,ao contestada enquanto
       estiver pendente a resoluc,ao da disputa, se solicitado por um
       mantenedor. Alterac,oes relacionadas `a seguranc,a podem anular os
       desejos de um mantenedor, a criterio do Oficial de Seguranc,a.

    6. As alterac,oes vao para o FreeBSD-CURRENT antes do FreeBSD-STABLE, a
       menos que especificamente permitido pelo engenheiro de release ou a
       menos que elas nao sejam aplicaveis ao FreeBSD-CURRENT. Qualquer
       alterac,ao nao trivial ou nao urgente que seja aplicavel tambem deve
       ser permitida no FreeBSD-CURRENT por pelo menos 3 dias antes da fusao,
       para que tenha tempo suficiente de teste. O engenheiro de release tem
       a mesma autoridade sobre o branch FreeBSD-STABLE, conforme descrito
       para o mantenedor na regra #5.

    7. Nao brigue em publico com outros committers; parece ruim.

    8. Respeite todos os congelamentos de codigo e leia as listas de
       discussao committers e developers em tempo habil para que voce saiba
       quando um congelamento de codigo esta em vigor.

    9. Em caso de duvida em qualquer procedimento, pergunte primeiro!

   10. Teste suas alterac,oes antes de fazer o commit.

   11. Nao commit em software contribuido sem a aprovac,ao explicita dos
       respectivos mantenedores.

   Conforme observado, a quebra de algumas dessas regras pode ser motivo para
   suspensao ou, mediante ofensa repetida, remoc,ao permanente de privilegios
   de commit. Membros individuais do core tem o poder de suspender
   temporariamente os privilegios de commit ate que o core como um todo tenha
   a chance de revisar o problema. No caso de uma "emergencia" (um committer
   causando dano ao repositorio), uma suspensao temporaria tambem pode ser
   feita pelos meisters do repositorio. Apenas uma maioria de 2/3 do core tem
   autoridade para suspender os privilegios de confirmac,ao por mais de uma
   semana ou para remove-los permanentemente. Essa regra nao existe para
   definir o core como um bando de ditadores crueis que podem se livrar
   casualmente de committers como se fossem latas de refrigerante vazias, mas
   para dar ao projeto uma especie de fusivel de seguranc,a. Se alguem esta
   fora de controle, e importante ser capaz de lidar com isso imediatamente,
   em vez de ficar paralisado pelo debate. Em todos os casos, um committer
   cujos privilegios foram suspensos ou revogados tem direito a uma
   "audiencia" com o core, sendo a durac,ao total da suspensao determinada
   naquele momento. Um committer cujos privilegios sao suspensos tambem pode
   solicitar uma revisao da decisao apos 30 dias e a cada 30 dias a partir de
   entao (a menos que o periodo total de suspensao seja inferior a 30 dias).
   Um committer cujos privilegios tenham sido revogados completamente pode
   solicitar uma revisao apos um periodo de 6 meses. Esta politica de revisao
   e estritamente informal e, em todos os casos, o core reserva-se o direito
   de agir ou desconsiderar os pedidos de revisao se eles sentirem que a
   decisao original e a correta.

   Em todos os outros aspectos da operac,ao do projeto, o core e um
   subconjunto de committers e e limitado pelas mesmas regras. So porque
   alguem esta no core isso nao significa que eles tem permissao especial
   para sair de qualquer uma das linhas pintadas aqui; os "poderes especiais"
   do core so sao aplicados quando ele age como um grupo, nao
   individualmente. Como individuos, os membros da equipe principal sao todos
   committers em primeiro lugar e core em segundo.

  18.1. Detalhes

    1. Respeite outros committers.

       Isso significa que voce precisa tratar outros committers como os
       desenvolvedores de grupos pares que eles sao. Apesar de nossas
       tentativas ocasionais de provar o contrario, nao se chega a ser um
       committer por ser estupido e nada incomoda mais do que ser tratado
       dessa maneira por um de seus colegas. Se nos sempre sentimos respeito
       uns pelos outros ou nao (e todo mundo tem dias dificeis), nos ainda
       temos que tratar os outros committers com respeito em todos os
       momentos, em foruns publicos e em emails privados.

       Ser capaz de trabalhar juntos a longo prazo e o maior patrimonio deste
       projeto, muito mais importante do que qualquer conjunto de alterac,oes
       no codigo, e transformar argumentos sobre codigo em problemas que
       afetam nossa capacidade de longo prazo de trabalhar harmoniosamente
       juntos nao vale a pena por qualquer estiramento concebivel da
       imaginac,ao.

       Para cumprir esta regra, nao envie e-mails quando estiver com raiva ou
       de alguma forma se comportar de uma maneira que possa causar uma
       confrontac,ao desnecessaria com os outros. Primeiro acalme-se, entao
       pense em como se comunicar da maneira mais eficaz para convencer as
       outras pessoas de que o seu lado do argumento esta correto, nao apenas
       gaste um pouco de vapor para que voce possa se sentir melhor a curto
       prazo `as custas de uma guerra de longa durac,ao. Isso nao so e uma
       "economia de energia" muito ruim, mas demonstrac,oes repetidas de
       agressao publica que prejudicam nossa capacidade de trabalhar bem
       juntas serao tratadas severamente pela lideranc,a do projeto e podem
       resultar na suspensao ou termino dos seus privilegios de commit. . A
       lideranc,a do projeto levara em considerac,ao as comunicac,oes
       publicas e privadas trazidas a ela. Ela nao buscara a divulgac,ao de
       comunicac,oes privadas, mas levara isso em conta se for oferecida de
       forma voluntaria pelos envolvidos na reclamac,ao.

       Tudo isso nunca e uma opc,ao que a lideranc,a do projeto goste nem um
       pouco, mas a uniao vem em primeiro lugar. Nenhuma quantidade de codigo
       ou de bons conselhos vale a pena se trocar desta forma.

    2. Respeite os outros colaboradores.

       Voce nem sempre foi um committer. Houve uma epoca em que voce era um
       colaborador. Lembre-se disso em todos os momentos. Lembre-se de como
       foi tentar obter ajuda e atenc,ao. Nao se esquec,a de que seu trabalho
       como colaborador foi muito importante para voce. Lembre-se de como
       foi. Nao desencoraje, deprecie ou diminua os colaboradores. Trate-os
       com respeito. Eles sao nossos committers em espera. Eles sao tao
       importantes para o projeto quanto os committers. Suas contribuic,oes
       sao tao validas e tao importantes quanto as suas. Afinal, voce fez
       muitas contribuic,oes antes de se tornar um committer. Sempre se
       lembre disso.

       Considere os pontos levantados sob 1 e aplique-os tambem aos
       contribuidores.

    3. Discuta qualquer mudanc,a significativa antes de fazer o commit.

       O repositorio nao e onde as alterac,oes sao inicialmente submetidas
       para correc,ao ou discussao, isso acontece primeiro nas listas de
       discussao ou pelo uso do servic,o do Phabricator. O commit so
       acontecera quando algo semelhante a um consenso for alcanc,ado. Isso
       nao significa que a permissao seja necessaria antes de corrigir todos
       os erros obvios de sintaxe ou erros ortograficos na pagina manual,
       significa apenas que e bom desenvolver uma ideia de quando a mudanc,a
       proposta nao e tao obvia e requer algum feedback primeiro. As pessoas
       realmente nao se importam com mudanc,as radicais se o resultado for
       algo claramente melhor do que antes, elas simplesmente nao gostam de
       ser surpreendidas por essas mudanc,as. A melhor maneira de
       certificar-se de que as coisas estao no caminho certo e ter o codigo
       revisado por um ou mais committers.

       Em caso de duvida, pec,a por uma revisao!

    4. Respeite os mantenedores existentes, se listados.

       Muitas partes do FreeBSD nao sao "possuidas" no sentido de que
       qualquer individuo especifico ira pular e gritar se voce enviar uma
       alterac,ao para a "sua" area, mas ainda vale a pena verificar
       primeiro. Uma convenc,ao que usamos e colocar uma linha de mantenedor
       no Makefile para qualquer pacote ou subarvore que esteja sendo mantido
       ativamente por uma ou mais pessoas; veja
       https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/developers-handbook/policies.html
       para documentac,ao sobre isso. Nas sec,oes de codigo para quais
       existirem varios mantenedores, os commits nas areas afetadas por um
       mantenedor precisarao ser revisados por pelo menos um outro
       mantenedor. Nos casos em que o "maintainer-ship" de algo nao esta
       claro, consulte os logs do repositorio para os arquivos em questao e
       veja se alguem esta trabalhando recentemente ou predominantemente
       naquela area.

    5. Deve ser feito o rollback de qualquer alterac,ao contestada enquanto
       estiver pendente a resoluc,ao da disputa, se solicitado por um
       mantenedor. Alterac,oes relacionadas `a seguranc,a podem anular os
       desejos de um mantenedor, a criterio do Oficial de Seguranc,a.

       Isso pode ser dificil de engolir em momentos de conflito (quando cada
       lado esta convencido de que eles estao certos, e claro), mas um
       sistema de controle de versao torna desnecessario ter uma disputa em
       andamento quando e muito mais facil simplesmente reverter a mudanc,a
       que gerou a disputa, fac,a com que todos se acalmem novamente e tente
       descobrir qual e a melhor maneira de proceder. Se a mudanc,a acaba por
       ser a melhor coisa depois de tudo, ela pode ser facilmente trazida de
       volta. Se ela nao for, os usuarios nao terao que viver com a mudanc,a
       falsa na arvore enquanto todos estavam ocupados debatendo seus
       meritos. Pessoas muito raramente pedem rollbacks no repositorio, uma
       vez que a discussao geralmente expoe mudanc,as ruins ou controversas
       antes que o commit acontec,a, mas em raras ocasioes o rollback deve
       ser feito sem discussao para que possamos entrar imediatamente da
       discussao do topico para descobrirmos se ele era adequado ou nao.

    6. As alterac,oes vao para o FreeBSD-CURRENT antes do FreeBSD-STABLE, a
       menos que especificamente permitido pelo engenheiro de release ou a
       menos que elas nao sejam aplicaveis ao FreeBSD-CURRENT. Qualquer
       alterac,ao nao trivial ou nao urgente que seja aplicavel tambem deve
       ser permitida no FreeBSD-CURRENT por pelo menos 3 dias antes da fusao,
       para que possa ter tempo suficiente de teste. O engenheiro de
       lanc,amento tem a mesma autoridade sobre o branch FreeBSD-STABLE,
       conforme descrito na regra #5.

       Este e outro problema do tipo "nao discuta sobre isso", ja que e o
       engenheiro de release quem e o responsavel final (e e espancado) se
       uma mudanc,a for ruim. Por favor, respeite isso e de ao engenheiro de
       release a sua total cooperac,ao quando se trata do branch
       FreeBSD-STABLE. O gerenciamento do FreeBSD-STABLE pode frequentemente
       parecer excessivamente conservador para o observador casual, mas
       tambem deve ter em mente o fato de que o conservadorismo deve ser a
       marca do FreeBSD-STABLE e regras diferentes aplicam-se la do que no
       FreeBSD-CURRENT. Tambem nao ha sentido em fazer com que o
       FreeBSD-CURRENT seja um campo de testes se as alterac,oes forem
       mescladas no FreeBSD-STABLE imediatamente. Mudanc,as precisam de uma
       chance de serem testadas pelos desenvolvedores do FreeBSD-CURRENT,
       entao espere algum tempo antes da fusao, a menos que a correc,ao do
       FreeBSD-STABLE seja critica, sensivel ao tempo ou obvia a ponto de
       tornar desnecessario testes adicionais (correc,oes ortograficas nas
       paginas de manual) correc,oes de erros / erros de digitac,ao, etc.) Em
       outras palavras, aplique o bom senso.

       Mudanc,as nas branches de seguranc,a (por exemplo, releng/9.3) devem
       ser aprovadas por um membro da Equipe de Seguranc,a
       <security-officer@FreeBSD.org>, ou em alguns casos , por um membro da
       Equipe de Engenharia de Release<re@FreeBSD.org>.

    7. Nao brigue em publico com outros committers; parece ruim.

       Este projeto tem uma imagem publica a defender e essa imagem e muito
       importante para todos nos, especialmente se quisermos continuar a
       atrair novos membros. Havera ocasioes em que, apesar das melhores
       tentativas de autocontrole de todos, os animos se perdem e palavras de
       raiva sao trocadas. A melhor coisa que pode ser feita nesses casos e
       minimizar os efeitos disso ate que todos tenham esfriado. Nao divulgue
       palavras iradas em publico e nao encaminhe correspondencias privadas
       ou outras comunicac,oes privadas para listas publicas de discussao,
       aliases de mensagens, canais de mensagens instantaneas ou sites de
       midia social. O que as pessoas dizem um-para-um e frequentemente muito
       menos revestido de ac,ucar do que o que eles diriam em publico, e tais
       comunicac,oes, portanto, nao tem lugar la - elas servem apenas para
       inflamar uma situac,ao ja ruim. Se a pessoa que enviou um
       flame-o-grama tiver pelo menos a elegancia de envia-lo em particular,
       entao tenha a elegancia de mante-lo em sigilo. Se voce acha que esta
       sendo tratado injustamente por outro desenvolvedor e esta lhe causando
       angustia, traga o assunto para o core em vez de torna-lo publico. O
       Core fara o seu melhor para atuar como pacificadores e trazer as
       coisas de volta para a sanidade. Nos casos em que a disputa envolve
       uma alterac,ao na base de codigo e os participantes nao parecem estar
       chegando a um acordo amigavel, o core pode nomear um terceiro
       mutuamente aceitavel para resolver a disputa. Todas as partes
       envolvidas devem entao concordar em se comprometer com a decisao
       tomada por este terceiro.

    8. Respeite todos os congelamentos de codigo e leia atempadamente a lista
       de discussao committers e developers para saber quando um congelamento
       de codigo esta em vigor.

       Efetuar o commit de alterac,oes nao aprovadas durante um congelamento
       de codigo e um erro realmente grande e espera-se que os committers se
       mantenham atualizados sobre o que esta acontecendo antes de entrar
       depois de uma longa ausencia e fazer o commit de 10 megabytes de
       material acumulado. As pessoas que abusarem disso regularmente terao
       seus privilegios de commit suspensos ate que eles voltem do FreeBSD
       Happy Reeducation Camp que mantemos na Groenlandia.

    9. Em caso de duvida em qualquer procedimento, pergunte primeiro!

       Muitos erros sao cometidos porque alguem esta com pressa e apenas
       assume que sabe a forma certa para fazer alguma coisa. Se voce nao fez
       isso antes, e bem provavel que voce nao conhec,a realmente a maneira
       como fazemos as coisas e realmente precise perguntar primeiro ou voce
       vai se envergonhar completamente em publico. Nao ha vergonha em
       perguntar "como diabos eu fac,o isso?" Ja sabemos que voce e uma
       pessoa inteligente; caso contrario, voce nao seria um committer.

   10. Teste suas alterac,oes antes de fazer o commit.

       Isso pode parecer obvio, mas se realmente fosse tao obvio,
       provavelmente nao veriamos tantos casos de pessoas claramente nao
       fazendo isso. Se suas mudanc,as sao para o kernel, certifique-se de
       que voce ainda pode compilar o GENERIC e o LINT. Se as suas
       alterac,oes estiverem em outro lugar, certifique-se de que voce ainda
       pode fazer um "make world". Se as alterac,oes forem feitas em uma
       branch, certifique-se de que seu teste ocorra com uma maquina que
       esteja executando esse codigo. Se voce tiver uma alterac,ao que tambem
       possa quebrar outra arquitetura, verifique e teste em todas as
       arquiteturas suportadas. Por favor, consulte a Pagina Interna do
       FreeBSD para obter uma lista dos recursos disponiveis. A medida que
       outras arquiteturas sao adicionadas `a lista de plataformas suportadas
       do FreeBSD, os recursos de teste compartilhados apropriados serao
       disponibilizados.

   11. Nao commit em software contribuido sem a aprovac,ao explicita dos
       respectivos mantenedores.

       Software contribuido e qualquer codigo que esteja sob as arvores
       src/contrib, src/crypto, ou src/sys/contrib.

       As arvores mencionadas acima sao para software contribuido geralmente
       importado para um branch de fornecedor. Fazer o commit de algo la pode
       causar dores de cabec,a desnecessarias quando for importado novas
       versoes do software. Uma regra geral e considerar enviar os patches
       upstream diretamente para o fornecedor. Patches podem ser committados
       primeiramente no FreeBSD, desde que tenha a permissao do mantenedor.

       As razoes para modificar o software upstream variam entre querer
       controle estrito sobre uma dependencia fortemente acoplada `a falta de
       portabilidade na distribuic,ao do repositorio canonico do seu codigo.
       Independentemente do motivo, o esforc,o para minimizar a carga de
       manutenc,ao do fork e util para outros mantenedores. Evite realizar
       commits de alterac,oes triviais ou cosmeticas nos arquivos, pois isso
       dificulta cada merge: esses patches precisam ser verificados
       manualmente a cada importac,ao.

       Se uma parte especifica do software nao tiver um mantenedor, voce e
       incentivado a assumir a propriedade. Se voce nao tiver certeza sobre o
       mantenedor atual, envie um email para a lista de email de arquitetura
       e design do FreeBSD e pergunte.

  18.2. Politica sobre Varias Arquiteturas

   O FreeBSD adicionou ports para varias novas arquiteturas durante os ciclos
   de release recentes e realmente nao e mais um sistema operacional centrado
   em i386(TM). Em um esforc,o para tornar mais facil manter o FreeBSD
   portatil entre as plataformas que suportamos, o core desenvolveu este
   mandato:

     Nossa plataforma de referencia de 32 bits e a i386 e a nossa plataforma
     de referencia de 64 bits e amd64. O principal trabalho de design
     (incluindo as principais alterac,oes da API e da ABI) deve ser
     comprovado em pelo menos uma plataforma de 32 bits e pelo menos uma de
     64 bits, preferencialmente nas plataformas de referencia primaria, antes
     que o seu commit possa ser feito na arvore de fontes.

   As plataformas i386 e amd64 foram escolhidas por estarem mais prontamente
   disponiveis para os desenvolvedores e como representantes dos mais
   diversos designs de processador e de sistema - "big versus little endian",
   registrador de arquivos versus pilha de registro, diferentes
   implementac,oes de DMA e cache, tabelas de pagina de hardware versus
   gerenciamento de TLB de software, etc.

   Continuaremos a reavaliar essa politica, ja que o custo e a
   disponibilidade das plataformas de 64 bits mudam.

   Os desenvolvedores tambem devem estar cientes da nossa Politica de Tier
   para o suporte de longo prazo das arquiteturas de hardware. As regras aqui
   pretendem fornecer orientac,ao durante o processo de desenvolvimento e sao
   diferentes dos requisitos de recursos e arquiteturas listados nessa
   sec,ao. As regras de Tier para suporte de recursos em arquiteturas no
   momento da release sao mais rigorosas do que as regras para alterac,oes
   durante o processo de desenvolvimento.

  18.3. Outras Sugestoes

   Ao enviar alterac,oes na documentac,ao, use um verificador ortografico
   antes de efetuar o commit. Para todos os documentos XML, verifique se as
   diretivas de formatac,ao estao corretas executando o make lint e o
   textproc/igor.

   Para as paginas de manual, execute o sysutils/manck e o textproc/igor na
   pagina de manual para verificar se todas as referencias cruzadas e
   referencias de arquivo estao corretas e se a pagina man possui todos os
   MLINKs apropriados instalados.

   Nao misture correc,oes de estilo com novas funcionalidades. Uma correc,ao
   de estilo e qualquer alterac,ao que nao modifique a funcionalidade do
   codigo. Misturar as alterac,oes ofusca a mudanc,a de funcionalidade ao
   solicitar a comparac,ao das diferenc,as entre as revisoes, o que pode
   ocultar quaisquer novos bugs. Nao inclua alterac,oes de espac,o em branco
   com alterac,oes de conteudo nos commits para doc/. A desordem extra nos
   diffs torna o trabalho dos tradutores muito mais dificil. Em vez disso,
   fac,a qualquer alterac,ao de estilo ou espac,o em branco em commits
   separados e que sejam claramente rotuladas como tal na mensagem de commit.

  18.4. Recursos Obsoletos (Deprecated)

   Quando for necessario remover uma funcionalidade de software do sistema
   basico, siga estas diretrizes sempre que possivel:

    1. Uma menc,ao e feita na pagina de manual e, possivelmente, nas notas de
       versao que a opc,ao, o utilitario ou a interface estao obsoletos. O
       uso do recurso obsoleto gera um aviso.

    2. A opc,ao, utilitario ou interface e preservada ate a proxima release
       principal (ponto zero).

    3. A opc,ao, o utilitario ou a interface sao removidos e nao sao mais
       documentados. Agora esta obsoleto. Tambem e geralmente uma boa ideia
       anotar sua remoc,ao nas notas de release.

  18.5. Privacidade e Confidencialidade

    1. A maioria dos negocios do FreeBSD e feita em publico.

       O FreeBSD e um projeto aberto. O que significa que nao so alguem pode
       usar o codigo-fonte, mas que a maior parte do processo de
       desenvolvimento esta aberto ao escrutinio publico.

    2. Certos assuntos delicados devem permanecer privados ou mantidos sob
       embargo.

       Infelizmente, nao pode haver transparencia completa. Como
       desenvolvedor do FreeBSD, voce tera um certo grau de acesso
       privilegiado `a informac,ao. Consequentemente, espera-se que voce
       respeite certos requisitos de confidencialidade. As vezes, a
       necessidade de confidencialidade vem de colaboradores externos ou tem
       um limite de tempo especifico. Principalmente, porem, e uma questao de
       nao liberar comunicac,oes privadas.

    3. O oficial de seguranc,a tem controle exclusivo sobre a liberac,ao de
       alertas de seguranc,a.

       Onde existem problemas de seguranc,a que afetam muitos sistemas
       operacionais diferentes, o FreeBSD frequentemente depende do acesso
       antecipado para poder preparar alertas para liberac,ao coordenada. A
       menos que se possa confiar nos desenvolvedores do FreeBSD para manter
       a seguranc,a, esse acesso antecipado nao sera disponibilizado. O
       Oficial de Seguranc,a e responsavel por controlar o acesso
       pre-lanc,amento `as informac,oes sobre vulnerabilidades, e por definir
       o momento de liberac,ao de todos os alertas. Ele pode solicitar ajuda
       sob condic,ao de confidencialidade de qualquer desenvolvedor com
       conhecimento relevante para preparar as correc,oes de seguranc,a.

    4. As comunicac,oes com o Core sao mantidas confidenciais pelo tempo que
       for necessario.

       As comunicac,oes para o core serao inicialmente tratadas como
       confidenciais. Eventualmente, no entanto, a maioria dos negocios do
       Core serao resumidos nos relatorios mensais ou trimestrais do core.
       Cuidado sera tomado para evitar a divulgac,ao de detalhes sensiveis.
       Os registros de alguns assuntos particularmente sensiveis podem nao
       ser relatados e serao mantidos apenas nos arquivos privados do Core.

    5. Acordos de nao divulgac,ao (NDA) podem ser necessarios para o acesso a
       determinados dados comercialmente sensiveis.

       O acesso a determinados dados comercialmente sensiveis so pode estar
       disponivel sob um Contrato de Nao Divulgac,ao. A equipe juridica da
       Fundac,ao FreeBSD deve ser consultado antes de qualquer acordo
       vinculativo ser firmado.

    6. Comunicac,oes privadas nao devem ser tornadas publicas sem permissao.

       Alem dos requisitos especificos acima, ha uma expectativa geral de nao
       publicar comunicac,oes privadas entre desenvolvedores sem o
       consentimento de todas as partes envolvidas. Pec,a permissao antes de
       encaminhar uma mensagem para uma lista de discussao publica, ou
       publica-la em um forum ou site que possa ser acessado por outros que
       nao os correspondentes originais.

    7. As comunicac,oes em canais de acesso restrito ou somente do projeto
       devem ser mantidas em sigilo.

       Semelhantemente `as comunicac,oes pessoais, certos canais de
       comunicac,ao interna, incluindo as listas de discussao dos Committers
       do FreeBSD e os canais de IRC de acesso restrito, sao considerados
       comunicac,oes privadas. A permissao e necessaria para publicar
       material dessas fontes.

    8. O Core pode aprovar a publicac,ao.

       Quando for impraticavel obter permissao devido ao numero de
       correspondentes ou quando a permissao para publicar for
       injustificadamente retida, a Core podera aprovar a liberac,ao de tais
       assuntos privados que merec,am uma publicac,ao mais geral.

19. Suporte para Varias Arquiteturas

   O FreeBSD e um sistema operacional altamente portatil destinado a
   funcionar em muitos tipos diferentes de arquiteturas de hardware. Manter
   uma separac,ao clara entre o codigo dependente de maquina (MD) e
   independente de maquina (MI), alem de minimizar o codigo MD, e uma parte
   importante da nossa estrategia de permanecer agil em relac,ao `as
   tendencias atuais de hardware. Cada nova arquitetura de hardware suportada
   pelo FreeBSD aumenta substancialmente o custo de manutenc,ao de codigo, de
   suporte do toolchain e de engenharia de release. Tambem aumenta
   drasticamente o custo do teste efetivo das alterac,oes no kernel. Como
   tal, ha uma forte motivac,ao para diferenciar as classes de suporte para
   as varias arquiteturas, permanecendo forte em algumas arquiteturas chaves
   que sao vistas como o "publico-alvo" do FreeBSD.

  19.1. Declarac,ao de Intenc,ao Geral

   O projeto FreeBSD tem como objetivo a "qualidade comercial de produc,ao
   off-the-shelf (COTS) para workstations, servidores e sistemas embarcados
   de ponta". Mantendo o foco em um conjunto restrito de arquiteturas de
   interesse nesses ambientes, o Projeto FreeBSD e capaz de manter altos
   niveis de qualidade, estabilidade e desempenho, bem como de minimizar a
   carga de varias equipes de suporte no projeto, como a equipe de ports, a
   equipe de documentac,ao, o oficial de seguranc,a e as equipes de
   engenharia de release. A diversidade no suporte de hardware amplia as
   opc,oes para os consumidores do FreeBSD oferecendo novos recursos e
   oportunidades de uso, mas esses beneficios devem sempre ser cuidadosamente
   considerados em termos do custo de manutenc,ao no mundo real associado ao
   suporte adicional `a plataforma.

   O projeto FreeBSD diferencia plataforma alvos em quatro camadas. Cada
   camada inclui uma lista de garantias que os consumidores podem confiar ,
   bem como as obrigac,oes por Projeto e desenvolvedores para cumprir essas
   garantias. Esta lista define o minimo de garantia por cada camada. O
   Projeto e desenvolvedores podem prover leveis de suporte adicionais alem
   da garantia minima dada a uma camada, mas tais suportes adicionais nao tem
   garantias. Cada plataforma alvo e designada para uma camada especifica
   para cada ramificac,ao stable. Como resultado, a plataforma alvo poderia
   ser designada para diferentes camadas em ramificac,oes stable
   concorrentes.

  19.2. Plataformas Alvo

   O suporte para uma plataforma de hardware consiste em dois componentes:
   suporte ao kernel e interfaces binarias de aplicativos (ABIs) do usuario.
   O suporte do kernel `a plataforma inclui os itens necessarios para
   executar um kernel do FreeBSD em uma plataforma de hardware, como
   gerenciamento de memoria virtual dependente de maquina e drivers de
   dispositivo. Uma ABI especifica uma interface para os processos do usuario
   interagirem com o kernel do FreeBSD e as bibliotecas do sistema base. Uma
   ABI inclui interfaces de chamada do sistema, o layout e a semantica de
   estruturas de dados publicos e o layout e a semantica de argumentos
   transmitidos `as sub-rotinas. Alguns componentes de uma ABI podem ser
   definidos por especificac,oes tais como o layout dos objetos de excec,ao C
   ++ ou as convenc,oes de chamada para func,oes C.

   Um kernel do FreeBSD tambem usa uma ABI (`as vezes chamada de Interface
   Binaria do Kernel (KBI)) que inclui a semantica e layouts de estruturas de
   dados publicos e o layout e semantica de argumentos para func,oes publicas
   dentro do proprio kernel.

   Um kernel do FreeBSD pode suportar multiplas ABIs de usuario. Por exemplo,
   o kernel amd64 do FreeBSD suporta as ABIs de usuario do FreeBSD amd64 e
   i386, bem como as ABIs de usuario do Linux x86_64 e i386. Um kernel do
   FreeBSD deve suportar uma ABI "nativa" como a ABI padrao. A "ABI" nativa
   geralmente compartilha certas propriedades com a ABI do kernel, como a
   convenc,ao de chamada C, tamanhos dos tipos basicos, etc.

   Os Tiers sao definidos tanto para os kernels quanto para as ABIs do
   usuario. Normalmente, o kernel de uma plataforma e as ABIs do FreeBSD sao
   atribuidas `a mesma Tier.

  19.3. Tier 1: Arquiteturas Completamente Suportadas

   As plataformas Tier 1 sao as plataformas mais maduras do FreeBSD. Elas sao
   suportadas pelas equipes de seguranc,a, engenharia de release e
   gerenciamento de ports. Espera-se que as arquiteturas Tier 1 estejam com
   Qualidade de Produc,ao em relac,ao a todos os aspectos do sistema
   operacional FreeBSD, incluindo ambientes de instalac,ao e desenvolvimento.

   O Projeto FreeBSD fornece as seguintes garantias aos consumidores das
   plataformas de Tier 1:

     * Imagens oficiais de Release do FreeBSD serao fornecidas pela equipe de
       engenharia de release.

     * Serao fornecidas atualizac,oes binarias e patches no formato de codigo
       fonte para os Avisos de Seguranc,a e Avisos de Erro das versoes
       suportadas.

     * Serao fornecidos patches de codigo fonte para os avisos de seguranc,a
       das branches suportadas.

     * Atualizac,oes binarias e patches de codigo fonte geralmente sao
       fornecidos para os avisos de seguranc,a multiplataforma no momento do
       anuncio.

     * As alterac,oes nas ABIs do usuario geralmente incluirao bibliotecas de
       compatibilidade para garantir a operac,ao correta dos binarios
       compilados a partir de qualquer branch estavel de uma plataforma Tier
       1. Estas bibliotecas podem nao ser ativadas na instalac,ao padrao. Se
       as bibliotecas de compatibilidade nao forem fornecidas para uma
       alterac,ao de ABI, a falta da mesma estara claramente documentada nas
       notas de versao.

     * Alterac,oes em certas partes da ABI do kernel incluirao bibliotecas de
       compatibilidade para garantir a operac,ao correta dos modulos do
       kernel compilados contra a versao suportada mais antiga da branch.
       Observe que nem todas as partes da ABI do kernel estao protegidas.

     * Pacotes binarios oficiais para softwares de terceiros serao fornecidos
       pela equipe de ports. Para arquiteturas embarcadas, esses pacotes
       podem ser compilados de forma cruzada a partir de uma arquitetura
       diferente.

     * Os ports mais relevantes devem ou compilar ou ter filtros apropriados
       para prevenir a compilac,ao dos inadequados.

     * Novos recursos que nao sao inerentemente especificos da plataforma
       serao totalmente funcionais em todas as arquiteturas de Tier 1.

     * Os recursos e bibliotecas de compatibilidade usados pelos binarios
       compilados a partir das branchs estaveis mais antigas podem ser
       removidos nas versoes principais mais recentes. Essas remoc,oes serao
       claramente documentadas nas notas de versao.

     * As plataformas Tier 1 devem ser totalmente documentadas. As operac,oes
       basicas serao documentadas no Handbook do FreeBSD.

     * As plataformas de Tier 1 serao incluidas na arvore de codigo fonte.

     * As plataformas de Tier 1 devem ser auto-hospedadas ou por meio de um
       toolchain disponivel na arvore de codigo fonte ou por meio de um
       toolchain externo. Se um toolchain externo for necessario, serao
       fornecidos pacotes binarios oficiais para o toolchain externo.

   Para manter a maturidade das plataformas de Tier 1, o Projeto FreeBSD
   mantera os seguintes recursos para apoiar o desenvolvimento:

     * Suporte `a automac,ao do processo de compilac,ao e de testes no
       cluster FreeBSD.org ou em algum outro local facilmente disponivel para
       todos os desenvolvedores. Plataformas embarcadas podem substituir um
       emulador disponivel no cluster FreeBSD.org por hardware real.

     * A inclusao nos targets do make universe e make tinderbox.

     * Hardware dedicado em um dos clusters do FreeBSD para compilac,ao de
       pacotes (nativamente ou via qemu-user).

   Coletivamente, os desenvolvedores devem fornecer o seguinte para manter o
   status de Tier 1 de uma plataforma:

     * Alterac,oes na arvore de codigo fonte nao devem quebrar
       conscientemente a compilac,ao de uma plataforma de Tier 1.

     * As arquiteturas de Tier 1 devem ter um ecossistema maduro e saudavel
       de usuarios e desenvolvedores ativos.

     * Os desenvolvedores devem ser capazes de compilar pacotes em sistemas
       Tier 1 nao-embarcados comumente disponiveis. Isso pode significar
       compilac,oes nativas se sistemas nao-embarcados estiverem normalmente
       disponiveis para a plataforma em questao, ou significar compilac,oes
       cruzadas hospedadas em alguma outra arquitetura de Tier 1.

     * As alterac,oes nao podem quebrar a ABI do usuario. Se for necessaria
       uma alterac,ao da ABI, a compatibilidade da ABI com os binarios
       existentes deve ser provida atraves do versionamento de simbolos ou do
       versionamento de bibliotecas compartilhadas.

     * Alterac,oes mescladas em branchs estaveis nao podem quebrar as partes
       protegidas da ABI do kernel. Se for necessaria uma alterac,ao da ABI
       do kernel, ela devera ser modificada para preservar a funcionalidade
       dos modulos existentes do kernel.

  19.4. Tier 2: Arquiteturas de Desenvolvimento e Nicho

   As plataformas de Tier 2 sao funcionais, mas sao plataformas FreeBSD menos
   maduras. Elas nao sao suportadas pelas equipes de seguranc,a, engenharia
   de release e gerenciamento de ports.

   As plataformas Tier 2 podem ser candidatas `a plataforma Tier 1 que ainda
   estao em desenvolvimento ativo. As arquiteturas que atingem o fim da vida
   util tambem podem ser movidas do status de Tier 1 para o status de Tier 2
   `a medida que a disponibilidade de recursos para continuar a manter o
   sistema em um estado de Qualidade de Produc,ao diminui. Arquiteturas de
   nicho bem suportadas tambem podem ser de Tier 2.

   O Projeto FreeBSD fornece as seguintes garantias aos consumidores das
   plataformas de Tier 2:

     * A infraestrutura de ports deve incluir suporte basico para as
       arquiteturas de Tier 2 suficiente para suportar a compilac,ao de ports
       e pacotes. Isso inclui suporte para pacotes basicos, tais como o
       ports-mgmt/pkg, mas nao ha garantia de que ports arbitrarios serao
       compilaveis ou funcionais.

     * Novos recursos que nao sao inerentemente especificos da plataforma
       devem ser viaveis em todas as arquiteturas de Tier 2 se nao
       implementados.

     * As plataformas de Tier 2 serao incluidas na arvore de codigo fonte.

     * As plataformas de Tier 2 devem ser auto-hospedadas ou por meio de um
       toolchain disponivel na arvore de codigo fonte ou por meio de um
       toolchain externo. Se um toolchain externo for necessario, serao
       fornecidos pacotes binarios oficiais para o toolchain externo.

     * As plataformas de Tier 2 devem fornecer kernels e espac,o de usuario
       funcionais, mesmo que uma release oficial nao seja provida.

   Para manter a maturidade das plataformas de Tier 2, o Projeto FreeBSD
   mantera os seguintes recursos para apoiar o desenvolvimento:

     * A inclusao nos targets do make universe e make tinderbox.

   Coletivamente, os desenvolvedores devem fornecer o seguinte para manter o
   status de Tier 2 de uma plataforma:

     * Alterac,oes na arvore de codigo fonte nao devem quebrar
       conscientemente a compilac,ao de uma plataforma de Tier 2.

     * As arquiteturas de Tier 2 devem ter um ecossistema ativo de usuarios e
       desenvolvedores.

     * Embora sejam permitidas alterac,oes que quebrem a ABI do usuario, a
       ABI nao deve ser quebrada gratuitamente. Alterac,oes significativas da
       ABI do usuario devem ser restritas `as versoes principais.

     * Novos recursos que ainda nao foram implementados nas arquiteturas de
       Tier 2 devem fornecer um meio de desativa-los nessas arquiteturas.

  19.5. Tier 3: Arquiteturas Experimentais

   As plataformas de Tier 3 tem pelo menos suporte parcial ao FreeBSD. Elas
   nao sao suportadas pelas equipes de seguranc,a, engenharia de release e de
   gerenciamento de ports.

   As plataformas de Tier 3 sao arquiteturas nos estagios iniciais de
   desenvolvimento, para plataformas de hardware nao convencionais, ou que
   sao considerados sistemas legados improvaveis de serem amplamente
   utilizados no futuro. O suporte inicial para plataformas de Tier 3 pode
   existir em um repositorio separado em vez do repositorio de codigo fonte
   principal.

   O Projeto FreeBSD nao oferece garantias aos consumidores das plataformas
   de Tier 3 e nao esta comprometido em manter recursos para apoiar o seu
   desenvolvimento. As plataformas de Tier 3 nem sempre podem ser
   compilaveis, nem quaisquer ABIs do kernel ou de usuario sao consideradas
   estaveis.

  19.6. Tier 4: Arquiteturas Nao Suportadas

   As plataformas Tier 4 nao sao suportadas de nenhuma forma pelo projeto.

   Todos os sistemas nao classificados de outra forma sao sistemas de Tier 4.
   Quando uma plataforma faz a transic,ao para o Tier 4, todo o suporte para
   a plataforma e removido das arvores de codigo fonte e de ports. Observe
   que o suporte aos ports deve ser mantido enquanto a plataforma for
   suportada em uma branch suportada pelo ports.

  19.7. Politica para Alterac,ao do Tier de uma Arquitetura

   Os sistemas so podem ser movidos de um Tier para outro por meio da
   aprovac,ao do Core Team do FreeBSD, que deve tomar essa decisao em
   colaborac,ao com as equipes de seguranc,a, engenharia de release e
   gerenciamento dos ports. Para que uma plataforma seja promovida para um
   Tier superior, todas as garantias de suporte ausentes devem ser atendidas
   antes que a promoc,ao seja concluida.

20. FAQ especifico dos Ports

   20.1. Adicionando um Novo Port

                20.1.1. Como eu adiciono um novo port?

                20.1.2. Existe qualquer outra coisa que preciso saber quando
                adiciono um novo port?

   20.2. Removendo um port existente

                20.2.1. Como fac,o para remover um port existente?

   20.3. Adicionando Novamente um Port que foi Removido

                20.3.1. Como fac,o para adicionar novamente um port que foi
                removido?

   20.4. Copias de Repositorio

                20.4.1. Quando precisamos de uma copia do repositorio?

                20.4.2. O que eu preciso fazer?

   20.5. Freeze do Ports

                20.5.1. O que e um "ports freeze"?

   20.6. Branches Trimestrais

                20.6.1. Qual e o procedimento para solicitar autorizac,ao
                para aplicar um commit `a branch trimestral?

                20.6.2. Existe alguma alterac,ao para a qual possa ser feito
                o commit sem aprovac,ao?

                20.6.3. Qual e o procedimento para aplicar os commits `a
                branch trimestral?

   20.7. Criando uma Nova Categoria

                20.7.1. Qual e o procedimento para criar uma nova categoria?

                20.7.2. O que preciso fazer para implementar uma nova
                categoria fisica?

                20.7.3. O que preciso fazer para implementar uma nova
                categoria virtual?

   20.8. Perguntas Diversas

                20.8.1. Existe alguma alterac,ao para a qual possa ser feito
                o commit sem a aprovac,ao do mantenedor?

                20.8.2. Como sei se meu port esta sendo compilado
                corretamente ou nao?

                20.8.3. Eu adicionei um novo port. Preciso adiciona-lo ao
                INDEX?

                20.8.4. Existem outros arquivos que nao tenho permissao para
                tocar?

                20.8.5. Qual e o procedimento adequado para atualizar o
                checksum de um distfile de um port quando o arquivo e
                alterado sem uma alterac,ao de versao?

                20.8.6. Como uma build de teste experimental da arvore de
                ports (exp-run) pode ser solicitada?

    20.1. Adicionando um Novo Port
20.1.1. Como eu adiciono um novo port?
        
20.1.2. Existe qualquer outra coisa que preciso saber quando adiciono um novo port?
20.1.1. Como eu adiciono um novo port?                                                                        
        Primeiro, por favor leia a sec,ao sobre copias do repositorio.                                        
                                                                                                              
        A maneira mais facil de adicionar um novo port e o script addport localizado no diretorio             
        ports/Tools/scripts. Ele adiciona um port do diretorio especificado, determinando a categoria         
        automaticamente a partir do Makefile do port. Tambem adiciona uma entrada `a categoria do Makefile do 
        port. Foi escrito por Michael Haro <mharo@FreeBSD.org>, Will Andrews <will@FreeBSD.org> e Renato      
        Botelho <garga@FreeBSD.org>. Ao enviar perguntas sobre este script para a lista de discussao dos      
        ports do FreeBSD, por favor tambem copie Chris Rees <crees@FreeBSD.org>, o mantenedor atual.          
20.1.2. Existe qualquer outra coisa que preciso saber quando adiciono um novo port?                           
        Verifique o port, de preferencia para garantir que ele seja compilado e empacotado corretamente. Essa 
        e a sequ:encia recomendada:                                                                           
                                                                                                              
        # make install                                                                                        
        # make package                                                                                        
        # make deinstall                                                                                      
        # pkg add package you built above                                                                     
        # make deinstall                                                                                      
        # make reinstall                                                                                      
        # make package                                                                                        
                                                                                                              
        O Manual de Porters contem instruc,oes mais detalhadas.                                               
                                                                                                              
        Use o portlint(1) para verificar a sintaxe do port. Voce nao precisa necessariamente eliminar todos   
        os avisos, mas certifique-se de ter corrigido os mais simples.                                        
                                                                                                              
        Se o port veio de um remetente que nao contribuiu para o projeto antes, adicione o nome dessa pessoa  
        a sec,ao Colaboradores Adicionais da Lista de Colaboradores do FreeBSD.                               
                                                                                                              
        Feche o PR se o port entrou como um PR. Para fechar um PR, mude o estado para Issue Resolved e a      
        resoluc,ao como Fixed.                                                                                
    20.2. Removendo um port existente
20.2.1. Como fac,o para remover um port existente?
20.2.1. Como fac,o para remover um port existente?                                                            
        Primeiro, por favor leia a sec,ao sobre copias do repositorio. Antes de remover o port, voce deve     
        verificar se nao ha outros ports dependendo dele.                                                     
                                                                                                              
          * Certifique-se de que nao haja dependencia do port na colec,ao de ports:                           
                                                                                                              
               * O PKGNAME do port aparece exatamente em uma linha em um arquivo INDEX recente.               
                                                                                                              
               * Nenhum outro port contem qualquer referencia ao diretorio do port ou ao seu PKGNAME em seus  
                 Makefiles                                                                                    
                                                                                                              
          Dica:                                                                                               
                                                                                                              
                 Ao usar o Git, considere o uso do git grep, ele e muito mais rapido que o grep -r.           
                                                                                                              
          * Em seguida, remova o port:                                                                        
                                                                                                              
              1. Remova os arquivos e o diretorio do port com svn remove.                                     
                                                                                                              
              2. Remova a entrada SUBDIR do port listado no diretorio pai do Makefile.                        
                                                                                                              
              3. Adicione uma entrada em ports/MOVED.                                                         
                                                                                                              
              4. Procure entradas em ports/security/vuxml/vuln.xml e ajuste-as de acordo. Em particular,      
                 verifique os pacotes anteriores com o novo nome e qual versao poderia incluir o novo port.   
                                                                                                              
              5. Remova o port de ports/LEGAL se ele estiver la.                                              
                                                                                                              
        Alternativamente, voce pode usar o script rmport, a partir de ports/Tools/scripts. Este roteiro foi   
        escrito por Vasil Dimov <vd@FreeBSD.org>. Ao enviar perguntas sobre este script para a lista de       
        discussao dos ports do FreeBSD, por favor tambem copie Chris Rees <crees@FreeBSD.org>, o mantenedor   
        atual.                                                                                                
    20.3. Adicionando Novamente um Port que foi Removido
20.3.1. Como fac,o para adicionar novamente um port que foi removido?
20.3.1. Como fac,o para adicionar novamente um port que foi removido?                                         
        Isto e essencialmente o contrario de deletar um port.                                                 
                                                                                                              
          Importante:                                                                                         
                                                                                                              
        Nao use svn add para adicionar o port. Siga esses passos. Se eles nao estiverem claros, ou nao        
        estiverem funcionando, pec,a ajuda, nao execute apenas o svn add para o port.                         
                                                                                                              
         1. Descubra quando o port foi removido. Use esta lista, ou procure o port em freshports e copie a    
            ultima revisao viva do porto:                                                                     
                                                                                                              
         % cd /usr/ports/category                                                                             
         % svn cp 'svn+ssh://repo.freebsd.org/ports/head/category/portname/@XXXXXX' portname                  
                                                                                                              
            Escolha a revisao que e justamente antes da remoc,ao. Por exemplo, se a revisao em que foi        
            removida for 269874, use 269873.                                                                  
                                                                                                              
            Tambem e possivel especificar uma data. Nesse caso, escolha uma data antes da remoc,ao, mas       
            depois do ultimo commit para o port.                                                              
                                                                                                              
         % cd /usr/ports/category                                                                             
         % svn cp 'svn+ssh://repo.freebsd.org/ports/head/category/portname/@{YYYY-MM-DD}' portname            
                                                                                                              
         2. Fac,a as alterac,oes necessarias para que o port funcione novamente. Se ele foi excluido porque   
            os distfiles nao estao mais disponiveis, seja voluntario para hospedar os distfiles ou encontre   
            outra pessoa para faze-lo.                                                                        
                                                                                                              
         3. Se alguns arquivos foram adicionados, ou foram removidos durante o processo de ressurreic,ao, use 
            o svn add ou svn remove para certificar-se de que todos os arquivos no port serao aplicados no    
            commit.                                                                                           
                                                                                                              
         4. Restaure o SUBDIR do port listado no diretorio pai do Makefile, mantendo as entradas ordenadas.   
                                                                                                              
         5. Exclua a entrada do port de ports/MOVED.                                                          
                                                                                                              
         6. Se o port tiver uma entrada em ports/LEGAL, a restaure.                                           
                                                                                                              
         7. Execute o svn commit para estas mudanc,as, de preferencia no primeiro passo.                      
                                                                                                              
          Dica:                                                                                               
                                                                                                              
        O script addport mencionado em P & R 20.1, "Adicionando um Novo Port" agora detecta quando o port a   
        ser adicionado existia anteriormente e tenta manipular todos automaticamente, exceto o ports/LEGAL.   
    20.4. Copias de Repositorio
20.4.1. Quando precisamos de uma copia do repositorio?
        
20.4.2. O que eu preciso fazer?
20.4.1. Quando precisamos de uma copia do repositorio?                                                        
        Quando voce deseja adicionar um port relacionado a qualquer port que ja esteja na arvore em um        
        diretorio separado, e necessario fazer uma copia do repositorio. Aqui relacionado significa que e uma 
        versao diferente ou uma versao ligeiramente modificada. Exemplos sao print/ghostscript* (versoes      
        diferentes) e x11-m/windowmaker* (versao somente inglesa e internacionalizada).                       
                                                                                                              
        Outro exemplo e quando um port e movido de um subdiretorio para outro, ou quando o nome de um         
        diretorio deve ser alterado porque os autores renomearam seu software mesmo sendo um descendente de   
        um port que ja esta em uma arvore.                                                                    
20.4.2. O que eu preciso fazer?                                                                               
        Com o Subversion, uma copia do repo pode ser feita por qualquer committer:                            
                                                                                                              
          * Fazendo uma copia do repo:                                                                        
                                                                                                              
              1. Verifique se o diretorio de destino nao existe.                                              
                                                                                                              
              2. Use o svn up para garantir que os arquivos originais, diretorios e informac,oes de checkout  
                 sejam atuais.                                                                                
                                                                                                              
              3. Use o svn move ou o svn copy para fazer a copia do repo.                                     
                                                                                                              
              4. Atualize o port copiado para a nova versao. Lembre-se de incluir ou alterar o PKGNAMEPREFIX  
                 ou PKGNAMESUFFIX para que nao haja ports duplicados com o mesmo nome. Em alguns casos raros, 
                 pode ser necessario alterar o PORTNAME em vez de adicionar o PKGNAMEPREFIX ou o              
                 PKGNAMESUFFIX, mas isso so e feito quando e realmente necessario - por exemplo, usando um    
                 port existente como base para um programa muito semelhante com um nome diferente ou          
                 atualizando um port para uma nova versao upstream que realmente altera o nome da             
                 distribuic,ao, como a transic,ao de textproc/libxml para textproc/libxml2. Na maioria dos    
                 casos, adicionar ou alterar o PKGNAMEPREFIX ou o PKGNAMESUFFIX e suficiente.                 
                                                                                                              
              5. Adicione o novo subdiretorio ao SUBDIR listado no diretorio pai do Makefile. Voce pode       
                 executar make checksubdirs no diretorio pai para verificar isso.                             
                                                                                                              
              6. Se o port mudou de categoria, modifique a linha CATEGORIES do Makefile do port adequadamente 
                                                                                                              
              7. Adicione uma entrada em ports/MOVED, se voce remover o port original.                        
                                                                                                              
              8. Fac,a o commit de todas as alterac,oes de uma unica vez.                                     
                                                                                                              
          * Ao remover um port:                                                                               
                                                                                                              
              1. Execute uma verificac,ao completa da colec,ao de ports para quaisquer dependencias no        
                 local/nome do port antigo e os atualize. A execuc,ao do grep no INDEX nao e suficiente       
                 porque alguns ports possuem dependencias ativadas pelas opc,oes em tempo de compilac,ao. Um  
                 grep -r completo da colec,ao de ports e recomendado.                                         
                                                                                                              
              2. Remova o port antigo e a entrada SUBDIR antiga.                                              
                                                                                                              
              3. Adicione uma entrada em ports/MOVED.                                                         
                                                                                                              
          * Apos o repo ser movido (operac,ao para "renomear" na qual um port e copiado e o local antigo e    
            removido):                                                                                        
                                                                                                              
               * Siga as mesmas etapas descritas nas duas entradas anteriores para ativar o novo local do     
                 port e remover o antigo.                                                                     
    20.5. Freeze do Ports
20.5.1. O que e um "ports freeze"?
20.5.1. O que e um "ports freeze"?                                                                            
        Um "ports freeze" e um estado restrito em que a arvore de ports e colocada antes de uma release. Ele  
        e usado para garantir uma qualidade superior para os pacotes enviados com um release. Geralmente dura 
        algumas semanas. Durante esse tempo, problemas de build foram corrigidos e os pacotes de release      
        foram criados. Esta pratica nao e mais usada, ja que os pacotes para os releases sao compilados a     
        partir da branch trimestral stable.                                                                   
                                                                                                              
        Para obter mais informac,oes sobre como aplicar commits na branch trimestral, consulte P: 20.6.1.     
    20.6. Branches Trimestrais
20.6.1. Qual e o procedimento para solicitar autorizac,ao para aplicar um commit `a branch trimestral?
        
20.6.2. Existe alguma alterac,ao para a qual possa ser feito o commit sem aprovac,ao?
        
20.6.3. Qual e o procedimento para aplicar os commits `a branch trimestral?
20.6.1. Qual e o procedimento para solicitar autorizac,ao para aplicar um commit `a branch trimestral?        
        Ao fazer o commit, inclua o nome da branch na linha MFH:, por exemplo:                                
                                                                                                              
        MFH:    2014Q1                                                                                        
                                                                                                              
        Ele notificara automaticamente a Equipe de Seguranc,a do Ports <ports-secteam@FreeBSD.org> e a Equipe 
        de Gerenciamento de Ports <portmgr@FreeBSD.org>. Eles entao decidirao se o commit pode ser aplicado e 
        responder com o procedimento.                                                                         
                                                                                                              
        Se o commit ja foi feito, envie um email para a Equipe de Seguranc,a do Ports                         
        <ports-secteam@FreeBSD.org> e a Equipe de Gerenciamento de Ports <portmgr@FreeBSD.org> com o numero   
        de revisao e uma pequena descric,ao de por que o commit precisa ser aplicado.                         
                                                                                                              
          Dica:                                                                                               
                                                                                                              
        Se o MFH esta coberto por uma aprovac,ao geral, explique o porque com algumas palavras na linha MFH,  
        para que a equipe de revisao possa ignorar esse commit e economizar tempo. Por exemplo:               
                                                                                                              
        MFH:  2014Q1 (runtime fix)                                                                            
        MFH:  2014Q1 (browser blanket)                                                                        
                                                                                                              
        A lista de aprovac,oes gerais esta disponivel em P: 20.6.2.                                           
20.6.2. Existe alguma alterac,ao para a qual possa ser feito o commit sem aprovac,ao?                         
        As seguintes aprovac,oes implicitas para merge nas branches trimestrais estao em vigor:               
                                                                                                              
          Nota:                                                                                               
                                                                                                              
        Essa aprovac,ao geral tambem se aplica aos commits diretos para ports que foram removidos do head.    
                                                                                                              
          Importante:                                                                                         
                                                                                                              
        Estas correc,oes devem ser testadas na branch trimestral.                                             
                                                                                                              
          * Correc,oes que nao resultam em uma alterac,ao no conteudo do pacote resultante. Por exemplo:      
                                                                                                              
               * pkg-descr: WWW: URL updates (existing 404, moved or incorrect)                               
                                                                                                              
          * Correc,oes de build, tempo de execuc,ao ou empacotamento, se a versao da branch trimestral        
            estiver atualmente quebrada.                                                                      
                                                                                                              
          * Dependencias ausentes (detectadas, vinculadas, mas nao registradas, por meio de *_DEPENDS).       
                                                                                                              
          * Correc,oes de shebangs, remoc,ao de bibliotecas e binarios instalados e correc,oes de plst.       
                                                                                                              
          * Backport de seguranc,a e correc,oes de confiabilidade que resultam apenas em um incremento no     
            PORTREVISION e nenhuma alterac,ao nos recursos habilitados. Por exemplo, adic,ao de um patch que  
            corrige um estouro de buffer.                                                                     
                                                                                                              
          * Alterac,oes de versoes secundarias que nao fazem nada alem de corrigir problemas de seguranc,a ou 
            relacionados a falhas.                                                                            
                                                                                                              
          * Adic,ao/Conserto de CONFLICTS.                                                                    
                                                                                                              
          * Navegadores Web, plug-ins do navegador e suas dependencias necessarias.                           
                                                                                                              
          Importante:                                                                                         
                                                                                                              
        Commits que nao sao cobertos por essas aprovac,oes implicitas sempre exigem aprovac,ao explicita da   
        Equipe de Seguranc,a do Ports <ports-secteam@FreeBSD.org> ou da Equipe de Gerenciamento do Ports      
        <portmgr@FreeBSD.org>.                                                                                
20.6.3. Qual e o procedimento para aplicar os commits `a branch trimestral?                                   
        Um script e fornecido para automatizar a mesclagem de um commit especifico: ports/Tools/scripts/mfh.  
        E usado da seguinte forma:                                                                            
                                                                                                              
        % /usr/ports/Tools/scripts/mfh 380362                                                                 
         U   2015Q1                                                                                           
        Checked out revision 380443.                                                                          
        A    2015Q1/security                                                                                  
        Updating '2015Q1/security/rubygem-sshkit':                                                            
        A    2015Q1/security/rubygem-sshkit                                                                   
        A    2015Q1/security/rubygem-sshkit/Makefile                                                          
        A    2015Q1/security/rubygem-sshkit/distinfo                                                          
        A    2015Q1/security/rubygem-sshkit/pkg-descr                                                         
        Updated to revision 380443.                                                                           
        --- Merging r380362 into '2015Q1':                                                                    
        U    2015Q1/security/rubygem-sshkit/Makefile                                                          
        U    2015Q1/security/rubygem-sshkit/distinfo                                                          
        --- Recording mergeinfo for merge of r380362 into '2015Q1':                                           
         U   2015Q1                                                                                           
        --- Recording mergeinfo for merge of r380362 into '2015Q1/security':                                  
         G   2015Q1/security                                                                                  
        --- Eliding mergeinfo from '2015Q1/security':                                                         
         U   2015Q1/security                                                                                  
        --- Recording mergeinfo for merge of r380362 into '2015Q1/security/rubygem-sshkit':                   
         G   2015Q1/security/rubygem-sshkit                                                                   
        --- Eliding mergeinfo from '2015Q1/security/rubygem-sshkit':                                          
         U   2015Q1/security/rubygem-sshkit                                                                   
         M      2015Q1                                                                                        
        M       2015Q1/security/rubygem-sshkit/Makefile                                                       
        M       2015Q1/security/rubygem-sshkit/distinfo                                                       
        Index: 2015Q1/security/rubygem-sshkit/Makefile                                                        
        ===================================================================                                   
        --- 2015Q1/security/rubygem-sshkit/Makefile     (revision 380443)                                     
        +++ 2015Q1/security/rubygem-sshkit/Makefile     (working copy)                                        
        @@ -2,7 +2,7 @@                                                                                       
         # $FreeBSD$                                                                                          
                                                                                                              
         PORTNAME=      sshkit                                                                                
        -PORTVERSION=   1.6.1                                                                                 
        +PORTVERSION=   1.7.0                                                                                 
         CATEGORIES=    security rubygems                                                                     
         MASTER_SITES=  RG                                                                                    
                                                                                                              
        Index: 2015Q1/security/rubygem-sshkit/distinfo                                                        
        ===================================================================                                   
        --- 2015Q1/security/rubygem-sshkit/distinfo     (revision 380443)                                     
        +++ 2015Q1/security/rubygem-sshkit/distinfo     (working copy)                                        
        @@ -1,2 +1,2 @@                                                                                       
        -SHA256 (rubygem/sshkit-1.6.1.gem) = 8ca67e46bb4ea50fdb0553cda77552f3e41b17a5aa919877d93875dfa22c03a7 
        -SIZE (rubygem/sshkit-1.6.1.gem) = 135680                                                             
        +SHA256 (rubygem/sshkit-1.7.0.gem) = 90effd1813363bae7355f4a45ebc8335a8ca74acc8d0933ba6ee6d40f281a2cf 
        +SIZE (rubygem/sshkit-1.7.0.gem) = 136192                                                             
        Index: 2015Q1                                                                                         
        ===================================================================                                   
        --- 2015Q1      (revision 380443)                                                                     
        +++ 2015Q1      (working copy)                                                                        
                                                                                                              
        Property changes on: 2015Q1                                                                           
        ___________________________________________________________________                                   
        Modified: svn:mergeinfo                                                                               
           Merged /head:r380362                                                                               
        Do you want to commit? (no = start a shell) [y/n]                                                     
                                                                                                              
        Nesse ponto, o script abrira um shell para voce consertar as coisas ou abrira o editor de texto com a 
        mensagem de commit preparada e, em seguida, ira aplicar o commit.                                     
                                                                                                              
        O script assume que voce pode se conectar ao repo.FreeBSD.org com o SSH diretamente, entao se o seu   
        nome de login local for diferente da sua conta no cluster do FreeBSD, voce precisa de algumas linhas  
        em seu ~/.ssh/config:                                                                                 
                                                                                                              
        Host *.freebsd.org                                                                                    
            User freebsd-login                                                                                
                                                                                                              
          Dica:                                                                                               
                                                                                                              
        O script tambem pode aplicar mais de uma revisao por vez. Se houver outras atualizac,oes no port      
        desde que a branch foi criada e que nao foram aplicadas porque nao estavam relacionadas `a            
        seguranc,a. Adicione as diferentes revisoes na ordem em que foram feitos seus commits na linha de     
        comando mfh. A nova mensagem de log de commit contera as mensagens de log combinadas de todos os      
        commits originais. Estas mensagens devem ser editadas para mostrar o que realmente esta sendo feito   
        com o novo commit.                                                                                    
                                                                                                              
        % /usr/ports/Tools/scripts/mfh r407208 r407713 r407722 r408567 r408943 r410728                        
                                                                                                              
          Nota:                                                                                               
                                                                                                              
        O script mfh tambem pode ter um primeiro argumento opcional, a branch onde a aplicac,ao esta sendo    
        feita. Apenas a ultima branch trimestral e suportada, portanto, especificar a branch e desencorajado. 
        Por seguranc,a, o script emitira um aviso se a branch trimestral nao for a mais recente:              
                                                                                                              
        % /usr/ports/Tools/scripts/mfh 2016Q1 r407208 r407713                                                 
        /!\ The latest branch is 2016Q2, do you really want to commit to 2016Q1? [y/n]                        
    20.7. Criando uma Nova Categoria
20.7.1. Qual e o procedimento para criar uma nova categoria?
        
20.7.2. O que preciso fazer para implementar uma nova categoria fisica?
        
20.7.3. O que preciso fazer para implementar uma nova categoria virtual?
20.7.1. Qual e o procedimento para criar uma nova categoria?                                                  
        Por favor, veja Propondo uma nova categoria no FreeBSD Porter's Handbook. Uma vez que o procedimento  
        tenha sido seguido e o PR tenha sido atribuido `a Equipe de Gerenciamento de Ports                    
        <portmgr@FreeBSD.org>, e decisao deles aprova-lo ou nao. Se eles fizerem isso, e sua                  
        responsabilidade:                                                                                     
                                                                                                              
         1. Executar todos os passos necessarios. (Isso so se aplica a categorias fisicas.)                   
                                                                                                              
         2. Atualizar a definic,ao de VALID_CATEGORIES em ports/Mk/bsd.port.mk.                               
                                                                                                              
         3. Atribua o PR de volta para voce.                                                                  
20.7.2. O que preciso fazer para implementar uma nova categoria fisica?                                       
         1. Atualize o Makefile de cada port movido. Nao conecte a nova categoria ao build ainda.             
                                                                                                              
            Para fazer isso, voce precisara:                                                                  
                                                                                                              
              1. Altere as CATEGORIES do port (esse foi o ponto do exercicio, lembra?) A nova categoria esta  
                 listada primeiro. Isso ajudara a garantir que o PKGORIGIN esteja correto.                    
                                                                                                              
              2. Execute um make describe. Como o make index de nivel superior que voce executara em poucas   
                 etapas e uma iterac,ao do make describe sobre a hierarquia de ports inteira, detectar erros  
                 aqui ira salvar voce de ter que voltar a executar esse passo mais tarde.                     
                                                                                                              
              3. Se voce quiser ser realmente meticuloso, agora pode ser um bom momento para executar o       
                 portlint(1).                                                                                 
                                                                                                              
         2. Verifique se os PKGORIGINs estao corretos. O sistema de ports usa a entrada CATEGORIES de cada    
            port para criar seu PKGORIGIN, que e usado para conectar pacotes instalados ao diretorio de port  
            do qual eles foram compilados. Se esta entrada estiver errada, ferramentas de port comuns como    
            pkg_version(1) e o portupgrade(1) irao falhar.                                                    
                                                                                                              
            Para fazer isso, use a ferramenta chkorigin.sh: env PORTSDIR=/path/to/ports sh -e                 
            /path/to/ports/Tools/scripts/chkorigin.sh. Isso ira verificar todos os ports na arvore de ports,  
            mesmo aqueles que nao estao conectados `a compilac,ao, para que voce possa executa-las            
            diretamente apos a operac,ao de mudanc,a. Dica: nao esquec,a de olhar para o PKGORIGINs de        
            qualquer port slave dos ports que voce acabou de mudar!                                           
                                                                                                              
         3. Em seu proprio sistema local, teste as alterac,oes propostas: primeiro, comente as entradas       
            SUBDIR nos Makefiles das 'categorias' antigas do port; em seguida, habilite a compilac,ao da nova 
            categoria em ports/Makefile. Execute make checksubdirs nos diretorios de categoria afetados para  
            verificar as entradas SUBDIR. Em seguida, no diretorio ports/, execute make index. Isso pode      
            levar mais de 40 minutos em sistemas modernos; no entanto, e um passo necessario para evitar      
            problemas para outras pessoas.                                                                    
                                                                                                              
         4. Uma vez feito isso, voce pode fazer o commit do ports/Makefile atualizado para conectar a nova    
            categoria `a compilac,ao e tambem fazer o commit das alterac,oes do Makefile para a categoria ou  
            categorias antigas.                                                                               
                                                                                                              
         5. Adicione as entradas apropriadas no ports/MOVED.                                                  
                                                                                                              
         6. Atualize a documentac,ao modificando:                                                             
                                                                                                              
               * a lista de categorias no FreeBSD Porter's Handbook                                           
                                                                                                              
               * doc/en_US.ISO8859-1/htdocs/ports. Observe que agora eles sao exibidos por subgrupos,         
                 conforme especificado em doc/en_US.ISO8859-1/htdocs/ports/categories.descriptions.           
                                                                                                              
            (Nota: estes estao nos docs, nao nos ports, repositorio). Se voce nao e um doc committer, voce    
            precisara enviar um PR para isso.                                                                 
                                                                                                              
         7. Apenas quando todas as opc,oes acima tiverem sido concluidas, e ninguem mais estiver relatando    
            problemas com os novos ports, os ports antigos devem ser excluidos de seus locais anteriores no   
            repositorio.                                                                                      
                                                                                                              
        Nao e necessario atualizar manualmente as paginas web dos ports para refletir a nova categoria. Isso  
        sera feito automaticamente atraves da alterac,ao em en_US.ISO8859-1/htdocs/ports/categories e o       
        rebuild automatico do INDEX.                                                                          
20.7.3. O que preciso fazer para implementar uma nova categoria virtual?                                      
        Isso e muito mais simples que uma categoria fisica. Apenas algumas modificac,oes sao necessarias:     
                                                                                                              
          * a lista de categorias no FreeBSD Porter's Handbook                                                
                                                                                                              
          * en_US.ISO8859-1/htdocs/ports/categories                                                           
    20.8. Perguntas Diversas
20.8.1. Existe alguma alterac,ao para a qual possa ser feito o commit sem a aprovac,ao do mantenedor?
        
20.8.2. Como sei se meu port esta sendo compilado corretamente ou nao?
        
20.8.3. Eu adicionei um novo port. Preciso adiciona-lo ao INDEX?
        
20.8.4. Existem outros arquivos que nao tenho permissao para tocar?
        
20.8.5. Qual e o procedimento adequado para atualizar o checksum de um distfile de um port quando o arquivo e
alterado sem uma alterac,ao de versao?
        
20.8.6. Como uma build de teste experimental da arvore de ports (exp-run) pode ser solicitada?
20.8.1. Existe alguma alterac,ao para a qual possa ser feito o commit sem a aprovac,ao do mantenedor?         
        A aprovac,ao implicita para a maioria dos ports se aplica a estes tipos de correc,oes:                
                                                                                                              
          * A maioria das alterac,oes de infraestrutura para um port (isso e, modernizar, sem alterar         
            funcionalidades). Por exemplo, a aprovac,ao implicita inclui a conversao de novas macros USES,    
            ativar verbosidade de compilac,ao e alterac,oes para novas sintaxes de sistema do ports.          
                                                                                                              
          * Trivialidades e correc,oes testadas de compilac,ao e execuc,ao.                                   
                                                                                                              
          Importante:                                                                                         
                                                                                                              
        Excec,oes para isso sao qualquer coisa que seja mantido pela Equipe de Gerenciamento do Ports         
        <portmgr@FreeBSD.org> ou pelo Time de Oficiais de Seguranc,a <security-officer@FreeBSD.org>. Nenhum   
        commit nao autorizado pode ser feito em ports mantidos por esses grupos.                              
20.8.2. Como sei se meu port esta sendo compilado corretamente ou nao?                                        
        Os pacotes sao criados varias vezes por semana. Se um port falhar, o mantenedor recebera um email de  
        pkg-fallout@FreeBSD.org.                                                                              
                                                                                                              
        Relatorios para todas as compilac,oes de pacotes (oficiais, experimentais e nao regressivos) sao      
        agregados em pkg-status.FreeBSD.org.                                                                  
20.8.3. Eu adicionei um novo port. Preciso adiciona-lo ao INDEX?                                              
        Nao. O arquivo pode ser gerado executando make index, ou uma versao pre-gerada pode ser baixada com o 
        comando make fetchindex.                                                                              
20.8.4. Existem outros arquivos que nao tenho permissao para tocar?                                           
        Qualquer arquivo diretamente sob ports/, ou qualquer arquivo sob um subdiretorio que comece com uma   
        letra maiuscula (Mk/, Tools/, etc.) . Em particular, a Equipe de Gerenciamento de Ports               
        <portmgr@FreeBSD.org> protege muito o ports/Mk/bsd.port*.mk , portanto, nao fac,a alterac,oes nesses  
        arquivos, a menos que voce queira enfrentar a sua ira.                                                
20.8.5. Qual e o procedimento adequado para atualizar o checksum de um distfile de um port quando o arquivo e 
        alterado sem uma alterac,ao de versao?                                                                
        Quando o checksum de um arquivo de distribuic,ao e atualizado devido ao autor atualizar o arquivo sem 
        alterar a revisao do port, a mensagem de commit inclui um resumo dos diffs relevantes entre o         
        distfile original e novo para garantir que o distfile nao tenha sido corrompido ou alterado de        
        maneira mal-intencionada . Se a versao atual do port estiver na arvore de ports por um tempo, uma     
        copia do antigo distfile estara normalmente disponivel nos servidores ftp; caso contrario, o autor ou 
        mantenedor deve ser contatado para descobrir por que o distfile foi alterado.                         
20.8.6. Como uma build de teste experimental da arvore de ports (exp-run) pode ser solicitada?                
        Um exp-run deve ser realizado antes que seja feito o commit de patches com um impacto significativo   
        nos ports. O patch pode ser contra a arvore de ports ou o sistema base.                               
                                                                                                              
        A build completa do pacote sera feita com as correc,oes fornecidas pelo remetente, e o remetente      
        devera corrigir os problemas detectados (fallout) antes de fazer o commit.                            
                                                                                                              
         1. Va para a nova pagina de PR do Bugzilla.                                                          
                                                                                                              
         2. Selecione o produto ao qual seu patch se aplica.                                                  
                                                                                                              
         3. Preencha o relatorio de erros normalmente. Lembre-se de anexar o patch.                           
                                                                                                              
         4. Se no topo existir "Show Advanced Fields" clique sobre ele. Agora, ele dira "Hide Advanced        
            Fields". Muitos novos campos estarao disponiveis. Se a pagina ja diz "Hide Advanced Fields", nao  
            precisa fazer nada.                                                                               
                                                                                                              
         5. Na sec,ao "Flags", defina o "exp-run" para ?. Quanto a todos os outros campos, passar o mouse     
            sobre qualquer campo mostrara mais detalhes.                                                      
                                                                                                              
         6. Envie. Aguarde a build ser executada.                                                             
                                                                                                              
         7. A Equipe de Gerenciamento do Ports <portmgr@FreeBSD.org> respondera com uma possivel fallout.     
                                                                                                              
         8. Dependendo do fallout:                                                                            
                                                                                                              
               * Se nao houver nenhuma falha, o procedimento sera interrompido e voce podera fazer o commit   
                 da alterac,ao, pendente de qualquer outra aprovac,ao que seja necessaria.                    
                                                                                                              
               *   a. Se houver uma falha, ela deve ser corrigida, seja consertando os ports diretamente na   
                      arvore de ports, ou adicionando ao patch enviado.                                       
                                                                                                              
                   b. Quando isso estiver pronto, volte para a etapa 6, informando que a falha foi corrigida  
                      e aguarde a exp-run ser executada novamente. Repita quantas vezes necessario enquanto   
                      houver ports quebrados.                                                                 

21. Problemas Especificos para Desenvolvedores Que Nao Sao Committers

   Algumas pessoas que tem acesso `as maquinas do FreeBSD nao possuem commit
   bits. Quase todo este documento tambem sera aplicado a esses
   desenvolvedores (exceto itens especificos de commits e associac,oes de
   listas de discussao que os acompanham). Em particular, recomendamos que
   voce leia:

     * Detalhes Administrativos

     * Convenc,oes

  Nota:

       Pec,a ao seu mentor para adiciona-lo em "Colaboradores Adicionais"
       (doc/en_US.ISO8859-1/articles/contributors/contrib.additional.xml), se
       voce ainda nao estiver listado ha.

     * Relac,oes entre os Desenvolvedores

     * Guia de inicio rapido do SSH

     * A Grande Lista de Regras dos Committers do FreeBSD

22. Informac,oes sobre o Google Analytics

   A partir de 12 de dezembro de 2012, o Google Analytics foi habilitado no
   site do Projeto FreeBSD para coletar estatisticas anonimas sobre o uso do
   site. As informac,oes coletadas sao valiosas para o Projeto de
   Documentac,ao do FreeBSD, para identificar varios problemas no site do
   FreeBSD.

  22.1. Politica Geral do Google Analytics

   O projeto FreeBSD leva a privacidade do visitante muito a serio. Como tal,
   o site do Projeto FreeBSD honra o cabec,alho "Do Not Track" antes de
   buscar o codigo de monitoramento do Google. Para mais informac,oes,
   consulte a Politica de Privacidade do FreeBSD.

   O acesso do Google Analytics nao e arbitrariamente permitido - o acesso
   deve ser solicitado, votado pela Equipe de Engenharia de Documentac,ao
   <doceng@FreeBSD.org> e explicitamente concedido.

   Solicitac,oes de acesso aos dados do Google Analytics devem incluir uma
   finalidade especifica. Por exemplo, uma razao valida para solicitar acesso
   seria "para ver os navegadores web usados com mais frequ:encia pelos
   visitantes do website do FreeBSD para garantir que as velocidades de
   renderizac,ao da pagina sejam aceitaveis."

   Por outro lado, "ver quais navegadores sao usados com mais frequ:encia"
   (sem declarar por que) seria rejeitado.

   Todas as solicitac,oes devem incluir o periodo de tempo para o qual os
   dados seriam requisitados. Por exemplo, deve ser explicitamente declarado
   se os dados solicitados seriam requisitados em um periodo de tempo que
   abranja um periodo de 3 semanas, ou se o pedido seria para acessar apenas
   uma vez.

   Qualquer pedido de dados do Google Analytics sem uma razao clara e
   razoavel que beneficie o Projeto FreeBSD sera rejeitado.

  22.2. Dados disponiveis por meio do Google Analytics

   Alguns exemplos dos tipos de dados do Google Analytics disponiveis
   incluem:

     * Navegadores Web comumente usados

     * Tempos de carregamento de paginas

     * Acesso ao site por idioma

23. Perguntas Diversas

   23.1. Como adiciono um novo arquivo a uma branch?

   23.2. Como eu acesso people.FreeBSD.org para colocar informac,oes pessoais
   ou de projeto?

   23.3. Onde estao armazenados os arquivos da lista de discussao?

   23.4. Eu gostaria de ser mentor de um novo committer. Qual processo eu
   preciso seguir?

   23.1. Como adiciono um novo arquivo a uma branch?                          
         Para adicionar um arquivo a uma branch, simplesmente fac,a o         
         check-out ou atualize-o na branch que voce deseja adicionar e, em    
         seguida, adicione o arquivo usando a operac,ao add como faria        
         normalmente. Isso funciona bem para as arvores doc e ports. A arvore 
         src usa o SVN e requer mais cuidado por causa das propriedades       
         mergeinfo. Veja o Subversion Primer para detalhes sobre como         
         executar um MFC.                                                     
   23.2. Como eu acesso people.FreeBSD.org para colocar informac,oes pessoais 
         ou de projeto?                                                       
         O servidor people.FreeBSD.org e o mesmo que freefall.FreeBSD.org.    
         Basta criar um diretorio public_html. Qualquer coisa que voce        
         colocar nesse diretorio sera automaticamente visivel em              
         https://people.FreeBSD.org/.                                         
   23.3. Onde estao armazenados os arquivos da lista de discussao?            
         As listas de discussao sao arquivadas em /local/mail na              
         freefall.FreeBSD.org.                                                
   23.4. Eu gostaria de ser mentor de um novo committer. Qual processo eu     
         preciso seguir?                                                      
         Consulte o documento Novo Procedimento para Criac,ao de Conta nas    
         paginas internas.                                                    

24. Beneficios e vantagens para os Commiters do FreeBSD

  24.1. Reconhecimento

   O reconhecimento como engenheiro de software competente e o valor mais
   duradouro. Alem disso, ter a chance de trabalhar com algumas das melhores
   pessoas que todos os engenheiros sonham em conhecer e um grande
   privilegio!

  24.2. FreeBSD Mall

   Os committers do FreeBSD podem obter um conjunto gratuito de 4-CDs ou DVDs
   da FreeBSD Mall, Inc. em conferencias.

  24.3. IRC

   Alem disso, os desenvolvedores podem solicitar um "cloaked hostmask" para
   sua conta na rede Freenode de IRC na forma de
   freebsd/developer/nome_na_freefall ou freebsd/developer/nome_no_NickServ.
   Para solicitar uma mascara, envie um e-mail para <irc@FreeBSD.org> com o
   nome da sua hostmask solicitada e nome da conta no NickServ.

  24.4. Gandi.net

   A Gandi fornece hospedagem de sites, computac,ao em nuvem, registro de
   dominio e servic,os de certificados X.509.

   A Gandi oferece um desconto E-rate para todos os desenvolvedores do
   FreeBSD. Envie e-mail para <non-profit@gandi.net> usando o seu enderec,o
   de e-mail @freebsd.org e indique o seu identificador no Gandi.
