Next: , Previous: , Up: Contribuir   [Contents][Index]

22.8 Acceso al repositorio

Everyone can contribute to Guix without having commit access (see Envío de parches). 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.

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.8.1 Applying for Commit Access

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

  1. Encuentre tres personas que contribuyan al proyecto que puedan respaldarle. Puede ver la lista de personas que contribuyen en Cada una de ellas deberá enviar un correo confirmando el respaldo a (un alias privado para el colectivo de personas que mantienen el proyecto), firmado con su clave OpenPGP.

    Se espera que dichas personas hayan tenido algunas interacciones con usted en sus contribuciones y sean capaces de juzgar si es suficientemente familiar con las prácticas del proyecto. No es un juicio sobre el valor de su trabajo, por lo que un rechazo debe ser interpretado más bien como un “habrá que probar de nuevo más adelante”.

  2. Envíe un correo a expresando su intención, enumerando a las tres contribuidoras que respaldan su petición, firmado con su clave OpenPGP que usará para firmar las revisiones, y proporcionando su huella dactilar (véase a continuación). Véase para una introducción a la criptografía de clave pública con GnuPG.

    Configure GnuPG de modo que no use el algorítmo de hash SHA1 nunca para las firmas digitales, el cual se sabe que no es seguro desde 2019, añadiendo, por ejemplo, la siguiente línea en ~/.gnupg/gpg.conf (see GPG Esoteric Options in The GNU Privacy Guard Manual):

    digest-algo sha512
  3. Las personas que mantienen el proyecto decidirán en última instancia si conceder o no el acceso de escritura, habitualmente siguiendo las recomendaciones de las personas de referencia proporcionadas.
  4. Una vez haya conseguido acceso, en caso de hacerlo, por favor envíe un mensaje a para notificarlo, de nuevo firmado con la clave OpenPGP que vaya a usar para firmar las revisiones (hágalo antes de subir su primera revisión). De esta manera todo el mundo puede enterarse y asegurarse de que controla su clave OpenPGP.

    Importante: Antes de que suba alguna revisión por primera vez, quienes mantienen Guix deben:

    1. añadir su clave OpenPGP a la rama keyring;
    2. añadir su firma OpenPGP al archivo .guix-authorizations de la(s) rama(s) a las que vaya a subir código.
  5. Asegúrese de leer el resto de esta sección y... ¡a disfrutar!

Nota: Quienes mantienen el proyecto están encantadas de proporcionar acceso al repositorio a personas que han contribuido durante algún tiempo y tienen buen registro—¡no sea tímida y no subestime su trabajo!

No obstante, tenga en cuenta que el proyecto está trabajando hacia la automatización de la revisión de parches y el sistema de mezclas, lo que, como consecuencia, puede hacer necesario que menos gente tenga acceso de escritura al repositorio principal. ¡Seguiremos informando!

Todas las revisiones que se suban al repositorio central de Savannah deben estar firmadas por una clave OpenPGP, y la clave pública debe subirse a su cuenta de usuaria en Savannah y a servidores públicos de claves, como Para configurar que Git firme automáticamente las revisiones ejecute:

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:

make authenticate

You can prevent yourself from accidentally pushing unsigned or signed with the wrong key commits to Savannah by using the pre-push Git hook located at etc/git/pre-push:

cp etc/git/pre-push .git/hooks/pre-push

It additionally calls make check-channel-news to be sure news.scm file is correct.

22.8.2 Commit Policy

Si obtiene acceso, por favor asegúrese de seguir la política descrita a continuación (el debate sobre dicha política puede llevarse a cabo en

Changes should be posted to This mailing list fills the patch-tracking database (see Seguimiento de errores y parches). It also allows patches to be picked up and tested by the quality assurance tooling; the result of that testing eventually shows up on the dashboard at ‘’, where ISSUE_NUMBER is the number assigned by the issue tracker. Leave time for a review, without committing anything (see Envío de parches). If you didn’t receive any reply after one week (two weeks for more significant changes), and if you’re confident, it’s OK to commit.

As an exception, some changes considered “trivial” or “obvious” may be pushed directly. This includes changes to fix typos and reverting commits that caused immediate problems. This is subject to being adjusted, allowing individuals to commit directly on non-controversial changes on parts they’re familiar with.

Cuando suba un commit en nombre de alguien, por favor añada una línea de Signed-off-by al final del mensaje de la revisión—por ejemplo con git am --signoff. Esto mejora el seguimiento sobre quién hizo qué.

Cuando añada entradas de noticias del canal (see Writing Channel News), compruebe que tienen el formato correcto con la siguiente órden antes de subir los cambios al repositorio:

make check-channel-news

22.8.3 Addressing Issues

Peer review (see Envío de parches) and tools such as guix lint (see Invocación de guix lint) and the test suite (see Ejecución de la batería de pruebas) 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.8.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.

Maintainers58 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 (see Contribuir). 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.8.5 Helping Out

Una última cosa: el proyecto sigue adelante porque las contribuidoras no solo suben sus cambios, sino que también ofrecen su tiempo revisando y subiendo cambios de otras personas. Como contribuidora, también se agradece que use su experiencia y derechos de escritura en el repositorio para ayudar a otras personas que quieren contribuir.



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

Next: , Previous: , Up: Contribuir   [Contents][Index]