Siguiente: , Anterior: , Subir: Contribuir   [Índice general][Índice]


16.6 Envío de parches

El desarrollo se lleva a cabo usando el sistema de control de versiones distribuido Git. Por lo tanto, no es estrictamente necesario el acceso al repositorio. Son bienvenidas las contribuciones en forma de parches como los producidos por git format-patch enviadas a la lista de correo guix-patches@gnu.org. Las desarrolladoras de Guix que lleven un tiempo en ello puede que también quieran leer la sección sobre el acceso al repositorio (véase Acceso al repositorio).

Esta lista de correo está respaldada por una instancia de Debbugs accesible en https://bugs.gnu.org/guix-patches, la cual nos permite mantener el seguimiento de los envíos. A cada mensaje enviado a esa lista de correo se le asigna un número de seguimiento; la gente puede realizar aportaciones sobre el tema mediante el envío de correos electrónicos a NNN@debbugs.gnu.org, donde NNN es el número de seguimiento (véase Envío de una serie de parches).

Le rogamos que escriba los mensajes de revisiones en formato ChangeLog (véase Change Logs en 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. Véase 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 (véase Invocación de guix lint).
  4. Asegúrese de que el paquete compile en su plataforma, usando guix build package.
  5. También le recomendamos que pruebe a construir el paquete en otras plataformas disponibles. Como puede no disponer de acceso a dichas plataformas hardware físicamente, le recomendamos el uso de qemu-binfmt-service-type para emularlas. Para activarlo, añada el siguiente servicio a la lista de servicios en su configuración operating-system:

    Una vez hecho esto, reconfigure su sistema.

    Entonces podrá construir paquetes para diferentes plataformas mediante la opción --system. Por ejemplo, para la construcción del paquete "hello" para las arquitecturas armhf, aarch64 o mips64 ejecutaría las siguientes órdenes, respectivamente:

    guix build --system=armhf-linux --rounds=2 hello
    guix build --system=aarch64-linux --rounds=2 hello
    
  6. 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.

  7. Take a look at the profile reported by guix size (véase 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 (véase 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.
  8. Para cambios importantes, compruebe que los paquetes dependientes (si aplica) no se ven afectados por el cambio; guix refresh --list-dependent package le ayudará a hacerlo (véase 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

    rama staging (cambios no disruptivos). Esta rama está pensada para ser incorporada en master cada 6 semanas más o menos. Ramas temáticas (por ejemplo, una actualización de la pila de GNOME) pueden ir en una rama específica (digamos, gnome-updates).

    más de 1.800 paquetes dependientes

    rama core-updates (puede incluir cambios mayores y potencialmente disruptivos). Esta rama está pensada para ser mezclada en master cada 6 meses más o menos.

    Todas estas ramas son seguidas por nuestra granja de construcción e incluidas en master una vez todo se ha construido satisfactoriamente. Esto nos permite corregir errores antes de que afecten a usuarias, y reducir la ventana durante la cual los binarios preconstruidos no están disponibles.

    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.

  9. 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 (véase 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.

    Otra opción es el uso de guix challenge (véase Invocación de guix challenge). Puede ejecutarse una vez la revisión del paquete haya sido publicada y construida por ci.guix.gnu.org para comprobar si obtuvo el mismo resultado que usted. Mejor aún: encuentre otra máquina que pueda construirla y ejecute guix publish. Ya que la máquina remota es probablemente diferente a la suya, puede encontrar problemas de no-determinismo relacionados con el hardware—por ejemplo, el uso de un conjunto de instrucciones extendido diferente—o con el núcleo del sistema operativo—por ejemplo, dependencias en uname o archivos /proc.

  10. Cuando escriba documentación, por favor use construcciones neutrales de género para referirse a la gente50, como singular “they”, “their”, “them” y demás.
  11. 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.

  12. Por favor, siga nuestras reglas de formato de código, posiblemente ejecutando el guión etc/indent-code.el para que lo haga automáticamente por usted (véase Formato del código).
  13. Cuando sea posible, use espejos en la URL de las fuentes (véase 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.
  14. Comprueba si Guix se puede construir correctamente (véase Construcción desde Git) y trata los avisos, especialmente aquellos acerca del uso de símbolos sin definición.
  15. 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
    

Cuando publique un parche en la lista de correo, use ‘[PATCH] …’ como el asunto, si su parche debe aplicarse sobre una rama distinta a master, digamos core-updates, especifíquelo en el asunto usando ‘[PATCH core-updates] …’. Puede usar su cliente de correo o la orden git send-email (véase Envío de una serie de parches). Preferimos recibir los parches en texto plano, ya sea en línea o como adjuntos MIME. Se le recomienda que preste atención por si su cliente de correo cambia algo como los saltos de línea o la indentación, lo que podría potencialmente romper los parches.

Cuando un error es resuelto, por favor cierre el hilo enviando un correo a NNN-done@debbugs.gnu.org.

Envío de una serie de parches

Cuando envíe una serie de parches (por ejemplo, usando git send-email), por favor mande primero un mensaje a guix-patches@gnu.org, y después mande los parches siguientes a NNN@debbugs.gnu.org para asegurarse de que se mantienen juntos. Véase la documentación de Debbugs para más información. Puede instalar git send-email con guix install git:send-email.


Notas al pie

(50)

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.


Siguiente: , Anterior: , Subir: Contribuir   [Índice general][Índice]