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.
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.
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:
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>.