22.11.2 Gerenciando Patches e Branches

As alterações devem ser postadas em guix-patches@gnu.org. Esta lista de discussão preenche o banco de dados de rastreamento de patches (veja O rastreador de problemas). Ela também permite que patches sejam coletados e testados pela ferramenta de garantia de qualidade; o resultado desse teste eventualmente aparece no painel em ‘https://qa.guix.gnu.org/issue/NÚMERO_DE_ISSÃO’, onde NÚMERO_DE_ISSÃO é o número atribuído pelo rastreador de problemas. Reserve um tempo para uma revisão, sem comprometer nada.

Como exceção, algumas mudanças consideradas “triviais” ou “óbvias” podem ser enviadas diretamente para o branch master. Isso inclui mudanças para corrigir erros de digitação e reverter commits que causaram problemas imediatos. Isso está sujeito a ajustes, permitindo que indivíduos se comprometam diretamente com mudanças não controversas em partes com as quais estão familiarizados.

Alterações que afetam mais de 300 pacotes dependentes (veja Invocando guix refresh) devem primeiro ser enviadas para um branch de tópico diferente de master; o conjunto de alterações deve ser consistente, por exemplo, “GNOME update”, “NumPy update”, etc. Isso permite testes: o branch aparecerá automaticamente em ‘https://qa.guix.gnu.org/branch/branch’, com uma indicação de seu status de compilação em várias plataformas.

Para ajudar a coordenar a fusão de branches, você deve criar um novo problema guix-patches sempre que criar um branch (veja O rastreador de problemas). O título do problema que solicita a fusão de um branch deve ter o seguinte formato:

Solicitação de mesclagem do branch "name"

O infraestrutura de QA reconhece tais problemas e lista as solicitações de mesclagem em sua página principal. Os seguintes pontos se aplicam ao gerenciamento dessas ramificações:

1. Os commits no branch devem ser uma combinação dos patches relevantes para o branch. Patches não relacionados ao tópico do branch devem ir para outro lugar.
2. Quaisquer alterações que possam ser feitas no branch master, devem ser feitas no branch master. Se um commit puder ser dividido para aplicar parte das alterações no master, isso é bom de se fazer.
3. Deve ser possível recriar a ramificação iniciando pelo master e aplicando os patches relevantes.
4. Evite mesclar o master no branch. Prefira rebasear ou recriar o branch em cima de uma revisão master atualizada.
5. Minimize as alterações no master que estão faltando no branch antes de mesclar o branch no master. Isso significa que o estado do branch reflete melhor o estado do master caso o branch seja mesclado.
6. Se você não tiver acesso de commit, crie o issue “Request for merging” e solicite que alguém crie o branch. Inclua uma lista de issues/patches para incluir no branch.

Normalmente, os branches serão mesclados de uma maneira “primeiro a chegar, primeiro a ser mesclado”, rastreados por meio dos problemas guix-patches. Se você concordar com uma ordem diferente com os envolvidos, você pode rastrear isso atualizando which issues block⁴⁷ which other issues. Portanto, para saber qual branch está na frente da fila, procure o issue mais antigo, ou o issue que não está bloqueado por nenhuma outra branch merges. Uma lista ordenada de branches com os issues abertos está disponível em https://qa.guix.gnu.org.

Uma vez que um branch esteja na frente da fila, espere até que tenha passado tempo suficiente para que as farms de build tenham processado as mudanças, e para que os testes necessários tenham acontecido. Por exemplo, você pode verificar ‘https://qa.guix.gnu.org/branch/branch’ para ver informações sobre alguns builds e disponibilidade de substitutos.

Depois que a ramificação for mesclada, o problema deverá ser fechado e a ramificação excluída.

Sometimes, a branch may be a work in progress, for example for larger efforts such as updating the GNOME desktop. In these cases, the branch name should reflect this by having the ‘wip-’ prefix. The QA infrastructure will avoid building work-in-progress branches, so that the available resources can be better focused on building the branches that are ready to be merged. When the branch is no longer a work in progress, it should be renamed, with the ‘wip-’ prefix removed, and only then should the merge requests be created, as documented earlier.