22.14.1 Solicitando acesso de confirmação

Quando você julgar necessário, considere solicitar acesso de confirmação seguindo estas etapas:

1. Encontre três committers que atestariam por você. Você pode ver a lista de committers em https://savannah.gnu.org/project/memberlist.php?group=guix. Cada um deles deve enviar uma declaração por e-mail para guix-maintainers@gnu.org (um alias privado para o coletivo de mantenedores), assinado com sua chave OpenPGP.

   Espera-se que os committers tenham tido algumas interações com você como colaborador e sejam capazes de julgar se você está suficientemente familiarizado com as práticas do projeto. Não é um julgamento sobre o valor do seu trabalho, então uma recusa deve ser interpretada como "vamos tentar novamente mais tarde”.

2. Envie para guix-maintainers@gnu.org uma mensagem informando sua intenção, listando os três committers que dão suporte ao seu aplicativo, assinados com a chave OpenPGP que você usará para assinar commits e fornecendo sua impressão digital (veja abaixo). Veja https://emailselfdefense.fsf.org/en/, para uma introdução à criptografia de chave pública com GnuPG.

   Configure o GnuPG de forma que ele nunca use o algoritmo de hash SHA1 para assinaturas digitais, que é conhecido por ser inseguro desde 2019, por exemplo, adicionando a seguinte linha em ~/.gnupg/gpg.conf (veja GPG Esoteric Options em The GNU Privacy Guard Manual):

   digest-algo sha512
   

3. Os mantenedores decidem, em última instância, se lhe concedem acesso de confirmação, geralmente seguindo a recomendação das suas referências.
4. Se e uma vez que você tenha recebido acesso, envie uma mensagem para guix-devel@gnu.org para dizer isso, novamente assinada com a chave OpenPGP que você usará para assinar os commits (faça isso antes de enviar seu primeiro commit). Dessa forma, todos podem notar e garantir que você controle essa chave OpenPGP.

   Importante: Antes de poder fazer push pela primeira vez, os mantenedores devem:

   1. adicione sua chave OpenPGP à ramificação keyring;
   2. adicione sua impressão digital OpenPGP ao arquivo .guix-authorizations da(s) ramificação(ões) para as quais você fará o commit.

5. Não deixe de ler o restante desta seção e... lucre!

Nota: Os mantenedores ficarão felizes em dar acesso de comprometimento a pessoas que contribuem há algum tempo e têm um histórico. Não seja tímido e não subestime seu trabalho!

No entanto, observe que o projeto está trabalhando em direção a um sistema de revisão e mesclagem de patches mais automatizado, o que, como consequência, pode nos levar a ter menos pessoas com acesso de commit ao repositório principal. Fique ligado!

Todos os commits que são enviados para o repositório central no Savannah devem ser assinados com uma chave OpenPGP, e a chave pública deve ser carregada para sua conta de usuário no Savannah e para servidores de chave pública, como keys.openpgp.org. Para configurar o Git para assinar commits automaticamente, execute:

git config commit.gpgsign true

# Substitua a impressão digital da sua chave PGP pública.
git config user.signingkey CABBA6EA1DC0FF33

Para verificar se os commits estão assinados com a chave correta, use:

guix git authenticate

Veja Compilando do git para executar a primeira autenticação de um checkout do Guix.

Para evitar enviar acidentalmente commits não assinados ou assinados com a chave errada para o Savannah, certifique-se de configurar o Git de acordo com Veja Configurando o Git.

22.14.2 Política de Comprometimento

Se você obtiver acesso de confirmação, certifique-se de seguir a política abaixo (as discussões sobre a política podem ocorrer em guix-devel@gnu.org).

Certifique-se de estar ciente de como as alterações devem ser tratadas (veja Gerenciando Patches e Branches) antes de serem enviadas ao repositório, especialmente para a ramificação master.

Se você estiver fazendo commit e enviando suas próprias alterações, tente esperar pelo menos uma semana (duas semanas para alterações mais significativas, até um mês para alterações como remover um pacote—veja Remoção de Pacotes) depois de enviá-las para revisão. Depois disso, se ninguém mais estiver disponível para revisá-las e se você estiver confiante sobre as alterações, está tudo bem fazer commit.

