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

22.6 Envío de parches

Development is done using the Git distributed version control system. Thus, access to the repository is not strictly necessary. We welcome contributions in the form of patches as produced by git format-patch sent to the guix-patches@gnu.org mailing list (see Submitting patches to a project in Git User Manual). Contributors are encouraged to take a moment to set some Git repository options (see Configuring Git) first, which can improve the readability of patches. Seasoned Guix developers may also want to look at the section on commit access (see Acceso al repositorio).

This mailing list is backed by a Debbugs instance, which allows us to keep track of submissions (see Seguimiento de errores y parches). Each message sent to that mailing list gets a new tracking number assigned; people can then follow up on the submission by sending email to ISSUE_NUMBER@debbugs.gnu.org, where ISSUE_NUMBER is the tracking number (see Envío de una serie de parches).

Le rogamos que escriba los mensajes de revisiones en formato ChangeLog (see Change Logs in GNU Coding Standards); puede comprobar la historia de revisiones en busca de ejemplos.

Antes de enviar un parche que añade o modifica una definición de un paquete, por favor recorra esta lista de comprobaciones:

  1. Si las autoras del paquete software proporcionan una firma criptográfica para el archivo de la versión, haga un esfuerzo para verificar la autenticidad del archivo. Para un archivo de firma GPG separado esto puede hacerse con la orden gpg --verify.
  2. Dedique algún tiempo a proporcionar una sinopsis y descripción adecuadas para el paquete. See Sinopsis y descripciones, para algunas directrices.
  3. Ejecute guix lint paquete, donde paquete es el nombre del paquete nuevo o modificado, y corrija cualquier error del que informe (see Invocación de guix lint).
  4. Run guix style package to format the new package definition according to the project’s conventions (see Invoking guix style).
  5. Asegúrese de que el paquete compile en su plataforma, usando guix build package.
  6. We recommend you also try building the package on other supported platforms. As you may not have access to actual hardware platforms, we recommend using the qemu-binfmt-service-type to emulate them. In order to enable it, add the virtualization service module and the following service to the list of services in your operating-system configuration: 
    (service qemu-binfmt-service-type
 (qemu-binfmt-configuration
   (platforms (lookup-qemu-platforms "arm" "aarch64"))))

    Una vez hecho esto, reconfigure su sistema.

    You can then build packages for different platforms by specifying the --system option. For example, to build the "hello" package for the armhf or aarch64 architectures, you would run the following commands, respectively: 

    guix build --system=armhf-linux --rounds=2 hello
