You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

1017 lines
45 KiB

  1. @node Contribuir
  2. @chapter Contribuir
  3. Este proyecto es un esfuerzo colaborativo, y ¡necesitamos su ayuda para que
  4. crezca! Por favor, contacte con nosotras en @email{guix-devel@@gnu.org} y en
  5. @code{#guix} en la red IRC Freenode. Estamos abiertas a ideas, informes de
  6. errores, parches y cualquier cosa que pueda ser de ayuda para el
  7. proyecto. Especialmente se agradece ayuda en empaquetamiento
  8. (@pxref{Guías de empaquetamiento}).
  9. @cindex código de conducta, de contribuidoras
  10. @cindex acuerdo de contribución
  11. Queremos proporcionar un entorno cálido, amistoso y libre de acoso, para que
  12. cualquiera pueda contribuir al máximo de sus capacidades. Para este fin
  13. nuestro proyecto usa un ``Acuerdo de Contribución'', que fue adaptado de
  14. @url{http://contributor-coventant.org}. Se puede encontrar una versión local
  15. en el fichero @file{CODE-OF-CONDUCT} del árbol de fuentes.
  16. Las contribuidoras no están obligadas a usar su nombre legal en los parches
  17. ni en la comunicación on-line; pueden usar cualquier nombre o seudónimo de
  18. su elección.
  19. @menu
  20. * Construcción desde Git:: Lo último y mejor.
  21. * Ejecución de Guix antes de estar instalado:: Trucos de hacker.
  22. * La configuración perfecta:: Las herramientas adecuadas.
  23. * Guías de empaquetamiento:: Crecimiento de la distribución.
  24. * Estilo de codificación:: Higiene de la contribuidora.
  25. * Envío de parches:: Comparta su trabajo.
  26. @end menu
  27. @node Construcción desde Git
  28. @section Construcción desde Git
  29. Si quiere picar en el mismo Guix se recomienda usar la última versión del
  30. repositorio Git:
  31. @example
  32. git clone https://git.savannah.gnu.org/git/guix.git
  33. @end example
  34. Cuando se compila Guix de una copia de trabajo local (checkout), se
  35. requieren los siguientes paquetes, además de los mencionados en las
  36. instrucciones de instalación (@pxref{Requisitos}).
  37. @itemize
  38. @item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
  39. @item @url{http://gnu.org/software/automake/, GNU Automake};
  40. @item @url{http://gnu.org/software/gettext/, GNU Gettext};
  41. @item @url{http://gnu.org/software/texinfo/, GNU Texinfo};
  42. @item @url{http://www.graphviz.org/, Graphviz};
  43. @item @url{http://www.gnu.org/software/help2man/, GNU Help2man (opcional)}.
  44. @end itemize
  45. El modo más fácil de preparar un entorno de desarrollo para Guix es, por
  46. supuesto, ¡usando Guix! Las siguientes órdenes inician un nuevo intérprete
  47. donde todas las dependencias y las variables de entorno apropiadas están
  48. listas para picar código en Guix:
  49. @example
  50. guix environment guix
  51. @end example
  52. @xref{Invocación de guix environment}, para más información sobre esa orden. Se
  53. pueden añadir dependencias adicionales con la opción @option{--ad-hoc}:
  54. @example
  55. guix environment guix --ad-hoc help2man git strace
  56. @end example
  57. Ejecute @command{./bootstrap} para generar la infraestructura del sistema de
  58. construcción usando Autoconf y Automake. Si obtiene un error como este:
  59. @example
  60. configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
  61. @end example
  62. @noindent
  63. probablemente significa que Autoconf no pudo encontrar el fichero pkg.m4,
  64. que proporciona pkg-config. Asegurese de que @file{pkg.m4} está
  65. disponible. Lo mismo aplica para el conjunto de macros @file{guile.m4} que
  66. proporciona Guile. Por ejemplo, si ha instalado Automake en
  67. @file{/usr/local}, no va a buscar ficheros @file{.m4} en
  68. @file{/usr/share}. En ese caso tiene que ejecutar la siguiente orden:
  69. @example
  70. export ACLOCAL_PATH=/usr/share/aclocal
  71. @end example
  72. @xref{Macro Search Path,,, automake, The GNU Automake Manual} para más
  73. información.
  74. Entonces, ejecute @command{./configure} como siempre. Asegurese de pasar
  75. @code{--localstatedir=@var{directorio}}, donde @var{directorio} es el valor
  76. de @code{localstatedir} usado por su instalación actual (@pxref{El almacén},
  77. para información sobre esto).
  78. Finalmente, tiene que ejecutar @code{make check} para iniciar las pruebas
  79. (@pxref{Ejecución de la batería de pruebas}). Si algo falla, eche un vistazo a las
  80. instrucciones de instalación (@pxref{Instalación}) o envíe un mensaje---en
  81. Inglés---a la @email{guix-devel@@gnu.org, lista de correo}.
  82. @node Ejecución de Guix antes de estar instalado
  83. @section Ejecución de Guix antes de estar instalado
  84. Para mantener un entorno de trabajo estable, encontrará útil probar los
  85. cambios hechos en su copia de trabajo local sin instalarlos realmente. De
  86. esa manera, puede distinguir entre su sombrero de ``usuaria final'' y el
  87. traje de ``harapos''.
  88. Para dicho fin, todas las herramientas de línea de órdenes pueden ser usadas
  89. incluso si no ha ejecutado @code{make install}. Para hacerlo, primero
  90. necesita tener un entorno con todas las dependencias disponibles
  91. (@pxref{Construcción desde Git}), y entonces añada al inicio de cada orden
  92. @command{./pre-inst-env} (el guión @file{pre-inst-env} se encuentra en la
  93. raíz del árbol de compilación de Guix, como en@footnote{La opción
  94. @option{-E} a @command{sudo} asegura que @code{GUILE_LOAD_PATH} contiene la
  95. información correcta para que @command{guix-daemon} y las herramientas que
  96. usa puedan encontrar los módulos Guile que necesitan.}:
  97. @example
  98. $ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
  99. $ ./pre-inst-env guix build hello
  100. @end example
  101. @noindent
  102. De manera similar, para una sesión de Guile que use los módulos Guix:
  103. @example
  104. $ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
  105. ;;; ("x86_64-linux")
  106. @end example
  107. @noindent
  108. @cindex REPL
  109. @cindex entorno interactivo
  110. @dots{} y para un entorno interactivo (REPL) (@pxref{Using Guile
  111. Interactively,,, guile, Guile Reference Manual}):
  112. @example
  113. $ ./pre-inst-env guile
  114. scheme@@(guile-user)> ,use(guix)
  115. scheme@@(guile-user)> ,use(gnu)
  116. scheme@@(guile-user)> (define serpientes
  117. (fold-packages
  118. (lambda (paquete lst)
  119. (if (string-prefix? "python"
  120. (package-name paquete))
  121. (cons paquete lst)
  122. lst))
  123. '()))
  124. scheme@@(guile-user)> (length serpientes)
  125. $1 = 361
  126. @end example
  127. El guión @command{pre-inst-env} fija todas las variables de entorno
  128. necesarias para permitir esto, incluyendo @env{PATH} y
  129. @env{GUILE_LOAD_PATH}.
  130. Fíjese que la orden @command{./pre-inst-env guix pull} @emph{no} actualiza
  131. el árbol de fuentes local; simplemente actualiza el enlace
  132. @file{~/.config/guix/latest} (@pxref{Invocación de guix pull}). Ejecute
  133. @command{git pull} si quiere actualizar su árbol de fuentes local.
  134. @node La configuración perfecta
  135. @section La configuración perfecta
  136. La configuración perfecta para hackear en Guix es básicamente la
  137. configuración perfecta para hacerlo en Guile (@pxref{Using Guile in Emacs,,,
  138. guile, Guile Reference Manual}). Primero, necesita más que un editor,
  139. necesita @url{http://www.gnu.org/software/emacs, Emacs}, empoderado por el
  140. maravilloso @url{http://nongnu.org/geiser, Geiser}. Para configurarlo,
  141. ejecute:
  142. @example
  143. guix package -i emacs guile emacs-geiser
  144. @end example
  145. Geiser permite desarrollo incremental e interactivo dentro de Emacs:
  146. compilación y evaluación de código dentro de los buffers, acceso a
  147. documentación en línea (docstrings), completado dependiente del contexto,
  148. @kbd{M-.} para saltar a la definición de un objeto, una consola interactiva
  149. (REPL) para probar su código, y más (@pxref{Introducción,,, geiser, Geiser
  150. User Manual}). Para desarrollar Guix adecuadamente, asegúrese de aumentar la
  151. ruta de carga de Guile (load-path) para que encuentre los ficheros fuente de
  152. su copia de trabajo:
  153. @lisp
  154. ;; @r{Suponiendo que la copia de trabajo de Guix está en ~/src/guix.}
  155. (with-eval-after-load 'geiser-guile
  156. (add-to-list 'geiser-guile-load-path "~/src/guix"))
  157. @end lisp
  158. Para realmente editar el código, Emacs tiene un modo limpio para
  159. Scheme. Pero además de eso, no debe perderse
  160. @url{http://www.emacswiki.org/emacs/ParEdit, Paredit}. Provee de facilidades
  161. para operar directamente en el árbol sintáctico como elevar una expresión S
  162. o recubrirla, embeber o expulsar la siguiente expresión S, etc.
  163. @cindex fragmentos de código
  164. @cindex plantillas
  165. @cindex reducir la verborrea
  166. También proporcionamos plantillas para los mensajes de revisión de git
  167. comunes y definiciones de paquetes en el directorio
  168. @file{etc/snippets}. Estas plantillas pueden ser usadas con
  169. @url{http://joaotavora.github.io/yasnippet, YASnippet} para expandir
  170. mnemotécnicos a fragmentos interactivos de texto. Puedes querer añadir el
  171. directorio de fragmentos a la variable @var{yas-snippet-dirs} en Emacs.
  172. @lisp
  173. ;; @r{Suponiendo que la copia de trabajo de Guix está en ~/src/guix.}
  174. (with-eval-after-load 'yasnippet
  175. (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets"))
  176. @end lisp
  177. Los fragmentos de mensajes de la revisión dependen de
  178. @url{https://magit.vc/, Magit} para mostrar los ficheros preparados. En la
  179. edición del mensaje de la revisión teclee @code{add} seguido de @kbd{TAB}
  180. (el tabulador) para insertar la plantilla del mensaje de la revisión de
  181. adición de un paquete; teclee @code{update} seguido de @kbd{TAB} para
  182. insertar una plantilla de actualización de un paquete; teclee @code{https}
  183. seguido de @kbd{TAB} para insertar una plantilla para cambiar la URI de la
  184. página de un paquete a HTTPS.
  185. El fragmento principal para @code{scheme-mode} es activado al teclear
  186. @code{package...} seguido de @kbd{TAB}. Este fragmento también inserta el
  187. lanzador @code{origin...} que puede ser expandido de nuevo. El fragmento
  188. @code{origin} puede a su vez insertar otros identificadores de lanzado
  189. terminando en @code{...}, que pueden ser expandidos de nuevo.
  190. @node Guías de empaquetamiento
  191. @section Guías de empaquetamiento
  192. @cindex paquetes, creación
  193. La distribución GNU es reciente y puede no disponer de alguno de sus
  194. paquetes favoritos. Esta sección describe cómo puede ayudar a hacer crecer
  195. la distribución.
  196. Los paquetes de software libre habitualmente se distribuyen en forma de
  197. @dfn{archivadores de código fuente}---típicamente ficheros @file{tar.gz} que
  198. contienen todos los ficheros fuente. Añadir un paquete a la distribución
  199. significa esencialmente dos cosas: añadir una @dfn{receta} que describe cómo
  200. construir el paquete, la que incluye una lista de otros paquetes necesarios
  201. para la construcción, y añadir @dfn{metadatos del paquete} junto a dicha
  202. receta, como la descripción y la información de licencias.
  203. En Guix toda esta información está contenida en @dfn{definiciones de
  204. paquete}. Las definiciones de paquete proporcionan una vista de alto nivel
  205. del paquete. Son escritas usando la sintaxis del lenguaje de programación
  206. Scheme; de hecho, definimos una variable por cada paquete enlazada a su
  207. definición y exportamos esa variable desde un módulo (@pxref{Módulos de paquetes}). No obstante, un conocimiento profundo de Scheme @emph{no} es un
  208. pre-requisito para la creación de paquetes. Para más información obre las
  209. definiciones de paquetes, @pxref{Definición de paquetes}.
  210. Una vez que una definición de paquete está en su lugar, almacenada en un
  211. fichero del árbol de fuentes de Guix, puede probarse usando la orden
  212. @command{guix build} (@pxref{Invocación de guix build}). Por ejemplo, asumiendo
  213. que el nuevo paquete se llama @code{gnuevo}, puede ejecutar esta orden desde
  214. el árbol de construcción de Guix (@pxref{Ejecución de Guix antes de estar instalado}):
  215. @example
  216. ./pre-inst-env guix build gnuevo --keep-failed
  217. @end example
  218. El uso de @code{--keep-failed} facilita la depuración de errores de
  219. construcción ya que proporciona acceso al árbol de la construcción
  220. fallida. Otra opción útil de línea de órdenes para la depuración es
  221. @code{--log-file}, para acceder al log de construcción.
  222. Si el paquete resulta desconocido para la orden @command{guix}, puede ser
  223. que el fichero fuente contenga un error de sintaxis, o no tenga una cláusula
  224. @code{define-public} para exportar la variable del paquete. Para encontrar
  225. el problema puede cargar el módulo desde Guile para obtener más información
  226. sobre el error real:
  227. @example
  228. ./pre-inst-env guile -c '(use-modules (gnu packages gnuevo))'
  229. @end example
  230. Una vez que se construya correctamente su paquete, por favor, envíenos un
  231. parche (@pxref{Envío de parches}). En cualquier caso, si necesita ayuda
  232. también estaremos felices de ayudarle. Una vez el parche se haya incorporado
  233. al repositorio de Guix, el nuevo paquete se construye automáticamente en las
  234. plataformas disponibles por @url{http://hydra.gnu.org/jobset/gnu/master,
  235. nuestro sistema de integración continua}.
  236. @cindex servidor de sustituciones
  237. Las usuarias pueden obtener la nueva definición de paquete ejecutando
  238. simplemente @command{guix pull} (@pxref{Invocación de guix pull}). Cuando
  239. @code{@value{SUBSTITUTE-SERVER}} ha terminado de construir el paquete, la
  240. instalación del paquete descarga automáticamente los binarios desde allí
  241. (@pxref{Sustituciones}). El único lugar donde la intervención humana es
  242. necesaria es en la revisión y aplicación del parche.
  243. @menu
  244. * Libertad del software:: Qué puede entrar en la distribución.
  245. * Nombrado de paquetes:: ¿Qué hay en un nombre?
  246. * Versiones numéricas:: Cuando el nombre no es suficiente.
  247. * Sinopsis y descripciones:: Ayudar a las usuarias a encontrar el paquete
  248. adecuado.
  249. * Módulos Python:: Un toque de comedia británica.
  250. * Módulos Perl:: Pequeñas perlas.
  251. * Paquetes Java:: La parada del café.
  252. * Tipografías:: Amor por las letras.
  253. @end menu
  254. @node Libertad del software
  255. @subsection Libertad del software
  256. @c ===========================================================================
  257. @c
  258. @c This file was generated with po4a. Translate the source file.
  259. @c
  260. @c ===========================================================================
  261. @c Adapted from http://www.gnu.org/philosophy/philosophy.html.
  262. @cindex software libre
  263. El sistema operativo GNU se ha desarrollado para que las usuarias puedan
  264. ejercitar su libertad de computación. GNU es @dfn{software libre}, lo que
  265. significa ue las usuarias tienen las
  266. @url{http://www.gnu.org/philosophy/free-sw.html,cuatro libertades
  267. esenciales}: para ejecutar el programa, para estudiar y modificar el
  268. programa en la forma de código fuente, para redistribuir copias exactas y
  269. para distribuir versiones modificadas. Los paquetes encontrados en la
  270. distribución GNU proporcionan únicamente software que permite estas cuatro
  271. libertades.
  272. Además, la distribución GNU sigue las
  273. @url{http://www.gnu.org/distros/free-system-distribution-guidelines.html,directrices
  274. de distribución de software libre}. Entre otras cosas, estas directrices
  275. rechazan firmware no-libre, recomendaciones de software no-libre y el
  276. tratamiento de formas de tratar con marcas registradas y patentes.
  277. Algunos paquetes originales, que serían de otra manera software libre,
  278. contienen un subconjunto pequeño y opcional que viola estas directrices, por
  279. ejemplo debido a que ese subconjunto sea en sí código no-libre. Cuando esto
  280. sucede, las partes indeseadas son eliminadas con parches o fragmentos de
  281. código en la forma @code{origin} del paquete (@pxref{Definición de paquetes}). De
  282. este modo, @code{guix build --source} devuelve las fuentes ``liberadas'' en
  283. vez de la versión original de las fuentes.
  284. @node Nombrado de paquetes
  285. @subsection Nombrado de paquetes
  286. @cindex nombre de paquete
  287. Un paquete tiene realmente dos nombres asociados con él: Primero, el nombre
  288. de la @emph{variable Scheme} asociada, que aparece después de
  289. @code{define-public}. A través de este nombre, el paquete está disponible en
  290. código Scheme, por ejemplo como entrada de otro paquete. Segundo, la cadena
  291. en el campo @code{name} de la definición de paquete. Este nombre se usa por
  292. las órdenes de gestión de paquetes como @command{guix package} y
  293. @command{guix build}.
  294. Ambos normalmente son iguales y corresponden a la conversión a minúsculas
  295. del nombre de proyecto elegido por sus creadoras, con los guiones bajos
  296. sustituidos por guiones. Por ejemplo, GNUnet está disponible como
  297. @code{gnunet}, y SDL_net como @code{sdl-net}.
  298. No añadimos prefijos @code{lib} para paquetes de bibliotecas, a menos que
  299. sean parte del nombre oficial del proyecto. Pero vea @ref{Módulos Python} y
  300. @ref{Módulos Perl} para reglas especiales que conciernen a los módulos de
  301. los lenguajes Python y Perl.
  302. Los nombres de paquetes de tipografías se manejan de forma diferente,
  303. @pxref{Tipografías}.
  304. @node Versiones numéricas
  305. @subsection Versiones numéricas
  306. @cindex versión de paquete
  307. Normalmente empaquetamos únicamente la última versión de un proyecto dado de
  308. software libre. Pero a veces, por ejemplo para versiones de bibliotecas
  309. incompatibles, se necesitan dos (o más) versiones del mismo paquete. Estas
  310. necesitan nombres diferentes para las variables Scheme. Usamos el nombre
  311. como se define en @ref{Nombrado de paquetes} para la versión más reciente; las
  312. versiones previas usan el mismo nombre, añadiendo un @code{-} y el prefijo
  313. menor del número de versión que permite distinguir las dos versiones.
  314. El nombre dentro de la definición de paquete es el mismo para todas las
  315. versiones de un paquete y no contiene ningún número de versión.
  316. Por ejemplo, las versiones 2.24.20 y 3.9.12 de GTK+ pueden empaquetarse como
  317. sigue:
  318. @example
  319. (define-public gtk+
  320. (package
  321. (name "gtk+")
  322. (version "3.9.12")
  323. ...))
  324. (define-public gtk+-2
  325. (package
  326. (name "gtk+")
  327. (version "2.24.20")
  328. ...))
  329. @end example
  330. Si también deseásemos GTK+3.8.2, se empaquetaría como
  331. @example
  332. (define-public gtk+-3.8
  333. (package
  334. (name "gtk+")
  335. (version "3.8.2")
  336. ...))
  337. @end example
  338. @c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>,
  339. @c for a discussion of what follows.
  340. @cindex número de versión, para revisiones de VCS
  341. De manera ocasional, empaquetamos instantáneas del sistema de control de
  342. versiones (VCS) de las desarrolladoras originales en vez de publicaciones
  343. formales. Esto debería permanecer como algo excepcional, ya que son las
  344. desarrolladoras originales quienes deben clarificar cual es la entrega
  345. estable. No obstante, a veces es necesario. Por tanto, ¿qué deberíamos poner
  346. en el campo @code{version}?
  347. Claramente, tenemos que hacer visible el identificador de la revisión en el
  348. VCS en la cadena de versión, pero tamién debemos asegurarnos que la cadena
  349. de versión incrementa monotónicamente de manera que @command{guix package
  350. --upgrade} pueda determinar qué versión es más moderna. Ya que los
  351. identificadores de revisión, notablemente en Git, no incrementan
  352. monotónicamente, añadimos un número de revisión que se incrementa cada vez
  353. que actualizamos a una nueva instantánea. La versión que resulta debería ser
  354. así:
  355. @example
  356. 2.0.11-3.cabba9e
  357. ^ ^ ^
  358. | | `-- ID de revisión original
  359. | |
  360. | `--- revisión del paquete Guix
  361. |
  362. última versión de publicación
  363. @end example
  364. Es una buena idea recortar los identificadores de revisión en el campo
  365. @code{version} a, digamos, 7 dígitos. Esto evita una molestia estética
  366. (asumiendo que la estética tiene importancia aquí) así como problemas
  367. relacionados con los límites del sistema operativo como la longitud máxima
  368. de una cadena de ejecución #! (127 bytes en el núcleo Linux). Es mejor usar
  369. el identificador de revisión completo en @code{origin}, no obstante, para
  370. evitar ambigüedades. Una definición típica de paquete sería así:
  371. @example
  372. (define mi-paquete
  373. (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
  374. (revision "1")) ;Revisión Guix del paquete
  375. (package
  376. (version (git-version "0.9" revision commit))
  377. (source (origin
  378. (method git-fetch)
  379. (uri (git-reference
  380. (url "git://example.org/mi-paquete.git")
  381. (commit commit)))
  382. (sha256 (base32 "1mbikn@dots{}"))
  383. (file-name (git-file-name name version))))
  384. ;; @dots{}
  385. )))
  386. @end example
  387. @node Sinopsis y descripciones
  388. @subsection Sinopsis y descripciones
  389. @cindex descripción de paquete
  390. @cindex sinopsis de paquete
  391. Como hemos visto previamente, cada paquete en GNU@tie{}Guix incluye una
  392. sinopsis y una descripción (@pxref{Definición de paquetes}). Las sinopsis y
  393. descripciones son importantes: son en lo que @command{guix package --search}
  394. busca, y una pieza crucial de información para ayudar a las usuarias a
  395. determinar si un paquete dado cubre sus necesidades. Consecuentemente, las
  396. empaquetadoras deben prestar atención a qué se incluye en ellas.
  397. Las sinopsis deben empezar con mayúscula y no deben terminar con punto. No
  398. deben empezar con un artículo que habitualmente no aporta nada; por ejemplo,
  399. se prefiere ``Herramienta para chiribizar'' sobre ``Una herramienta que
  400. chiribiza ficheros''. La sinopsis debe decir qué es el paquete---por
  401. ejemplo, ``Utilidades básicas GNU (ficheros, texto, shell)''---o para qué se
  402. usa---por ejemplo, la sinopsis de GNU@tie{}grep es ``Imprime líneas que
  403. aceptadas por un patrón''.
  404. Tenga en cuenta que las sinopsis deben tener un claro significado para una
  405. audiencia muy amplia. Por ejemplo, ``Manipula la alineación en el formato
  406. SAM'' puede tener sentido para una investigadora de bioinformática con
  407. experiencia, pero puede ser de poca ayuda o incluso llevar a confusión a una
  408. audiencia no-especializada. Es una buena idea proporcionar una sinopsis que
  409. da una idea del dominio de aplicación del paquete. En ese ejemplo, esto
  410. podría ser algo como ``Manipula la alineación de secuencias de
  411. nucleótidos'', lo que esperablemente proporciona a la usuaria una mejor idea
  412. sobre si esto es lo que está buscando.
  413. Las descripciones deben tener entre cinco y diez líneas. Use frases
  414. completas, y evite usar acrónimos sin introducirlos previamente. Por favor
  415. evite frases comerciales como ``líder mundial'', ``de potencia industrial''
  416. y ``siguiente generación'', y evite superlativos como ``el más
  417. avanzado''---no son útiles para las usuarias que buscan un paquete e incluso
  418. pueden sonar sospechosas. En vez de eso, intente ceñirse a los hechos,
  419. mencionando casos de uso y características.
  420. @cindex marcado Texinfo, en descripciones de paquetes
  421. Las descripciones pueden incluir marcado Texinfo, lo que es útil para
  422. introducir ornamentos como @code{@@code} o @code{@@dfn}, listas de puntos o
  423. enlaces (@pxref{Overview,,, texinfo, GNU Texinfo}). Por consiguiente, debe
  424. ser cuidadosa cuando use algunos caracteres, por ejemplo @samp{@@} y llaves,
  425. que son los caracteres especiales básicos en Texinfo (@pxref{Special
  426. Characters,,, texinfo, GNU Texinfo}). Las interfaces de usuaria como
  427. @command{guix package --show} se encargan de su correcta visualización.
  428. Las sinopsis y descripciones son traducidas por voluntarias
  429. @uref{http://translationproject.org/domain/guix-packages.html, en
  430. Translation Project} para que todas las usuarias posibles puedan leerlas en
  431. su lengua nativa. Las interfaces de usuaria las buscan y las muestran en el
  432. idioma especificado por la localización actual.
  433. Para permitir a @command{xgettext} extraerlas como cadenas traducibles, las
  434. sinopsis y descripciones @emph{deben ser cadenas literales}. Esto significa
  435. que no puede usar @code{string-append} o @code{format} para construir estas
  436. cadenas:
  437. @lisp
  438. (package
  439. ;; @dots{}
  440. (synopsis "Esto es traducible")
  441. (description (string-append "Esto " "*no*" " es traducible.")))
  442. @end lisp
  443. La traducción requiere mucho trabajo, por lo que, como empaquetadora, le
  444. rogamos que ponga incluso más atención a sus sinopsis y descripciones ya que
  445. cada cambio puede suponer trabajo adicional para las traductoras. Para
  446. ayudarlas, es posible hacer recomendaciones o instrucciones insertando
  447. comentarios especiales como este (@pxref{xgettext Invocation,,, gettext, GNU
  448. Gettext}):
  449. @example
  450. ;; TRANSLATORS: "X11 resize-and-rotate" should not be translated.
  451. (description "ARandR is designed to provide a simple visual front end
  452. for the X11 resize-and-rotate (RandR) extension. @dots{}")
  453. @end example
  454. @node Módulos Python
  455. @subsection Módulos Python
  456. @cindex python
  457. Actualmente empaquetamos Python 2 y Python 3, bajo los nombres de variable
  458. Scheme @code{python-2} y @code{python} como se explica en @ref{Versiones numéricas}. Para evitar confusiones y conflictos de nombres con otros
  459. lenguajes de programación, parece deseable que el nombre de paquete para un
  460. módulo Python contenga la palabra @code{python}.
  461. Algunos módulos son compatibles únicamente con una versión de Python, otros
  462. con ambas. Si el paquete Foo compila sólo con Python 3, lo llamamos
  463. @code{python-foo}; si compila sólo con Python 2, lo llamamos
  464. @code{python2-foo}. Si es compatible con ambas versiones, creamos dos
  465. paquetes con los nombres correspondientes.
  466. Si un proyecto ya contiene la palabra @code{python}, la eliminamos; por
  467. ejemplo, el módulo python-dateutil se empaqueta con los nombres
  468. @code{python-dateutil} y @code{python2-dateutil}. Si el nombre del proyecto
  469. empieza con @code{py} (por ejemplo @code{pytz}), este se mantiene y el
  470. prefijo es el especificado anteriormente..
  471. @subsubsection Especificación de dependencias
  472. @cindex entradas, para paquetes Python
  473. La información de dependencias para paquetes Python está disponible
  474. habitualmente en el árbol de fuentes, con varios grados de precisión: en el
  475. fichero @file{setup.py}, en @file{requirements.txt} o en @file{tox.ini}.
  476. Su misión, cuando escriba una receta para un paquete Python, es asociar
  477. estas dependencias con el tipo apropiado de ``entrada'' (@pxref{Referencia de ``package'', inputs}). Aunque el importador de @code{pypi} normalmente hace un
  478. buen trabajo (@pxref{Invocación de guix import}), puede querer comprobar la
  479. siguiente lista para determinar qué dependencia va dónde.
  480. @itemize
  481. @item
  482. Actualmente empaquetamos con @code{setuptools} y @code{pip} instalados como
  483. Python 3.4 tiene por defecto. Por tanto no necesita especificar ninguno de
  484. ellos como entrada. @command{guix lint} le avisará si lo hace.
  485. @item
  486. Las dependencias Python requeridas en tiempo de ejecución van en
  487. @code{propagated-inputs}. Típicamente están definidas con la palabra clave
  488. @code{install_requires} en @file{setup.py}, o en el fichero
  489. @file{requirements.txt}.
  490. @item
  491. Los paquetes Python requeridos únicamente durante la construcción---por
  492. ejemplo, aquellos listados con la palabra clave @code{setup_requires} en
  493. @file{setup.py}---o únicamente para pruebas---por ejemplo, aquellos en
  494. @code{tests_require}---van en @code{native-inputs}. La razón es que (1) no
  495. necesitan ser propagados ya que no se requieren en tiempo de ejecución, y
  496. (2) en un entorno de compilación cruzada lo que necesitamos es la entrada
  497. ``nativa''.
  498. Ejemplos son las bibliotecas de pruebas @code{pytest}, @code{mock} y
  499. @code{nose}. Por supuesto, si alguno de estos paquetes también se necesita
  500. en tiempo de ejecución, necesita ir en @code{propagated-inputs}.
  501. @item
  502. Todo lo que no caiga en las categorías anteriores va a @code{inputs}, por
  503. ejemplo programas o bibliotecas C requeridas para construir los paquetes
  504. Python que contienen extensiones C.
  505. @item
  506. Si un paquete Python tiene dependencias opcionales (@code{extras_require}),
  507. queda en su mano decidir si las añade o no, en base a la relación
  508. utilidad/sobrecarga (@pxref{Envío de parches, @command{guix size}}).
  509. @end itemize
  510. @node Módulos Perl
  511. @subsection Módulos Perl
  512. @cindex perl
  513. Los programas ejecutables Perl se nombran como cualquier otro paquete,
  514. mediante el uso del nombre oficial en minúsculas. Para paquetes Perl que
  515. contienen una única clase, usamos el nombre en minúsculas de la clase,
  516. substituyendo todas las ocurrencias de @code{::} por guiones y agregando el
  517. prefijo @code{perl-}. Por tanto la clase @code{XML::Parser} se convierte en
  518. @code{perl-xml-parser}. Los módulos que contienen varias clases mantienen su
  519. nombre oficial en minúsculas y también se agrega @code{perl-} al
  520. inicio. Dichos módulos tienden a tener la palabra @code{perl} en alguna
  521. parte de su nombre, la cual se elimina en favor del prefijo. Por ejemplo,
  522. @code{libwww-perl} se convierte en @code{perl-libwww}.
  523. @node Paquetes Java
  524. @subsection Paquetes Java
  525. @cindex java
  526. Los programas Java ejecutables se nombran como cualquier otro paquete,
  527. mediante el uso del nombre oficial en minúsculas.
  528. Para evitar confusión y colisiones de nombres con otros lenguajes de
  529. programación, es deseable que el nombre del paquete para un paquete Java
  530. contenga el prefijo @code{java-}. Si el proyecto ya tiene la palabra
  531. @code{java}, eliminamos esta; por ejemplo, el paquete @code{ngsjaga} se
  532. empaqueta bajo el nombre @code{java-ngs}.
  533. Para los paquetes Java que contienen una clase única o una jerarquía
  534. pequeña, usamos el nombre de clase en minúsculas, substituyendo todas las
  535. ocurrencias de @code{.} por guiones y agregando el prefijo @code{java-}. Por
  536. tanto la clase @code{apache.commons.cli} se convierte en el paquete
  537. @code{java-apache-commons-cli}.
  538. @node Tipografías
  539. @subsection Tipografías
  540. @cindex tipografías
  541. Para tipografías que no se instalan generalmente por una usuaria para
  542. propósitos tipográficos, o que se distribuyen como parte de un paquete de
  543. software más grande, seguimos las reglas generales de empaquetamiento de
  544. software; por ejemplo, esto aplica a las tipografías distribuidas como parte
  545. del sistema X.Org o las tipografías que son parte de TeX Live.
  546. Para facilitar a las usuarias la búsqueda de tipografías, los nombres para
  547. otros paquetes que contienen únicamente tipografías se construyen como
  548. sigue, independientemente del nombre de paquete oficial.
  549. El nombre de un paquete que contiene únicamente una familia tipográfica
  550. comienza con @code{font-}; seguido por el nombre de la tipografía y un guión
  551. si la tipografía es conocida, y el nombre de la familia tipográfica, donde
  552. los espacios se sustituyen por guiones (y como es habitual, todas las letras
  553. mayúsculas se transforman a minúsculas). Por ejemplo, la familia de
  554. tipografías Gentium de SIL se empaqueta bajo el nombre de
  555. @code{font-sil-gentium}.
  556. Para un paquete que contenga varias familias tipográficas, el nombre de la
  557. colección se usa en vez del nombre de la familia tipográfica. Por ejemplo,
  558. las tipografías Liberation consisten en tres familias: Liberation Sans,
  559. Liberation Serif y Liberation Mono. Estas se podrían empaquetar por separado
  560. bajo los nombres @code{font-liberation-sans}, etcétera; pero como se
  561. distribuyen de forma conjunta bajo un nombre común, preferimos empaquetarlas
  562. conjuntamente como @code{font-liberation}.
  563. En el caso de que varios formatos de la misma familia o colección
  564. tipográfica se empaqueten de forma separada, una forma corta del formato,
  565. precedida por un guión, se añade al nombre del paquete. Usamos @code{-ttf}
  566. para tipografías TrueType, @code{-otf} para tipografías OpenType y
  567. @code{-type1} para tipografías Tipo 1 PostScript.
  568. @node Estilo de codificación
  569. @section Estilo de codificación
  570. En general nuestro código sigue los Estándares de codificación GNU
  571. (@pxref{Top,,, standards, GNU Coding Standards}). No obstante, no dicen
  572. mucho de Scheme, así que aquí están algunas reglas adicionales.
  573. @menu
  574. * Paradigma de programación:: Cómo componer sus elementos.
  575. * Módulos:: ¿Dónde almacenar su código?
  576. * Tipos de datos y reconocimiento de patrones:: Implementación de
  577. estructuras de datos.
  578. * Formato del código:: Convenciones de escritura.
  579. @end menu
  580. @node Paradigma de programación
  581. @subsection Paradigma de programación
  582. El código scheme en Guix está escrito en un estilo puramente funcional. Una
  583. excepción es el código que incluye entrada/salida, y procedimientos que
  584. implementan conceptos de bajo nivel, como el procedimiento @code{memoize}.
  585. @node Módulos
  586. @subsection Módulos
  587. Los módulos Guile que están destinados a ser usados en el lado del
  588. constructor deben encontrarse en el espacio de nombres @code{(guix build
  589. @dots{})}. No deben hacer referencia a otros módulos Guix o GNU. No
  590. obstante, no hay problema en usar un módulo del lado del constructor en un
  591. módulo ``del lado del cliente''.
  592. Los módulos que tratan con el sistema GNU más amplio deben estar en el
  593. espacio de nombres @code{(gnu @dots{})} en vez de en @code{(guix @dots{})}.
  594. @node Tipos de datos y reconocimiento de patrones
  595. @subsection Tipos de datos y reconocimiento de patrones
  596. La tendencia en el Lisp clásico es usar listas para representar todo, y
  597. recorrerlas ``a mano'' usando @code{car}, @code{cdr}, @code{cadr} y
  598. compañía. Hay varios problemas con este estilo, notablemente el hecho de que
  599. es difícil de leer, propenso a errores y una carga para informes adecuados
  600. de errores de tipado.
  601. El código de Guix debe definir tipos de datos apropiados (por ejemplo,
  602. mediante el uso @code{define-record-type*}) en vez de abusar de las
  603. listas. Además debe usarse el reconocimiento de patrones, vía el módulo de
  604. Guile @code{(ice-9 match)}, especialmente cuando se analizan listas.
  605. @node Formato del código
  606. @subsection Formato del código
  607. @cindex dar formato al código
  608. @cindex estilo de codificación
  609. Cuando escribimos código Scheme, seguimos la sabiduría común entre las
  610. programadoras Scheme. En general, seguimos las
  611. @url{http://mumble.net/~campbell/scheme/style.txt, Reglas de estilo Lisp de
  612. Riastradh}. Este documento resulta que también describe las convenciones más
  613. usadas en el código Guile. Está lleno de ideas y bien escrito, así que
  614. recomendamos encarecidamente su lectura.
  615. Algunas formas especiales introducidas en Guix, como el macro
  616. @code{substitute*} tienen reglas de indentación especiales. Estas están
  617. definidas en el fichero @file{.dir-locals.el}, el cual Emacs usa
  618. automáticamente. Fíjese que además Emacs-Guix proporciona el modo
  619. @code{guix-devel-mode} que indenta y resalta adecuadamente el código de Guix
  620. (@pxref{Desarrollo,,, emacs-guix, The Emacs-Guix Reference Manual}).
  621. @cindex indentación, de código
  622. @cindex formato, de código
  623. Si no usa Emacs, por favor asegúrese de que su editor conoce esas
  624. reglas. Para indentar automáticamente una definición de paquete también
  625. puede ejecutar:
  626. @example
  627. ./etc/indent-code.el gnu/packages/@var{fichero}.scm @var{paquete}
  628. @end example
  629. @noindent
  630. Esto indenta automáticamente la definición de @var{paquete} en
  631. @file{gnu/packages/@var{fichero}.scm} ejecutando Emacs en modo de
  632. procesamiento de lotes. Para indentar un fichero completo, omita el segundo
  633. parámetro:
  634. @example
  635. ./etc/indent-code.el gnu/services/@var{fichero}.scm
  636. @end example
  637. @cindex Vim, edición de código Scheme
  638. Si está editando código con Vim, le recomendamos ejecutar @code{:set
  639. autoindent} para que el código se indente automáticamente mientras
  640. escribe. Adicionalmente,
  641. @uref{https://www.vim.org/scripts/script.php?script_id=3998,
  642. @code{paredit.vim}} puede ayudar a manejar todos estos paréntesis.
  643. Requerimos que todos los procedimientos del nivel superior tengan una cadena
  644. de documentación. Este requisito puede relajarse para procedimientos simples
  645. privados en el espacio de nombres @code{(guix build @dots{})} no obstante.
  646. Los procedimientos no deben tener más de cuatro parámetros posicionales. Use
  647. parámetros con palabras clave para procedimientos que toman más de cuatro
  648. parámetros.
  649. @node Envío de parches
  650. @section Envío de parches
  651. El desarrollo se lleva a cabo usando el sistema de control de versiones
  652. distribuido Git. Por lo tanto, no es estrictamente necesario el acceso al
  653. repositorio. Son bienvenidas las contribuciones en forma de parches como los
  654. producidos por @code{git format-patch} enviadas a la lista de correo
  655. @email{guix-patches@@gnu.org}.
  656. Esta lista de correo está respaldada por una instancia de Debbugs accesible
  657. en @uref{https://bugs.gnu.org/guix-patches}, la cual nos permite mantener el
  658. seguimiento de los envíos. A cada mensaje enviado a esa lista de correo se
  659. le asigna un número de seguimiento; la gente puede realizar aportaciones
  660. sobre el tema mediante el envío de correos electrónicos a
  661. @code{@var{NNN}@@debbugs.gnu.org}, donde @var{NNN} es el número de
  662. seguimiento (@pxref{Envío de una serie de parches}).
  663. Le rogamos que escriba los mensajes de revisiones en formato ChangeLog
  664. (@pxref{Change Logs,,, standards, GNU Coding Standards}); puede comprobar la
  665. historia de revisiones en busca de ejemplos.
  666. Antes de enviar un parche que añade o modifica una definición de un paquete,
  667. por favor recorra esta lista de comprobaciones:
  668. @enumerate
  669. @item
  670. Si las autoras del paquete software proporcionan una firma criptográfica
  671. para el archivo de la versión, haga un esfuerzo para verificar la
  672. autenticidad del archivo. Para un fichero de firma GPG separado esto puede
  673. hacerse con la orden @code{gpg --verify}.
  674. @item
  675. Dedique algún tiempo a proporcionar una sinopsis y descripción adecuadas
  676. para el paquete. @xref{Sinopsis y descripciones}, para algunas directrices.
  677. @item
  678. Ejecute @code{guix lint @var{paquete}}, donde @var{paquete} es el nombre del
  679. paquete nuevo o modificado, y corrija cualquier error del que informe
  680. (@pxref{Invocación de guix lint}).
  681. @item
  682. Asegurese de que el paquete compile en su plataforma, usando @code{guix
  683. build @var{package}}.
  684. @item
  685. También le recomendamos que pruebe a construir el paquete en otras
  686. plataformas disponibles. Como puede no disponer de acceso a dichas
  687. plataformas hardware físicamente, le recomendamos el uso de
  688. @code{qemu-binfmt-service-type} para emularlas. Para activarlo, añada el
  689. siguiente servicio a la lista de servicios en su configuración
  690. @code{operating-system}:
  691. @example
  692. (service qemu-binfmt-service-type
  693. (qemu-binfmt-configuration
  694. (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el"))
  695. (guix-support? #t)))
  696. @end example
  697. Una vez hecho esto, reconfigure su sistema.
  698. Enotonces podrá construir paquetes para diferentes plataformas mediante la
  699. opción @code{--system}. Por ejemplo, para la construcción del paquete
  700. "hello" para las arquitecturas armhf, aarch64 o mips64 ejecutaría las
  701. siguientes órdenes, respectivamente:
  702. @example
  703. guix build --system=armhf-linux --rounds=2 hello
  704. guix build --system=aarch64-linux --rounds=2 hello
  705. guix build --system=mips64el-linux --rounds=2 hello
  706. @end example
  707. @item
  708. @cindex empaquetamientos
  709. Asegurese de que el paquete no usa copias empaquetadas de software ya
  710. disponible como paquetes separados.
  711. A veces, paquetes incluyen copias embebidas del código fuente de sus
  712. dependencias para conveniencia de las usuarias. No obstante, como
  713. distribución, queremos asegurar que dichos paquetes efectivamente usan la
  714. copia que ya tenemos en la distribución si hay ya una. Esto mejora el uso de
  715. recursos (la dependencia es construida y almacenada una sola vez), y permite
  716. a la distribución hacer cambios transversales como aplicar actualizaciones
  717. de seguridad para un software dado en un único lugar y que afecte a todo el
  718. sistema---algo que esas copias embebidas impiden.
  719. @item
  720. Eche un vistazo al perfil mostrado por @command{guix size} (@pxref{Invocación de guix size}). Esto le permitirá darse cuenta de referencias a otros paquetes
  721. retenidas involuntariamente. También puede ayudar a determinar si se debe
  722. dividir el paquete (@pxref{Paquetes con múltiples salidas}), y qué
  723. dependencias opcionales deben usarse. En particular, evite añadir
  724. @code{texlive} como una dependencia: debido a su tamaño extremo, use
  725. @code{texlive-tiny} o @code{texlive-union}.
  726. @item
  727. Para cambios importantes, compruebe que los paquetes dependientes (si
  728. aplica) no se ven afectados por el cambio; @code{guix refresh
  729. --list-dependent @var{package}} le ayudará a hacerlo (@pxref{Invocación de guix refresh}).
  730. @c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
  731. @cindex estrategia de ramas
  732. @cindex estrategia de planificación de reconstrucciones
  733. En base al número de paquetes dependientes y, por tanto, del tamaño de la
  734. reconstrucción inducida, los revisiones van a ramas separadas, según estas
  735. líneas:
  736. @table @asis
  737. @item 300 paquetes dependientes o menos
  738. rama @code{master} (cambios no disruptivos).
  739. @item entre 300 y 1.200 paquetes dependientes
  740. rama @code{staging} (cambios no disruptivos). Esta rama está pensada para
  741. ser incorporada en @code{master} cada 3 semanas más o menos. Ramas temáticas
  742. (por ejemplo, una actualización de la pila de GNOME) pueden ir en una rama
  743. específica (digamos, @code{gnome-updates}).
  744. @item más de 1.200 paquetes dependientes
  745. rama @code{core-updates} (puede incluir cambios mayores y potencialmente
  746. disruptivos). Esta rama está pensada para ser incluida en @code{master} cada
  747. 2,5 más o menos.
  748. @end table
  749. Todas estas ramas son @uref{https://hydra.gnu.org/project/gnu, seguidas por
  750. nuestra granja de construcción} e incluidas en @code{master} una vez todo se
  751. ha construido satisfactoriamente. Esto nos permite corregir errores antes de
  752. que afecten a usuarias, y reducir la ventana durante la cual los binarios
  753. preconstruidos no están disponibles.
  754. @c TODO: It would be good with badges on the website that tracks these
  755. @c branches. Or maybe even a status page.
  756. Generalmente, ramas distintas a @code{master} se consideran
  757. @emph{congeladas} si ha habido una evaluación reciente, o hay una rama
  758. @code{-next} correspondiente. Por favor, pregunte en la lista de correo o en
  759. IRC si no está segura de dónde colocar un parche.
  760. @item
  761. @cindex determinismo, del proceso de construcción
  762. @cindex construcciones reproducibles, comprobar
  763. Compruebe si el proceso de construcción de un paquete es determinista. Esto
  764. significa típicamente comprobar si una construcción independiente del
  765. paquete ofrece exactamente el mismo resultado que usted obtuvo, bit a bit.
  766. Una forma simple de hacerlo es construyendo el mismo paquete varias veces
  767. seguidas en su máquina (@pxref{Invocación de guix build}):
  768. @example
  769. guix build --rounds=2 mi-paquete
  770. @end example
  771. Esto es suficiente una clase común de problemas de no-determinismo, como las
  772. marcas de tiempo o salida generada aleatoriamente en el resultado de la
  773. construcción.
  774. Otra opción es el uso de @command{guix challenge} (@pxref{Invocación de guix challenge}). Puede ejecutarse una vez la revisión del paquete haya sido
  775. publicada y construida por @code{@value{SUBSTITUTE-SERVER}} para comprobar
  776. si obtuvo el mismo resultado que usted. Mejor aún: encuentre otra máquina
  777. que pueda construirla y ejecute @command{guix publish}. Ya que la máquina
  778. remota es probablemente diferente a la suya, puede encontrar problemas de
  779. no-determinismo relacionados con el hardware---por ejemplo, el uso de un
  780. conjunto de instrucciones extendido diferente---o con el núcleo del sistema
  781. operativo---por ejemplo, dependencias en @code{uname} o ficheros
  782. @file{/proc}.
  783. @item
  784. Cuando escriba documentación, por favor use construcciones neutrales de
  785. género para referirse a la gente@footnote{NdT: En esta traducción se ha
  786. optado por usar el femenino para referirse a @emph{personas}, ya que es el
  787. género gramatical de dicha palabra. Aunque las construcciones impersonales
  788. pueden adoptarse en la mayoría de casos, también pueden llegar a ser muy
  789. artificiales en otros usos del castellano; en ocasiones son directamente
  790. imposibles. Algunas construcciones que proponen la neutralidad de género
  791. dificultan la lecura automática (-x), o bien dificultan la corrección
  792. automática (-e), o bien aumentan significativamente la redundancia y reducen
  793. del mismo modo la velocidad en la lectura (-as/os, -as y -os). No obstante,
  794. la adopción del genero neutro heredado del latín, el que en castellano se ha
  795. unido con el masculino, como construcción neutral de género se considera
  796. inaceptable, ya que sería equivalente al ``it'' en inglés, nada más lejos de
  797. la intención de las autoras originales del texto.}, como
  798. @uref{https://en.wikipedia.org/wiki/Singular_they, singular ``they''@comma{}
  799. ``their''@comma{} ``them''} y demás.
  800. @item
  801. Compruebe que su parche contiene únicamente un conjunto relacionado de
  802. cambios. Agrupando cambios sin relación dificulta y ralentiza la revisión.
  803. Ejemplos de cambios sin relación incluyen la adición de varios paquetes, o
  804. una actualización de un paquete junto a correcciones a ese paquete.
  805. @item
  806. Por favor, siga nuestras reglas de formato de código, posiblemente
  807. ejecutando el guión @command{etc/indent-code.el} para que lo haga
  808. automáticamente por usted (@pxref{Formato del código}).
  809. @item
  810. Cuando sea posible, use espejos en la URL de las fuentes (@pxref{Invocación de guix download}). Use URL fiables, no generadas. Por ejemplo, los archivos de
  811. GitHub no son necesariamente idénticos de una generación a la siguiente, así
  812. que en este caso es normalmente mejor clonar el repositorio. No use el campo
  813. @command{name} en la URL: no es muy útil y si el nombre cambia, la URL
  814. probablemente estará mal.
  815. @end enumerate
  816. Cuando publique un parche a la lista de correo, use @samp{[PATCH] @dots{}}
  817. como el asunto. Puede usar su cliente de correo o la orden @command{git
  818. send-email} (@pxref{Envío de una serie de parches}). Preferimos recibir los parches
  819. en texto plano, ya sea en línea o como adjuntos MIME. Se le recomienda que
  820. preste atención por si su cliente de correo cambia algo como los saltos de
  821. línea o la indentación, lo que podría potencialmente romper los parches.
  822. Cuando un error es resuelto, por favor cierre el hilo enviando un correo a
  823. @email{@var{NNN}-done@@debbugs.gnu.org}.
  824. @unnumberedsubsec Envío de una serie de parches
  825. @anchor{Envío de una serie de parches}
  826. @cindex series de parches
  827. @cindex @code{git send-email}
  828. @cindex @code{git-send-email}
  829. @c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html
  830. Cuando envíe una serie de parches (por ejemplo, usando @code{git
  831. send-email}), por favor mande primero un mensaje a
  832. @email{guix-patches@@gnu.org}, y después mande los parches siguientes a
  833. @email{@var{NNN}@@debbugs.gnu.org} para asegurarse de que se mantienen
  834. juntos. Véase @uref{https://debbugs.gnu.org/Advanced.html, la documentación
  835. de Debbugs} para más información.