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 https://savannah.gnu.org/project/memberlist.php?group=guix. Cada una de ellas deberá enviar un correo confirmando el respaldo a guix-maintainers@gnu.org (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 guix-maintainers@gnu.org 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 https://emailselfdefense.fsf.org/es/ 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 guix-devel@gnu.org 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 keys.openpgp.org. 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 guix-devel@gnu.org).

Los parches no triviales deben enviarse siempre a guix-patches@gnu.org (los parches triviales incluyen la corrección de errores tipográficos, etcétera). Esta lista de correo rellena la base de datos de seguimiento de parches (see Seguimiento de errores y parches).

Para los parches que únicamente añaden un nuevo paquete, y uno simple, está bien subirlos directamente, si tiene confianza en ello (lo que significa que lo ha construido de manera correcta en un entorno chroot, y ha hecho un auditado razonable de derechos de copia y licencias). Lo mismo puede ser dicho de las actualizaciones de paquetes, excepto actualizaciones que desencadenen muchas reconstrucciones (por ejemplo, la actualización de GnuTLS o GLib). Tenemos una lista de correo para las notificaciones de revisiones (guix-commits@gnu.org), de manera que la gente pueda enterarse. Antes de subir los cambios, asegúrese de ejecutar git pull --rebase.

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

Para cualquier otra cosa, envíe un mensaje a guix-patches@gnu.org y deje tiempo para que sea revisado, sin subir ningún cambio (see Envío de parches). Si no recibe ninguna respuesta después de dos semanas y tiene confianza en ello, está bien subir el cambio.

Esta última parte está sujeta a revisión, para permitir a individualidades que suban cambios que no puedan generar controversia directamente en partes con las que estén familiarizadas.

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.

Maintainers⁵⁷ 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:

• repeated violation of the commit policy stated above;
• repeated failure to take peer criticism into account;
• breaching trust through a series of grave incidents.

When maintainers resort to such a decision, they notify developers on guix-devel@gnu.org; inquiries may be sent to guix-maintainers@gnu.org. 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.