Lines Matching +full:x +full:- +full:tal
1 .. include:: ../disclaimer-sp.rst
3 :Original: :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
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 --------------------------------
54 ---------------------
68 que seleccionan ("cherry-pick") solo parches específicos de upstream, así
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*
139 enlace, utilice el contenido del encabezado ("header") ``Message-Id`` del
150 resuma los puntos relevantes de la discusión que condujeron al parche tal y
155 con los primeros 12 caracteres del ID SHA-1 y el resumen de una línea. No
174 $ git log -1 --pretty=fixes 54a4f0239f2e
180 -------------------
198 está bien. Simplemente incluya que **"este parche depende del parche X"**
213 --------------------------------
216 detalles pueden ser encontrados en Documentation/process/coding-style.rst.
221 En tal caso, en absoluto debe modificar el código movido en el mismo parche
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 ------------------------------------------
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
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
279 Documentation/process/security-bugs.rst.
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 --------------------------------------------------------------------
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``:
329 Consulte Documentation/process/email-clients.rst para obtener sugerencias
334 ---------------------------------------
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 ---------------------------
416 --------------------------
423 ``git send-email`` lo hará automáticamente.
427 ------------------------------------------------------------
431 maintainers, hemos introducido un procedimiento de "sign-off" (aprobación)
451 presentar tal trabajo con modificaciones, ya sean creadas en su
454 tal y como se indica en el documento; o
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
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
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
509 Acked-by: no necesariamente indica el reconocimiento de todo el parche.
511 Acked-by: de un maintainer del subsistema, entonces esto generalmente
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.
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
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
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
638 Documentation/process/stable-kernel-rules.rst.
643 ---------------------------
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
699 --oneline``.
701 Por estas razones, el ``resumen`` no debe tener más de 70-75 caracteres, y
743 con tal detalle que cuando se lea semanas, meses o incluso años después,
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
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
764 horizontal (que encaje fácilmente en 80 columnas, tal vez con alguna
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+++--
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
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