Lines Matching refs:el
8 Envío de parches: la guía esencial para incluir su código en el kernel
12 el proceso puede en ocasiones resultar desalentador si no se está
13 familiarizado con "el sistema". Este texto es una colección de sugerencias
19 funciona el proceso de desarrollo del kernel, consulte
35 Obtenga el código fuente actual
38 Si no tiene a mano un repositorio con el código fuente actual del kernel,
39 use ``git`` para obtener uno. Querrá comenzar con el repositorio principal,
45 el árbol principal directamente. La mayoría de los maintainers de
47 preparados para esos árboles. Revise el campo **T:** para el subsistema
48 en el archivo MAINTAINERS para encontrar dicho árbol, o simplemente
49 pregunte al maintainer si el árbol no está listado allí.
62 Describa el impacto relativo al usuario. Cosas que estropeen el kernel y
65 código, describa el impacto que cree pueda tener en los usuarios. Tenga en
80 optimización para que el revisor pueda comparar las perdidas con los
83 Una vez establecido el problema, describa lo que realmente está haciendo
84 al respecto en detalles técnicos. Es importante describir el cambio en
85 lenguaje sencillo para que el revisor verifique que el código se está
99 decir que esa es la versión N del parche (serie). No espere que el
101 referencias URL para encontrar la descripción del parche y colocarla en el
102 parche. Es decir, el parche (serie) y su descripción deben ser
113 referencia al ID SHA-1 del commit. Incluya también el resumen de una línea
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
139 enlace, utilice el contenido del encabezado ("header") ``Message-Id`` del
145 Verifique el enlace para asegurarse de que realmente funciona y apunta al
155 con los primeros 12 caracteres del ID SHA-1 y el resumen de una línea. No
185 el rendimiento de un controlador, separe esos cambios en dos o más parches.
202 asegurarse de que el kernel se compila y ejecuta correctamente después de
212 Revise el estilo en sus cambios
217 No hacerlo simplemente desperdicia el tiempo de los revisores y su parche
221 En tal caso, en absoluto debe modificar el código movido en el mismo parche
222 en que lo mueve. Esto divide claramente el acto de mover el código y sus
224 que las herramientas rastreen mejor el historial del código en sí.
226 Verifique sus parches con el verificador de estilo de parches antes de
227 enviarlos (scripts/checkpatch.pl). Tenga en cuenta, sin embargo, que el
245 MAINTAINERS y el historial de revisión del código fuente para ver quiénes
249 subsistema en el que está trabajando, Andrew Morton
254 usarse de forma predeterminada para todos los parches, pero el volumen en
255 esta lista ha hecho que muchos desarrolladores se desconecten. Busque en el
260 Muchas listas relacionadas con el kernel están alojadas en vger.kernel.org;
262 http://vger.kernel.org/vger-lists.html. Existen listas relacionadas con el
267 Linus Torvalds es el árbitro final de todos los cambios aceptados en el
276 poco de discreción y permitir que los distribuidores entreguen el parche a
277 los usuarios; en esos casos, obviamente, el parche no debe enviarse a
286 en el área de sign-off de su parche (es decir, NO un destinatario de correo
290 Si los cambios afectan las interfaces del kernel para el usuario, envíe al
291 maintainer de las MAN-PAGES (como se indica en el archivo MAINTAINERS) un
316 Tenga cuidado con el ajuste de palabras de su editor que corrompe su
319 No adjunte el parche como un archivo adjunto MIME, comprimido o no. Muchas
337 maneras en que se pueda mejorar el parche, en forma de respuesta a su
342 código deben casi con certeza generar un comentario o una entrada en el
343 "changelog" para que el próximo revisor entienda lo que está pasando.
367 Érase una vez, los parches solían desaparecer en el vacío sin comentarios,
368 pero el proceso de desarrollo funciona mejor que eso ahora. Debería
375 También está bien volver a enviar el parche o la serie de parches después
387 Incluya PATCH en el asunto
398 Firme su trabajo: el Certificado de Origen del Desarrollador
401 Para mejorar el seguimiento de quién hizo qué, especialmente con parches
418 indicada en el documento; o
422 abierto apropiada y tengo el derecho bajo esa licencia de
426 tal y como se indica en el documento; o
454 personas que manipulen y transporten el parche, pero no participaron en su
463 La etiqueta Signed-off-by: indica que el firmante estuvo involucrado en el
464 desarrollo del parche, o que él/ella se encontraba en el camino de entrega
472 Acked-by: a menudo lo usa el maintainer del código afectado cuando ese
473 maintainer no contribuyó ni envió el parche.
476 el "acker" ha revisado al menos ese parche y ha indicado su aceptación. Por
477 los merge de parches a veces convertirán manualmente el "sí, me parece bien"
481 Acked-by: no necesariamente indica el reconocimiento de todo el parche.
484 indica el reconocimiento de solo la parte que afecta el código de ese
492 fue copiada en el parche. Esta etiqueta documenta que las partes
495 Co-developed-by: establece que el parche fue co-creado por múltiples
500 coautor asociado. Se mantiene el procedimiento estándar, es decir, el orden
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
504 Signed-off-by: siempre debe ser del desarrollador que envía el parche.
506 Tenga en cuenta que la etiqueta From: es opcional cuando el autor From: es
510 Ejemplo de un parche enviado por el From: autor::
541 Una etiqueta Tested-by: indica que el parche se probó con éxito (en algún
544 "testers" (gente que pruebe) otros parches futuros y asegura el crédito
547 Reviewed-by: en cambio, indica que el parche ha sido revisado y encontrado
557 el kernel principal.
559 (b) Cualquier problema, inquietud o pregunta relacionada con el parche
568 (d) Si bien he revisado el parche y creo que es correcto,
573 Una etiqueta Reviewed-by es una declaración de opinión de que el parche es
575 a nivel técnico. Cualquier revisor interesado (que haya hecho el trabajo)
578 revisión que se ha hecho en el parche. Las etiquetas Reviewed-by, cuando
581 parche entre en el kernel.
584 correo por el tester o revisor, deben ser incluidas por el autor de los
585 parches pertinentes al enviar próximas versiones. Sin embargo, si el parche
589 Reviewed-by de alguien en el registro de cambios del parche (después del
593 persona nombrada y asegura el crédito a la persona por la idea. Tenga en
594 cuenta que esto no debe agregarse sin el permiso del "reporter",
597 sentirán inspirados para ayudarnos nuevamente en el futuro.
599 Una etiqueta Fixes: indica que el parche corrige un problema en un commit
603 versiones estables del kernel deberían recibir su corrección. Este es el
604 método preferido para indicar un error corregido por el parche. Revise
608 proceso del kernel ni el requisito de CC: stable@vger.kernel.org en todos
618 cuenta que, si tiene sus parches almacenados en un repositorio ``git``, el
620 herramientas no pueden crear el texto necesario, sin embargo, así que lea
629 - Una línea ``from`` que especifica el autor del parche, seguida de una
630 línea vacía (solo es necesario si la persona que envía el parche no es
631 el autor).
634 copiara en el registro de cambios permanente para describir este parche.
639 también vaya en el registro de cambios.
643 - Cualquier comentario adicional que no sea adecuado para el registro de
650 lector de correo electrónico permite esto, ya que debido a que el número de
651 secuencia se rellena con ceros, el orden numérico y alfabético es el mismo.
653 El ``subsistema`` en el asunto del correo electrónico debe identificar qué
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
665 hasta el registro de cambios de ``git``. La ``frase resumida`` se puede
673 Por estas razones, el ``resumen`` no debe tener más de 70-75 caracteres, y
674 debe describir tanto lo que cambia el parche como por qué el parche podría
681 cómo debería ser tratado el parche. Las etiquetas comunes pueden incluir un
688 desarrolladores entiendan el orden en que se deben aplicar los parches y
694 Asunto: [PATCH v2 27/01] x86: corregir el seguimiento de eflags
698 La línea ``from`` debe ser la primera línea en el cuerpo del mensaje,
703 La línea ``From`` especifica quién será acreditado como el autor del parche
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.
708 La explicación estará incluida en el commit del changelog permanente, por
711 este parche. Incluidos los síntomas del fallo que el parche trate
716 pueda dar al lector la información necesaria y detalles para comprender el
717 razonamiento de **por qué** se creó el parche.
721 que sea probable que alguien que busque el parche puede encontrarlo. 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
730 para ``diffstat``, para mostrar qué archivos han cambiado, y el número de
739 Otros comentarios relevantes solo en el momento o para el maintainer, pero
740 no adecuados para el registro de cambios permanente, también debe ir aquí.
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
750 debajo de la línea de separación, se quita automáticamente al aplicar el
763 Revise más detalles sobre el formato de parche adecuado en las siguientes
771 Los "backtraces" (deshacer el camino) ayuda a documentar la cadena de
780 centrarse en el verdadero tema. Este es un ejemplo de un backtrace bien
796 (por ejemplo, al usar ``git send-email``) para asociar el parche con una
798 errores al correo electrónico con el informe de errores. Sin embargo, para
803 útil, puede usar el redirector https://lore.kernel.org/ (por ejemplo, en
804 el texto de la carta de introducción del correo electrónico) para vincular
811 Cuando otros desarrolladores reciben sus parches y comienzan el proceso de
815 establecer la calidad de su envío antes de que el maintainer comience la
819 incluir automáticamente la información del árbol base en su envío usando el
835 cuenta que tendrá el tráiler ``base-commit:`` al final, que proporciona al
853 el mismo tráiler ``base-commit`` para indicar el hash de confirmación del
855 o en el primer parche de la serie y debe colocarse ya sea bajo la línea