guix build --system=aarch64-linux --rounds=2 hello
  7. Asegúrese de que el paquete no usa copias empaquetadas de software ya disponible como paquetes separados.

    A veces, paquetes incluyen copias embebidas del código fuente de sus dependencias para conveniencia de las usuarias. No obstante, como distribución, queremos asegurar que dichos paquetes efectivamente usan la copia que ya tenemos en la distribución si hay ya una. Esto mejora el uso de recursos (la dependencia es construida y almacenada una sola vez), y permite a la distribución hacer cambios transversales como aplicar actualizaciones de seguridad para un software dado en un único lugar y que afecte a todo el sistema—algo que esas copias embebidas impiden.

  8. Take a look at the profile reported by guix size (see Invocación de guix size). This will allow you to notice references to other packages unwillingly retained. It may also help determine whether to split the package (see Paquetes con múltiples salidas), and which optional dependencies should be used. In particular, avoid adding texlive as a dependency: because of its extreme size, use the texlive-tiny package or texlive-union procedure instead.
  9. For important changes, check that dependent packages (if applicable) are not affected by the change; guix refresh --list-dependent package will help you do that (see Invocación de guix refresh).

    En base al número de paquetes dependientes y, por tanto, del tamaño de la reconstrucción inducida, los revisiones van a ramas separadas, según estas líneas:

    300 paquetes dependientes o menos

    rama master (cambios no disruptivos).

    entre 300 y 1.800 paquetes dependientes

    staging branch (non-disruptive changes). This branch is intended to be merged in master every 6 weeks or so. Topical changes (e.g., an update of the GNOME stack) can instead go to a specific branch (say, gnome-updates). This branch is not expected to be buildable or usable until late in its development process.

    más de 1.800 paquetes dependientes

    core-updates branch (may include major and potentially disruptive changes). This branch is intended to be merged in master every 6 months or so. This branch is not expected to be buildable or usable until late in its development process.

    All these branches are tracked by our build farm and merged into master once everything has been successfully built. This allows us to fix issues before they hit users, and to reduce the window during which pre-built binaries are not available.

    When we decide to start building the staging or core-updates branches, they will be forked and renamed with the suffix -frozen, at which time only bug fixes may be pushed to the frozen branches. The core-updates and staging branches will remain open to accept patches for the next cycle. Please ask on the mailing list or IRC if unsure where to place a patch.

  10. Compruebe si el proceso de construcción de un paquete es determinista. Esto significa típicamente comprobar si una construcción independiente del paquete ofrece exactamente el mismo resultado que usted obtuvo, bit a bit.

    Una forma simple de hacerlo es construyendo el mismo paquete varias veces seguidas en su máquina (see Invocación de guix build): 

    guix build --rounds=2 mi-paquete

    Esto es suficiente una clase común de problemas de no-determinismo, como las marcas de tiempo o salida generada aleatoriamente en el resultado de la construcción.

    Another option is to use guix challenge (see Invocación de guix challenge). You may run it once the package has been committed and built by ci.guix.gnu.org to check whether it obtains the same result as you did. Better yet: Find another machine that can build it and run guix publish. Since the remote build machine is likely different from yours, this can catch non-determinism issues related to the hardware—e.g., use of different instruction set extensions—or to the operating system kernel—e.g., reliance on uname or /proc files.

  11. Cuando escriba documentación, por favor use construcciones neutrales de género para referirse a la gente54, como singular “they”, “their”, “them” y demás.
  12. Compruebe que su parche contiene únicamente un conjunto relacionado de cambios. Agrupando cambios sin relación dificulta y ralentiza la revisión.

    Ejemplos de cambios sin relación incluyen la adición de varios paquetes, o una actualización de un paquete junto a correcciones a ese paquete.

  13. Please follow our code formatting rules, possibly running guix style script to do that automatically for you (see Formato del código).
  14. Cuando sea posible, use espejos en la URL de las fuentes (see Invocación de guix download). Use URL fiables, no generadas. Por ejemplo, los archivos de GitHub no son necesariamente idénticos de una generación a la siguiente, así que en este caso es normalmente mejor clonar el repositorio. No use el campo name en la URL: no es muy útil y si el nombre cambia, la URL probablemente estará mal.
  15. Comprueba si Guix se puede construir correctamente (see Construcción desde Git) y trata los avisos, especialmente aquellos acerca del uso de símbolos sin definición.
  16. Asegúrese de que sus cambios no rompen Guix y simule guix pull con: 
    guix pull --url=/ruta/a/su/copia --profile=/tmp/guix.master

When posting a patch to the mailing list, use ‘[PATCH] …’ as a subject, if your patch is to be applied on a branch other than master, say core-updates, specify it in the subject like ‘[PATCH core-updates] …’.

You may use your email client or the git send-email command (see Envío de una serie de parches). We prefer to get patches in plain text messages, either inline or as MIME attachments. You are advised to pay attention if your email client changes anything like line breaks or indentation which could potentially break the patches.

Expect some delay when you submit your very first patch to guix-patches@gnu.org. You have to wait until you get an acknowledgement with the assigned tracking number. Future acknowledgements should not be delayed.

When a bug is resolved, please close the thread by sending an email to ISSUE_NUMBER-done@debbugs.gnu.org.

Footnotes

(54)

NdT: En esta traducción se ha optado por usar el femenino para referirse a personas, ya que es el género gramatical de dicha palabra. Aunque las construcciones impersonales pueden adoptarse en la mayoría de casos, también pueden llegar a ser muy artificiales en otros usos del castellano; en ocasiones son directamente imposibles. Algunas construcciones que proponen la neutralidad de género dificultan la lectura automática (-x), o bien dificultan la corrección automática (-e), o bien aumentan significativamente la redundancia y reducen del mismo modo la velocidad en la lectura (-as/os, -as y -os). No obstante, la adopción del genero neutro heredado del latín, el que en castellano se ha unido con el masculino, como construcción neutral de género se considera inaceptable, ya que sería equivalente al “it” en inglés, nada más lejos de la intención de las autoras originales del texto.

Next: Seguimiento de errores y parches, Previous: Estilo de codificación, Up: Contribuir   [Contents][Index]