sp_SP/process/submitting-patches.rst

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
38 Si no tiene a mano un repositorio con el código fuente actual del kernel,
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
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
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
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:'
164 agregar un bonito formato y generar este estilo con los comandos
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
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
248 scripts/get_maintainer.pl). Si no puede encontrar un maintainer del
261 puedes encontrar un listado de estas 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
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
291 maintainer de las MAN-PAGES (como se indica en el archivo MAINTAINERS) un
302 los cambios que está enviando. Es importante para un desarrollador kernel
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
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
370 asegúrese de que ha enviado sus parches al lugar correcto. Espere un mínimo
376 de un par de semanas con la palabra "RESEND" (reenviar) añadida a la línea
382 serie de parches: "RESEND" solo se aplica al reenvío de un parche o serie
403 maintainers, hemos introducido un procedimiento de "sign-off" (aprobación)
407 que certifica que usted lo escribió o que tiene derecho a enviarlo como un
433             son públicos y que un registro de la contribución (incluyendo
457 la primera entrada de SoB que señala la autoría principal de un solo autor.
468 administración de un parche pero desea expresar y registrar su aprobación,
478 de un acker en un Acked-by: (pero tenga en cuenta que por lo general es
479 mejor pedir un acuse de recibo explícito).
482 Por ejemplo, si un parche afecta a varios subsistemas y tiene un
483 Acked-by: de un maintainer del subsistema, entonces esto generalmente
488 Si una persona ha tenido la oportunidad de comentar un parche, pero no lo
498 un solo parche. Ya que Co-developed-by: denota autoría, cada
510 Ejemplo de un parche enviado por el From: autor::
520 Ejemplo de un parche enviado por un Co-developed-by: autor::
537 informó de un error en privado, debe pedir primero permiso antes de usar la
543 de que se han realizado algunas pruebas, proporciona un medio para ubicar
576 puede ofrecer una etiqueta Reviewed-by para un parche. Esta etiqueta sirve
595 especialmente si la idea no fue publicada en un foro público. Dicho esto,
599 Una etiqueta Fixes: indica que el parche corrige un problema en un commit
600 anterior. Esto se utiliza para facilitar descubrir dónde se originó un
604 método preferido para indicar un error corregido por el parche. Revise
618 cuenta que, si tiene sus parches almacenados en un repositorio ``git``, el
658 ``frase resumen`` no debe ser un nombre de archivo. No use la mismo ``frase
664 convierte en un identificador global único para ese parche. Se propaga por
675 ser necesario. Es un reto ser tanto sucinto como descriptivo, pero eso es
676 lo que un resumen bien escrito debería hacer.
681 cómo debería ser tratado el parche. Las etiquetas comunes pueden incluir un
709 lo que debería tener sentido para un lector competente que hace mucho tiempo
719 Si un parche corrige una falla de compilación, puede que no sea necesario
732 especialmente útil en parches más grandes. Si va a incluir un ``diffstat``
772 llamadas que conducen a un problema. Sin embargo, no todos los rastreos son
780 centrarse en el verdadero tema. Este es un ejemplo de un backtrace bien
795 Puede ser útil agregar manualmente encabezados In-Reply-To: a un parche
801 forma, varias versiones del parche no se convierten en un inmanejable
802 bosque de referencias en clientes de correo electrónico. Si un enlace es