Lines Matching refs:de
8 Envío de parches: la guía esencial para incluir su código en el kernel
13 familiarizado con "el sistema". Este texto es una colección de sugerencias
14 que pueden aumentar considerablemente las posibilidades de que se acepte su
17 Este documento contiene una gran cantidad de sugerencias en un formato
19 funciona el proceso de desarrollo del kernel, consulte
21 Documentation/process/submit-checklist.rst para obtener una lista de
22 elementos a verificar antes de enviar código. Para los parches de
23 "binding" del árbol de dispositivos, lea
31 Algunos subsistemas y árboles de mantenimiento cuentan con información
32 adicional sobre su flujo de trabajo y expectativas, consulte
45 el árbol principal directamente. La mayoría de los maintainers de
46 subsistemas usan sus propios árboles de código fuente y quieren ver parches
56 Describa su problema. Sea su parche una corrección de un error de una
58 subyacente que le motivó a hacer ese trabajo. Convenza al revisor de que
59 hay un problema que merece la pena solucionar y de que tiene sentido que
66 cuenta que la mayoría de instalaciones de Linux ejecutan kernels desde
67 árboles estables secundarios o árboles específicos de proveedor/producto
68 que seleccionan ("cherry-pick") solo parches específicos de upstream, así
70 aguas abajo: circunstancias que producen cierta situación, extractos de
71 dmesg, descripciones del error fatal, regresiones de rendimiento, picos de
75 rendimiento, consumo de memoria, huella del stack o tamaño de binario,
78 CPU, memoria y legibilidad; o, cuando se trata de heurísticas, entre
79 diferentes cargas de trabajo. Describa las desventajas esperadas de su
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).
94 larga, eso es una señal de que probablemente necesite dividir su parche.
97 Cuando envíe o vuelva a enviar un parche o una serie de parches, incluya la
100 maintainer del subsistema referencie versiones de parches anteriores o use
108 haga frotz" en lugar de "[Este parche] hace que xyzzy haga frotz" o "[Yo]
113 referencia al ID SHA-1 del commit. Incluya también el resumen de una línea
114 del commit, para que sea más fácil para los revisores saber de qué se
122 También debe asegurarse de utilizar al menos los primeros doce caracteres
126 identificación de seis caracteres ahora, esa condición puede cambiar dentro
127 de cinco años.
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
134 parche es el resultado de alguna discusión anterior de la lista de correo o
137 Cuando se vincule a archivos de listas de correo, preferiblemente use el
138 servicio de archivador de mensajes lore.kernel.org. Para crear la URL del
145 Verifique el enlace para asegurarse de que realmente funciona y apunta al
149 externos. Además de dar una URL a un archivo o error de la lista de correo,
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
156 divida la etiqueta en varias líneas, las etiquetas están exentas de la
157 regla "ajustar a 75 columnas" para simplificar análisis de scripts. Por
161 devuelva la cantidad de páginas que realmente liberó")
163 Las siguientes configuraciones de ``git config`` se pueden usar para
172 Un ejemplo de uso::
175 …Fixes: 54a4f0239f2e ("KVM: MMU: hacer que kvm_mmu_zap_page() devuelva la cantidad de páginas que r…
184 Por ejemplo, si sus cambios incluyen correcciones de errores y mejoras en
185 el rendimiento de un controlador, separe esos cambios en dos o más parches.
186 Si sus cambios incluyen una actualización de la API y una nueva controlador
197 Si un parche depende de otro parche para que un cambio sea completo, eso
199 en la descripción de su parche.
201 Cuando divida su cambio en una serie de parches, tenga especial cuidado en
202 asegurarse de que el kernel se compila y ejecuta correctamente después de
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
215 Revise su parche para ver si hay violaciones de estilo básico, cuyos
217 No hacerlo simplemente desperdicia el tiempo de los revisores y su parche
220 Una excepción importante es cuando se mueve código de un archivo a otro.
222 en que lo mueve. Esto divide claramente el acto de mover el código y sus
223 cambios. Esto ayuda mucho a la revisión de la diferencias reales y permite
226 Verifique sus parches con el verificador de estilo de parches antes de
228 verificador de estilo debe ser visto como una guía, no como un reemplazo
240 Seleccione los destinatarios de su parche
245 MAINTAINERS y el historial de revisión del código fuente para ver quiénes
250 (akpm@linux-foundation.org) sirve como maintainer de último recurso.
252 Normalmente, también debe elegir al menos una lista de correo para recibir
253 una copia de su conjunto de parches. linux-kernel@vger.kernel.org debe
254 usarse de forma predeterminada para todos los parches, pero el volumen en
256 archivo MAINTAINERS una lista específica de los subsistemas; su parche
261 puedes encontrar un listado de estas en
265 ¡No envíe más de 15 parches a la vez a las listas de correo de vger!
267 Linus Torvalds es el árbitro final de todos los cambios aceptados en el
268 kernel de Linux. Su dirección de correo electrónico es
274 Si tiene un parche que corrige un error de seguridad explotable, envíe ese
276 poco de discreción y permitir que los distribuidores entreguen el parche a
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
292 parche de páginas de manual, o al menos una notificación del cambio, para
294 de la API del espacio de usuario también deben copiarse en
303 poder "citar" sus cambios, utilizando herramientas estándar de correo
304 electrónico, de modo que puedan comentar sobre partes específicas de su
308 "inline". La forma más sencilla de hacerlo es con ``git send-email``, que
316 Tenga cuidado con el ajuste de palabras de su editor que corrompe su
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
323 archivo adjunto MIME, disminuyendo la probabilidad de que se acepte su
326 Excepción: si su proveedor de correo está destrozando parches, entonces
330 sobre cómo configurar su cliente de correo electrónico para que envíe sus
333 Responda a los comentarios de revisión
336 Es casi seguro que su parche recibirá comentarios de los revisores sobre
337 maneras en que se pueda mejorar el parche, en forma de respuesta a su
339 revisores es una buena manera de ser ignorado de vuelta. Simplemente puede
341 Revisiones a los comentarios o preguntas que no conduzcan a un cambio de
345 Asegúrese de decirles a los revisores qué cambios está haciendo y de
347 agotador y lento, y los revisores a veces se ponen de mal humor. Sin
350 ``patch changelog`` (registro de cambios en los parches) a la carta de
356 recomendaciones sobre clientes de correo electrónico y normas de etiqueta
357 en la lista de correo.
364 Después de haber entregado su cambio, sea paciente y espere. Los revisores
365 son personas ocupadas y es posible que no lleguen a su parche de inmediato.
368 pero el proceso de desarrollo funciona mejor que eso ahora. Debería
369 recibir comentarios dentro de una semana más o menos; si eso no sucede,
370 asegúrese de que ha enviado sus parches al lugar correcto. Espere un mínimo
371 de una semana antes de volver a enviar o hacer ping a los revisores,
372 posiblemente más durante periodos de mucho trabajo ocupados como "merge
375 También está bien volver a enviar el parche o la serie de parches después
376 de un par de semanas con la palabra "RESEND" (reenviar) añadida a la línea
377 de asunto::
379 [PATCH Vx RESEND] sub/sys: Resumen condensado de parche
381 No incluya "RESEND" cuando envíe una versión modificada de su parche o
382 serie de parches: "RESEND" solo se aplica al reenvío de un parche o serie
383 de parches que no hayan sido modificados de ninguna manera con respecto a
390 Debido al alto tráfico de correo electrónico a Linus y al kernel de Linux,
391 es común prefijar su línea de asunto con [PATCH]. Esto le permite a Linus
392 y otros desarrolladores del kernel distinguir más fácilmente los parches de
398 Firme su trabajo: el Certificado de Origen del Desarrollador
401 Para mejorar el seguimiento de quién hizo qué, especialmente con parches
402 que pueden filtrarse hasta su destino final a través de varias capas de
403 maintainers, hemos introducido un procedimiento de "sign-off" (aprobación)
406 La aprobación es una simple línea al final de la explicación del parche,
408 parche de código abierto. Las reglas son bastante simples: si usted puede
411 Certificado de Origen del Desarrollador 1.1
417 tengo derecho a enviarlo bajo la licencia de código abierto
421 soy consciente, está cubierto por una licencia de código
422 abierto apropiada y tengo el derecho bajo esa licencia de
424 totalidad o en parte por mí, bajo la misma licencia de código
433 son públicos y que un registro de la contribución (incluyendo
436 de manera consistente con este proyecto o la(s) licencia(s) de
445 Las reversiones de código también deben incluir "Signed-off-by".
450 internos de su empresa o simplemente señalar algún detalle especial sobre
453 Cualquier otro SoB (Signed-off-by:) después del SoB del autor es de
455 desarrollo. Las cadenas de SoB deben reflejar la ruta **real** del parche
456 de cómo se propagó a los maintainers y, en última instancia, a Linus, con
457 la primera entrada de SoB que señala la autoría principal de un solo autor.
464 desarrollo del parche, o que él/ella se encontraba en el camino de entrega
468 administración de un parche pero desea expresar y registrar su aprobación,
469 entonces puede pedir que se agregue una línea Acked-by: al registro de
475 Acked-by: no es tan formal como Signed-off-by:. Es una manera de marcar que
477 los merge de parches a veces convertirán manualmente el "sí, me parece bien"
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).
481 Acked-by: no necesariamente indica el reconocimiento de todo el parche.
483 Acked-by: de un maintainer del subsistema, entonces esto generalmente
484 indica el reconocimiento de solo la parte que afecta el código de ese
485 maintainer. Buen juicio debe ejercitarse aquí. En caso de duda, la gente
486 debe consultar la discusión original en los archivos de la lista de correo.
488 Si una persona ha tenido la oportunidad de comentar un parche, pero no lo
491 parte de la persona a la que se nombre - pero debe indicar que esta persona
499 Co-developed-by: debe ser inmediatamente seguido de Signed-off-by: del
501 de las etiquetas Signed-off-by: debe reflejar el historial cronológico del
502 parche en la medida de lo posible, independientemente de si el autor se
503 atribuye a través de From: o Co-developed-by:. Cabe destacar que el último
510 Ejemplo de un parche enviado por el From: autor::
520 Ejemplo de un parche enviado por un Co-developed-by: autor::
532 Uso de Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: y Fixes:
537 informó de un error en privado, debe pedir primero permiso antes de usar la
539 use para acreditar peticiones de características.
543 de que se han realizado algunas pruebas, proporciona un medio para ubicar
548 aceptable de acuerdo con la Declaración del Revisor:
550 Declaración de Supervisión del Revisor
555 (a) He llevado a cabo una revisión técnica de este parche para
565 modificación valiosa al kernel, y (2) libre de conocidas
566 cuestiones que argumentarían en contra de su inclusión.
570 garantía o avales de que logrará su definido
573 Una etiqueta Reviewed-by es una declaración de opinión de que el parche es
577 para dar crédito a revisores e informar a los maintainers del grado de
580 revisiones exhaustivas, normalmente aumentan la probabilidad de que su
583 Las etiquetas Tested-by y Reviewed-by, una vez recibidas en la lista de
584 correo por el tester o revisor, deben ser incluidas por el autor de los
588 general, se debe mencionar la eliminación de las etiquetas Tested-by o
589 Reviewed-by de alguien en el registro de cambios del parche (después del
596 si diligentemente acreditamos a los reporters de ideas, con suerte, se
601 error, lo que puede ayudar a revisar una corrección de errores. Esta
608 proceso del kernel ni el requisito de CC: stable@vger.kernel.org en todos
609 los parches candidatos de ramas estables. Para obtener más información, lea
614 Formato de parche canónico
621 las instrucciones a continuación de todos modos.
623 La línea de asunto del parche canónico es::
625 Asunto: [PATCH 001/123] subsistema: frase de resumen
629 - Una línea ``from`` que especifica el autor del parche, seguida de una
633 - El cuerpo de la explicación, línea envuelta en 75 columnas, que se
634 copiara en el registro de cambios permanente para describir este parche.
639 también vaya en el registro de cambios.
641 - Una línea de marcador que contiene simplemente ``---``.
643 - Cualquier comentario adicional que no sea adecuado para el registro de
646 - El parche real (output de ``diff``).
648 El formato de la línea de asunto hace que sea muy fácil ordenar los correos
649 electrónicos alfabéticamente por línea de asunto - prácticamente cualquier
650 lector de correo electrónico permite esto, ya que debido a que el número de
656 La ``frase de resumen`` en el Asunto del correo electrónico debe describir
657 de forma concisa el parche que contiene ese correo electrónico. La
658 ``frase resumen`` no debe ser un nombre de archivo. No use la mismo ``frase
659 resumen`` para cada parche en una serie completa de parches (donde una
660 `` serie de parches`` (patch series) es una secuencia ordenada de múltiples
663 Tenga en cuenta que la ``frase de resumen`` de su correo electrónico se
665 hasta el registro de cambios de ``git``. La ``frase resumida`` se puede
666 usar más adelante en discusiones de desarrolladores que se refieran al
667 parche. La gente querrá buscar en Google la ``frase de resumen`` para leer
670 quizás miles de parches usando herramientas como ``gitk`` o ``git log
673 Por estas razones, el ``resumen`` no debe tener más de 70-75 caracteres, y
678 La ``frase de resumen`` puede estar precedida por etiquetas encerradas en
679 corchetes: "Asunto: [PATCH <etiqueta>...] <frase de resumen>". Las
680 etiquetas no se consideran parte de la frase de resumen, pero describen
682 descriptor de versión si las múltiples versiones del parche se han enviado
684 una solicitud de comentarios.
686 Si hay cuatro parches en una serie de parches, los parches individuales
689 que han revisado o aplicado todos los parches de la serie de parches.
691 Aquí hay algunos buenos ejemplos de Asuntos::
693 Asunto: [PATCH 2/5] ext2: mejorar la escalabilidad de la búsqueda de mapas de bits
694 Asunto: [PATCH v2 27/01] x86: corregir el seguimiento de eflags
704 en el registro de cambios permanente. Si falta la línea ``from``, entonces
706 determinar el autor del parche en el registro de cambios.
710 ha olvidado los detalles de la discusión que podrían haber llevado a
712 (mensajes de registro del kernel, mensajes de oops, etc.) son especialmente
713 útiles para personas que podrían estar buscando en los registros de
714 commits en busca de la aplicación del parche. El texto debe estar escrito
717 razonamiento de **por qué** se creó el parche.
719 Si un parche corrige una falla de compilación, puede que no sea necesario
720 incluir _todos_ los errores de compilación; pero lo suficiente como para
722 en la ``frase de resumen``, es importante ser tanto sucinto como
725 La línea marcadora ``---`` cumple el propósito esencial de marcar para
726 herramientas de manejo de parches donde termina el mensaje de registro de
729 Un buen uso de los comentarios adicionales después del marcador ``---`` es
730 para ``diffstat``, para mostrar qué archivos han cambiado, y el número de
734 ``-p 1 -w 70`` para que los nombres de archivo se enumeran desde la parte
735 superior del árbol de fuentes del kernel y no use demasiado espacio
740 no adecuados para el registro de cambios permanente, también debe ir aquí.
741 Un buen ejemplo de tales comentarios podría ser ``registros de cambios de
745 Por favor, ponga esta información **después** de la línea ``---`` que
746 separa el registro de cambios del resto del parche. La información de la
747 versión no forma parte del registro de cambios que se incluye con el árbol
748 git. Es información adicional para los revisores. Si se coloca encima de la
749 etiquetas de commit, necesita interacción manual para eliminarlo. Si esta
750 debajo de la línea de separación, se quita automáticamente al aplicar el
753 <mensaje de commit>
758 V1 -> V2: estilo de código limpio y comentarios de revisión abordados
763 Revise más detalles sobre el formato de parche adecuado en las siguientes
768 Retrocesos en mensajes de confirmación
771 Los "backtraces" (deshacer el camino) ayuda a documentar la cadena de
773 útiles. Por ejemplo, las tempranas cadenas de llamadas de inicio son únicas
774 y obvias. Sin embargo, al copiar la salida completa de dmesg textualmente,
775 incluye información que distrae, como marcas de tiempo, listas de módulos,
776 registro y volcados de pila.
779 relevantes de la información vertida, lo que hace que sea más fácil
780 centrarse en el verdadero tema. Este es un ejemplo de un backtrace bien
783 error de acceso de MSR no verificado: WRMSR a 0xd51 (intentó escribir 0x0000000000000064)
785 Rastreo de llamadas:
797 discusión anterior relevante, por ejemplo para vincular una corrección de
798 errores al correo electrónico con el informe de errores. Sin embargo, para
799 una serie de parches múltiples, generalmente es mejor evitar usar
800 In-Reply-To: para vincular a versiones anteriores de la serie. De esta
802 bosque de referencias en clientes de correo electrónico. Si un enlace es
804 el texto de la carta de introducción del correo electrónico) para vincular
805 a una versión anterior de la serie de parches.
808 Proporcionar información de árbol base
811 Cuando otros desarrolladores reciben sus parches y comienzan el proceso de
814 automatizado de procesos que intentan ejecutar una serie de pruebas para
815 establecer la calidad de su envío antes de que el maintainer comience la
820 parámetro ``--base``. La forma más fácil y conveniente de usar esta opción
821 es con "topical branches" (ramas de temas)::
836 revisor y a las herramientas de CI suficiente información para realizar
846 de esta opción.
850 La función ``--base`` se introdujo en la versión 2.9.0 de git.
853 el mismo tráiler ``base-commit`` para indicar el hash de confirmación del
854 árbol en que se basa su trabajo. Debe agregarlo en la carta de presentación
855 o en el primer parche de la serie y debe colocarse ya sea bajo la línea
856 ``---`` o en la parte inferior de todos los demás contenido, justo antes de
882 NO!!!! Gente, no mas bombas enormes de parches a linux-kernel@vger.kernel.org!
887 Email de Linus Torvalds sobre la forma canónica de los parches:
894 http://halobates.de/on-submitting-patches.pdf