6.2. Enviando código para o projeto (Committing code)

O processo de commit de um código novo ou modificado é um dos processos mais frequentes no projeto FreeBSD e geralmente acontece muitas vezes ao dia. O commit do código só pode ser feito por um committer. Committers aplicam código escrito por eles mesmos, código enviado a eles ou código enviado através de um relatório de problemas.

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

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

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

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

Figura 6.3. Resumo do processo: um committer aplica o código
Resumo do processo: um committer aplica o código


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

Figura 6.4. Resumo do processo: um colaborador envia o código
Resumo do processo: um colaborador envia o código


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

Hats incluídos neste processo são:

  1. Committer

  2. Contributor

  3. Vendor

  4. Reviewer

[FreeBSD, 2001] [Jørgensen, 2001]

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.