Ao enviar um commit em nome de outra pessoa, adicione uma linha Signed-off-by no final da mensagem de log do commit—por exemplo, com git am --signoff. Isso melhora o rastreamento de quem fez o quê.

Ao adicionar entradas de notícias do canal (veja Escrevendo Notícias do Canal), certifique-se de que elas estejam bem formadas executando o seguinte comando antes de enviar:

make check-channel-news

22.14.3 Abordando questões

A revisão por pares (veja Enviando patches) e ferramentas como guix lint (veja Invocando guix lint) e o conjunto de testes (veja Executando o conjunto de testes) devem detectar problemas antes que eles sejam enviados. No entanto, confirmações que “quebram” a funcionalidade podem ocasionalmente passar. Quando isso acontece, há duas prioridades: mitigar o impacto e entender o que aconteceu para reduzir a chance de incidentes semelhantes no futuro. A responsabilidade por ambas as coisas recai principalmente sobre os envolvidos, mas, como tudo, este é um esforço de grupo.

Alguns problemas podem afetar diretamente todos os usuários, por exemplo, porque fazem com que guix pull falhe ou interrompa a funcionalidade principal, porque interrompem pacotes importantes (em tempo de compilação ou execução) ou porque introduzem vulnerabilidades de segurança conhecidas.

As pessoas envolvidas na criação, revisão e envio de tais confirmações devem estar na vanguarda para mitigar seu impacto em tempo hábil: enviando uma confirmação de acompanhamento para corrigi-lo (se possível) ou revertendo-o para dar tempo de encontrar uma correção adequada e comunicando-se com outros desenvolvedores sobre o problema.

Se essas pessoas não estiverem disponíveis para resolver o problema a tempo, outros responsáveis pelo commit têm o direito de reverter o(s) commit(s), explicando no log de commits e na lista de discussão qual era o problema, com o objetivo de dar tempo ao responsável pelo commit original, revisor(es) e autor(es) para propor um caminho a seguir.

Uma vez que o problema tenha sido resolvido, é responsabilidade dos envolvidos garantir que a situação seja compreendida. Se você estiver trabalhando para entender o que aconteceu, concentre-se em reunir informações e evite atribuir qualquer culpa. Peça aos envolvidos para descrever o que aconteceu, não peça para eles explicarem a situação — isso os culparia implicitamente, o que não ajuda. A responsabilização vem de um consenso sobre o problema, aprendendo com ele e melhorando os processos para que seja menos provável que ele ocorra novamente.

22.14.4 Commit Revocation

Para reduzir a possibilidade de erros, os responsáveis pelo commit terão suas contas Savannah removidas do projeto Guix Savannah e suas chaves removidas de .guix-authorizations após 12 meses de inatividade; eles podem solicitar o acesso de commit novamente enviando um e-mail aos mantenedores, sem passar pelo processo de garantia.

Mantenedores⁵⁰ também pode revogar os direitos de commit de um indivíduo, como último recurso, se a cooperação com o resto da comunidade tiver causado muito atrito — mesmo dentro dos limites do código de conduta do projeto (veja Contribuindo). Eles só fariam isso após discussão pública ou privada com o indivíduo e um aviso claro. Exemplos de comportamento que dificulta a cooperação e pode levar a tal decisão incluem:

• violação repetida da política de compromisso declarada acima;
• falha repetida em levar em consideração as críticas dos colegas;
• quebrando a confiança através de uma série de incidentes graves.

Quando os mantenedores recorrem a tal decisão, eles notificam os desenvolvedores em guix-devel@gnu.org; consultas podem ser enviadas para guix-maintainers@gnu.org. Dependendo da situação, o indivíduo ainda pode ser bem-vindo para contribuir.

22.14.5 Ajudando

Uma última coisa: o projeto continua avançando porque os committers não apenas empurram suas próprias mudanças incríveis, mas também oferecem parte do seu tempo revisando e empurrando as mudanças de outras pessoas. Como committer, você é bem-vindo para usar sua expertise e direitos de commit para ajudar outros contribuidores também!