Lines Matching +full:un +full:-
1 .. include:: ../disclaimer-sp.rst
3 :Original: :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
11 Para una persona o empresa que desee enviar un cambio al kernel Linux,
17 Este documento contiene una gran cantidad de sugerencias en un formato
20 Documentation/process/development-process.rst. Además, lea
21 Documentation/process/submit-checklist.rst para obtener una lista de
24 Documentation/devicetree/bindings/submitting-patches.rst.
33 :ref:`Documentation/process/maintainer-handbooks.rst <maintainer_handbooks_main>`.
36 --------------------------------
38 Si no tiene a mano un repositorio con el código fuente actual del kernel,
54 ---------------------
56 Describa su problema. Sea su parche una corrección de un error de una
57 línea o 5000 líneas para una nuevo "feature", debe haber un problema
59 hay un problema que merece la pena solucionar y de que tiene sentido que
64 evidentes. Incluso si se detectó un problema durante la revisión del
68 que seleccionan ("cherry-pick") solo parches específicos de upstream, así
77 Las optimizaciones generalmente no son gratuitas, sino un equilibrio entre
88 El maintainer le agradecerá que escriba la descripción de su parche en un
90 del sistema, ``git``, como un "commit log" (registros de los commits).
93 Resuelva solo un problema por parche. Si su descripción comienza a ser muy
97 Cuando envíe o vuelva a enviar un parche o una serie de parches, incluya la
112 Si desea hacer referencia a un commit específico, no se limite a hacer
113 referencia al ID SHA-1 del commit. Incluya también el resumen de una línea
123 del identificador SHA-1. El repositorio del kernel contiene muchos *muchos*
131 apunten a estos. En caso de que su parche corrija un error, por poner un
133 los archivos de las listas de correo o un rastreador de errores; si el
139 enlace, utilice el contenido del encabezado ("header") ``Message-Id`` del
149 externos. Además de dar una URL a un archivo o error de la lista de correo,
153 Si su parche corrige un error en un commit específico, por ejemplo
154 encontró un problema usando ``git bisect``, utilice la etiqueta 'Fixes:'
155 con los primeros 12 caracteres del ID SHA-1 y el resumen de una línea. No
164 agregar un bonito formato y generar este estilo con los comandos
172 Un ejemplo de uso::
174 $ git log -1 --pretty=fixes 54a4f0239f2e
180 -------------------
182 Separe cada **cambio lógico** en un parche separado.
185 el rendimiento de un controlador, separe esos cambios en dos o más parches.
189 Por otro lado, si realiza un solo cambio en numerosos archivos, agrupe esos
190 cambios en un solo parche. Por lo tanto, un solo cambio lógico estará
191 contenido en un solo parche.
193 El punto a recordar es que cada parche debe realizar un cambio que puede
197 Si un parche depende de otro parche para que un cambio sea completo, eso
204 para rastrear un problema pueden terminar dividiendo su serie de parches en
207 Si no puede condensar su conjunto de parches en un conjunto más pequeño de
213 --------------------------------
216 detalles pueden ser encontrados en Documentation/process/coding-style.rst.
220 Una excepción importante es cuando se mueve código de un archivo a otro.
228 verificador de estilo debe ser visto como una guía, no como un reemplazo
233 - ERROR: cosas que es muy probable que estén mal
234 - WARNING: Advertencia. Cosas que requieren una revisión cuidadosa
235 - CHECK: Revisar. Cosas que requieren pensarlo
241 ------------------------------------------
248 scripts/get_maintainer.pl). Si no puede encontrar un maintainer del
250 (akpm@linux-foundation.org) sirve como maintainer de último recurso.
253 una copia de su conjunto de parches. linux-kernel@vger.kernel.org debe
261 puedes encontrar un listado de estas en
262 http://vger.kernel.org/vger-lists.html. Existen listas relacionadas con el
269 <torvalds@linux-foundation.org>. Recibe muchos correos electrónicos y, en
271 normalmente debe hacer todo lo posible para -evitar- enviarle un correo
274 Si tiene un parche que corrige un error de seguridad explotable, envíe ese
275 parche a security@kernel.org. Para errores graves, se debe mantener un
279 Documentation/process/security-bugs.rst.
281 Los parches que corrigen un error grave en un kernel en uso deben dirigirse
286 en el área de sign-off de su parche (es decir, NO un destinatario de correo
288 Documentation/process/stable-kernel-rules.rst además de este documento.
291 maintainer de las MAN-PAGES (como se indica en el archivo MAINTAINERS) un
295 linux-api@vger.kernel.org.
299 --------------------------------------------------------------------
302 los cambios que está enviando. Es importante para un desarrollador kernel
308 "inline". La forma más sencilla de hacerlo es con ``git send-email``, que
309 es muy recomendable. Un tutorial interactivo para ``git send-email`` está
310 disponible en https://git-send-email.io.
312 Si elige no usar ``git send-email``:
319 No adjunte el parche como un archivo adjunto MIME, comprimido o no. Muchas
320 populares aplicaciones de correo electrónico no siempre transmiten un MIME
322 en su código. Linus también necesita un poco más de tiempo para procesar un
329 Consulte Documentation/process/email-clients.rst para obtener sugerencias
334 ---------------------------------------
341 Revisiones a los comentarios o preguntas que no conduzcan a un cambio de
342 código deben casi con certeza generar un comentario o una entrada en el
346 agradecerles que dediquen su tiempo. La revisión del código es un proceso
349 que hayan señalado. Al enviar un siguiente versión, agregue un
355 Consulte Documentation/process/email-clients.rst para obtener
362 -----------------------------------------------------------------------------------
373 Q: ¿Dónde puedo encontrar información sobre esto que se llama top-posting?
375 Q: ¿Por qué es tan malo el top-posting?
376 A: Top-posting.
390 ---------------------------
398 asegúrese de que ha enviado sus parches al lugar correcto. Espere un mínimo
404 de un par de semanas con la palabra "RESEND" (reenviar) añadida a la línea
410 serie de parches: "RESEND" solo se aplica al reenvío de un parche o serie
416 --------------------------
423 ``git send-email`` lo hará automáticamente.
427 ------------------------------------------------------------
431 maintainers, hemos introducido un procedimiento de "sign-off" (aprobación)
435 que certifica que usted lo escribió o que tiene derecho a enviarlo como un
461 son públicos y que un registro de la contribución (incluyendo
469 Signed-off-by: Random J Developer <random@developer.example.org>
472 anónimas). Esto se hará por usted automáticamente si usa ``git commit -s``.
473 Las reversiones de código también deben incluir "Signed-off-by".
474 ``git revert -s`` hace eso por usted.
481 Cualquier otro SoB (Signed-off-by:) después del SoB del autor es de
485 la primera entrada de SoB que señala la autoría principal de un solo autor.
488 Cuándo usar Acked-by:, Cc: y Co-developed-by por:
489 -------------------------------------------------
491 La etiqueta Signed-off-by: indica que el firmante estuvo involucrado en el
496 administración de un parche pero desea expresar y registrar su aprobación,
497 entonces puede pedir que se agregue una línea Acked-by: al registro de
500 Acked-by: a menudo lo usa el maintainer del código afectado cuando ese
503 Acked-by: no es tan formal como Signed-off-by:. Es una manera de marcar que
506 de un acker en un Acked-by: (pero tenga en cuenta que por lo general es
507 mejor pedir un acuse de recibo explícito).
509 Acked-by: no necesariamente indica el reconocimiento de todo el parche.
510 Por ejemplo, si un parche afecta a varios subsistemas y tiene un
511 Acked-by: de un maintainer del subsistema, entonces esto generalmente
516 Si una persona ha tenido la oportunidad de comentar un parche, pero no lo
519 parte de la persona a la que se nombre - pero debe indicar que esta persona
523 Co-developed-by: establece que el parche fue co-creado por múltiples
526 un solo parche. Ya que Co-developed-by: denota autoría, cada
527 Co-developed-by: debe ser inmediatamente seguido de Signed-off-by: del
529 de las etiquetas Signed-off-by: debe reflejar el historial cronológico del
531 atribuye a través de From: o Co-developed-by:. Cabe destacar que el último
532 Signed-off-by: siempre debe ser del desarrollador que envía el parche.
538 Ejemplo de un parche enviado por el From: autor::
542 Co-developed-by: Primer coautor <primer@coauthor.example.org>
543 Signed-off-by: Primer coautor <primer@coauthor.example.org>
544 Co-developed-by: Segundo coautor <segundo@coautor.ejemplo.org>
545 Signed-off-by: Segundo coautor <segundo@coautor.ejemplo.org>
546 Signed-off-by: Autor del From <from@author.example.org>
548 Ejemplo de un parche enviado por un Co-developed-by: autor::
554 Co-developed-by: Co-Autor aleatorio <aleatorio@coauthor.example.org>
555 Signed-off-by: Coautor aleatorio <aleatorio@coauthor.example.org>
556 Signed-off-by: Autor del From <from@author.example.org>
557 Co-developed-by: Coautor que envió <sub@coauthor.example.org>
558 Signed-off-by: Coautor que envía <sub@coauthor.example.org>
560 Uso de Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: y Fixes:
561 ----------------------------------------------------------------------
563 La etiqueta Reported-by (Reportado-por) otorga crédito a las personas que
565 informó de un error en privado, debe pedir primero permiso antes de usar la
566 etiqueta Reported-by. La etiqueta está destinada a errores; por favor no la
569 Una etiqueta Tested-by: indica que el parche se probó con éxito (en algún
571 de que se han realizado algunas pruebas, proporciona un medio para ubicar
575 Reviewed-by: en cambio, indica que el parche ha sido revisado y encontrado
581 Al ofrecer mi etiqueta Reviewed-by:, afirmo que:
601 Una etiqueta Reviewed-by es una declaración de opinión de que el parche es
604 puede ofrecer una etiqueta Reviewed-by para un parche. Esta etiqueta sirve
606 revisión que se ha hecho en el parche. Las etiquetas Reviewed-by, cuando
611 Las etiquetas Tested-by y Reviewed-by, una vez recibidas en la lista de
616 general, se debe mencionar la eliminación de las etiquetas Tested-by o
617 Reviewed-by de alguien en el registro de cambios del parche (después del
618 separador '---').
620 Una etiqueta Suggested-by: indica que la idea del parche es sugerida por la
623 especialmente si la idea no fue publicada en un foro público. Dicho esto,
627 Una etiqueta Fixes: indica que el parche corrige un problema en un commit
628 anterior. Esto se utiliza para facilitar descubrir dónde se originó un
632 método preferido para indicar un error corregido por el parche. Revise
638 Documentation/process/stable-kernel-rules.rst.
643 ---------------------------
646 cuenta que, si tiene sus parches almacenados en un repositorio ``git``, el
647 parche con formato adecuado se puede obtener con ``git format-patch``. Las
657 - Una línea ``from`` que especifica el autor del parche, seguida de una
661 - El cuerpo de la explicación, línea envuelta en 75 columnas, que se
664 - Una línea vacía.
666 - Las líneas ``Signed-off-by:``, descritas anteriormente, que
669 - Una línea de marcador que contiene simplemente ``---``.
671 - Cualquier comentario adicional que no sea adecuado para el registro de
674 - El parche real (output de ``diff``).
677 electrónicos alfabéticamente por línea de asunto - prácticamente cualquier
686 ``frase resumen`` no debe ser un nombre de archivo. No use la mismo ``frase
692 convierte en un identificador global único para ese parche. Se propaga por
699 --oneline``.
701 Por estas razones, el ``resumen`` no debe tener más de 70-75 caracteres, y
703 ser necesario. Es un reto ser tanto sucinto como descriptivo, pero eso es
704 lo que un resumen bien escrito debería hacer.
709 cómo debería ser tratado el parche. Las etiquetas comunes pueden incluir un
737 lo que debería tener sentido para un lector competente que hace mucho tiempo
747 Si un parche corrige una falla de compilación, puede que no sea necesario
753 La línea marcadora ``---`` cumple el propósito esencial de marcar para
757 Un buen uso de los comentarios adicionales después del marcador ``---`` es
759 líneas insertadas y eliminadas por archivo. Un ``diffstat`` es
760 especialmente útil en parches más grandes. Si va a incluir un ``diffstat``
761 después del marcador ``---``, utilice las opciones ``diffstat``
762 ``-p 1 -w 70`` para que los nombres de archivo se enumeran desde la parte
769 Un buen ejemplo de tales comentarios podría ser ``registros de cambios de
773 Por favor, ponga esta información **después** de la línea ``---`` que
783 Signed-off-by: Autor <autor@correo>
784 ---
785 V2 -> V3: función auxiliar redundante eliminada
786 V1 -> V2: estilo de código limpio y comentarios de revisión abordados
788 ruta/al/archivo | 5+++--
800 llamadas que conducen a un problema. Sin embargo, no todos los rastreos son
808 centrarse en el verdadero tema. Este es un ejemplo de un backtrace bien
820 In-Reply-To explicitos en las cabeceras
821 ---------------------------------------
823 Puede ser útil agregar manualmente encabezados In-Reply-To: a un parche
824 (por ejemplo, al usar ``git send-email``) para asociar el parche con una
828 In-Reply-To: para vincular a versiones anteriores de la serie. De esta
829 forma, varias versiones del parche no se convierten en un inmanejable
830 bosque de referencias en clientes de correo electrónico. Si un enlace es
837 --------------------------------------
846 Si está utilizando ``git format-patch`` para generar sus parches, puede
848 parámetro ``--base``. La forma más fácil y conveniente de usar esta opción
851 $ git checkout -t -b my-topical-branch master
852 Branch 'my-topical-branch' set up to track local branch 'master'.
853 Switched to a new branch 'my-topical-branch'
857 $ git format-patch --base=auto --cover-letter -o outgoing/ master
858 outgoing/0000-cover-letter.patch
859 outgoing/0001-First-Commit.patch
862 Cuando abra ``outgoing/0000-cover-letter.patch`` para editar, tenga en
863 cuenta que tendrá el tráiler ``base-commit:`` al final, que proporciona al
867 $ git checkout -b patch-review [base-commit-id]
868 Switched to a new branch 'patch-review'
873 Consulte ``man git-format-patch`` para obtener más información al respecto
878 La función ``--base`` se introdujo en la versión 2.9.0 de git.
881 el mismo tráiler ``base-commit`` para indicar el hash de confirmación del
884 ``---`` o en la parte inferior de todos los demás contenido, justo antes de
889 -----------
895 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
897 "How to piss off a kernel subsystem maintainer" por Greg Kroah-Hartman.
900 <http://www.kroah.com/log/linux/maintainer-02.html>
902 <http://www.kroah.com/log/linux/maintainer-03.html>
904 <http://www.kroah.com/log/linux/maintainer-04.html>
906 <http://www.kroah.com/log/linux/maintainer-05.html>
908 <http://www.kroah.com/log/linux/maintainer-06.html>
910 NO!!!! Gente, no mas bombas enormes de parches a linux-kernel@vger.kernel.org!
913 Kernel Documentation/process/coding-style.rst
922 http://halobates.de/on-submitting-patches.pdf