Próximo: , Anterior: , Acima: Contribuindo   [Conteúdo][Índice]

22.12 Confirmar acesso

Everyone can contribute to Guix without having commit access (veja Enviando patches). However, for frequent contributors, having write access to the repository can be convenient. As a rule of thumb, a contributor should have accumulated fifty (50) reviewed commits to be considered as a committer and have sustained their activity in the project for at least 6 months. This ensures enough interactions with the contributor, which is essential for mentoring and assessing whether they are ready to become a committer. Commit access should not be thought of as a “badge of honor” but rather as a responsibility a contributor is willing to take to help the project. It is expected from all contributors, and even more so from committers, to help build consensus and make decisions based on consensus. By using consensus, we are committed to finding solutions that everyone can live with. It implies that no decision is made against significant concerns and these concerns are actively resolved with proposals that work for everyone. A contributor (which may or may not have commit access) wishing to block a proposal bears a special responsibility for finding alternatives, proposing ideas/code or explain the rationale for the status quo to resolve the deadlock. To learn what consensus decision making means and understand its finer details, you are encouraged to read

The following sections explain how to get commit access, how to be ready to push commits, and the policies and community expectations for commits pushed upstream.

22.12.1 Applying for Commit Access

When you deem it necessary, consider applying for commit access by following these steps:

  1. Find three committers who would vouch for you. You can view the list of committers at Each of them should email a statement to (a private alias for the collective of maintainers), signed with their OpenPGP key.

    Committers are expected to have had some interactions with you as a contributor and to be able to judge whether you are sufficiently familiar with the project’s practices. It is not a judgment on the value of your work, so a refusal should rather be interpreted as “let’s try again later”.

  2. Send a message stating your intent, listing the three committers who support your application, signed with the OpenPGP key you will use to sign commits, and giving its fingerprint (see below). See, for an introduction to public-key cryptography with GnuPG.

    Set up GnuPG such that it never uses the SHA1 hash algorithm for digital signatures, which is known to be unsafe since 2019, for instance by adding the following line to ~/.gnupg/gpg.conf (veja GPG Esoteric Options em The GNU Privacy Guard Manual):

    digest-algo sha512
  3. Maintainers ultimately decide whether to grant you commit access, usually following your referrals’ recommendation.
  4. If and once you’ve been given access, please send a message to to say so, again signed with the OpenPGP key you will use to sign commits (do that before pushing your first commit). That way, everyone can notice and ensure you control that OpenPGP key.

    Importante: Before you can push for the first time, maintainers must:

    1. add your OpenPGP key to the keyring branch;
    2. add your OpenPGP fingerprint to the .guix-authorizations file of the branch(es) you will commit to.
  5. Make sure to read the rest of this section and... profit!

Nota: Maintainers are happy to give commit access to people who have been contributing for some time and have a track record—don’t be shy and don’t underestimate your work!

However, note that the project is working towards a more automated patch review and merging system, which, as a consequence, may lead us to have fewer people with commit access to the main repository. Stay tuned!

All commits that are pushed to the central repository on Savannah must be signed with an OpenPGP key, and the public key should be uploaded to your user account on Savannah and to public key servers, such as To configure Git to automatically sign commits, run:

git config commit.gpgsign true

# Substitute the fingerprint of your public PGP key.
git config user.signingkey CABBA6EA1DC0FF33

To check that commits are signed with correct key, use:

guix git authenticate

Veja Compilando do git for running the first authentication of a Guix checkout.

To avoid accidentally pushing unsigned or signed with the wrong key commits to Savannah, make sure to configure Git according to Veja Configurando o Git.

22.12.2 Commit Policy

If you get commit access, please make sure to follow the policy below (discussions of the policy can take place on

Ensure you’re aware of how the changes should be handled (veja Managing Patches and Branches) prior to being pushed to the repository, especially for the master branch.

If you’re committing and pushing your own changes, try and wait at least one week (two weeks for more significant changes) after you send them for review. After this, if no one else is available to review them and if you’re confident about the changes, it’s OK to commit.

When pushing a commit on behalf of somebody else, please add a Signed-off-by line at the end of the commit log message—e.g., with git am --signoff. This improves tracking of who did what.

When adding channel news entries (veja Writing Channel News), make sure they are well-formed by running the following command right before pushing:

make check-channel-news

22.12.3 Addressing Issues

Peer review (veja Enviando patches) and tools such as guix lint (veja Invocando guix lint) and the test suite (veja Executando a suíte de testes) should catch issues before they are pushed. Yet, commits that “break” functionality might occasionally go through. When that happens, there are two priorities: mitigating the impact, and understanding what happened to reduce the chance of similar incidents in the future. The responsibility for both these things primarily lies with those involved, but like everything this is a group effort.

Some issues can directly affect all users—for instance because they make guix pull fail or break core functionality, because they break major packages (at build time or run time), or because they introduce known security vulnerabilities.

The people involved in authoring, reviewing, and pushing such commit(s) should be at the forefront to mitigate their impact in a timely fashion: by pushing a followup commit to fix it (if possible), or by reverting it to leave time to come up with a proper fix, and by communicating with other developers about the problem.

If these persons are unavailable to address the issue in time, other committers are entitled to revert the commit(s), explaining in the commit log and on the mailing list what the problem was, with the goal of leaving time to the original committer, reviewer(s), and author(s) to propose a way forward.

Once the problem has been dealt with, it is the responsibility of those involved to make sure the situation is understood. If you are working to understand what happened, focus on gathering information and avoid assigning any blame. Do ask those involved to describe what happened, do not ask them to explain the situation—this would implicitly blame them, which is unhelpful. Accountability comes from a consensus about the problem, learning from it and improving processes so that it’s less likely to reoccur.

22.12.4 Commit Revocation

In order to reduce the possibility of mistakes, committers will have their Savannah account removed from the Guix Savannah project and their key removed from .guix-authorizations after 12 months of inactivity; they can ask to regain commit access by emailing the maintainers, without going through the vouching process.

Maintainers49 may also revoke an individual’s commit rights, as a last resort, if cooperation with the rest of the community has caused too much friction—even within the bounds of the project’s code of conduct (veja Contribuindo). They would only do so after public or private discussion with the individual and a clear notice. Examples of behavior that hinders cooperation and could lead to such a decision include:

When maintainers resort to such a decision, they notify developers on; inquiries may be sent to Depending on the situation, the individual may still be welcome to contribute.

22.12.5 Helping Out

One last thing: the project keeps moving forward because committers not only push their own awesome changes, but also offer some of their time reviewing and pushing other people’s changes. As a committer, you’re welcome to use your expertise and commit rights to help other contributors, too!

Notas de Rodapé


See for the current list of maintainers. You can email them privately at

Próximo: Revendo o trabalho de outros, Anterior: Rastreando Bugs e Mudanças, Acima: Contribuindo   [Conteúdo][Índice]