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 kernel.org;
262 https://subspace.kernel.org. Existen listas relacionadas con el kernel
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.
365 discusiones sobre el desarrollo del kernel de Linux. Las respuestas
374 A: Porque desordena el orden en el que la gente normalmente lee el texto.
375 Q: ¿Por qué es tan malo el top-posting?
395 Érase una vez, los parches solían desaparecer en el vacío sin comentarios,
396 pero el proceso de desarrollo funciona mejor que eso ahora. Debería
403 También está bien volver a enviar el parche o la serie de parches después
415 Incluya PATCH en el asunto
426 Firme su trabajo: el Certificado de Origen del Desarrollador
429 Para mejorar el seguimiento de quién hizo qué, especialmente con parches
446 indicada en el documento; o
450 abierto apropiada y tengo el derecho bajo esa licencia de
454 tal y como se indica en el documento; o
482 personas que manipulen y transporten el parche, pero no participaron en su
491 La etiqueta Signed-off-by: indica que el firmante estuvo involucrado en el
492 desarrollo del parche, o que él/ella se encontraba en el camino de entrega
500 Acked-by: a menudo lo usa el maintainer del código afectado cuando ese
501 maintainer no contribuyó ni envió el parche.
504 el "acker" ha revisado al menos ese parche y ha indicado su aceptación. Por
505 los merge de parches a veces convertirán manualmente el "sí, me parece bien"
509 Acked-by: no necesariamente indica el reconocimiento de todo el parche.
512 indica el reconocimiento de solo la parte que afecta el código de ese
520 fue copiada en el parche. Esta etiqueta documenta que las partes
523 Co-developed-by: establece que el parche fue co-creado por múltiples
528 coautor asociado. Se mantiene el procedimiento estándar, es decir, el orden
529 de las etiquetas Signed-off-by: debe reflejar el historial cronológico del
530 parche en la medida de lo posible, independientemente de si el autor se
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.
534 Tenga en cuenta que la etiqueta From: es opcional cuando el autor From: es
538 Ejemplo de un parche enviado por el From: autor::
569 Una etiqueta Tested-by: indica que el parche se probó con éxito (en algún
572 "testers" (gente que pruebe) otros parches futuros y asegura el crédito
575 Reviewed-by: en cambio, indica que el parche ha sido revisado y encontrado
585 el kernel principal.
587 (b) Cualquier problema, inquietud o pregunta relacionada con el parche
596 (d) Si bien he revisado el parche y creo que es correcto,
601 Una etiqueta Reviewed-by es una declaración de opinión de que el parche es
603 a nivel técnico. Cualquier revisor interesado (que haya hecho el trabajo)
606 revisión que se ha hecho en el parche. Las etiquetas Reviewed-by, cuando
609 parche entre en el kernel.
612 correo por el tester o revisor, deben ser incluidas por el autor de los
613 parches pertinentes al enviar próximas versiones. Sin embargo, si el parche
617 Reviewed-by de alguien en el registro de cambios del parche (después del
621 persona nombrada y asegura el crédito a la persona por la idea. Tenga en
622 cuenta que esto no debe agregarse sin el permiso del "reporter",
625 sentirán inspirados para ayudarnos nuevamente en el futuro.
627 Una etiqueta Fixes: indica que el parche corrige un problema en un commit
631 versiones estables del kernel deberían recibir su corrección. Este es el
632 método preferido para indicar un error corregido por el parche. Revise
636 proceso del kernel ni el requisito de CC: stable@vger.kernel.org en todos
646 cuenta que, si tiene sus parches almacenados en un repositorio ``git``, el
648 herramientas no pueden crear el texto necesario, sin embargo, así que lea
657 - Una línea ``from`` que especifica el autor del parche, seguida de una
658 línea vacía (solo es necesario si la persona que envía el parche no es
659 el autor).
662 copiara en el registro de cambios permanente para describir este parche.
667 también vaya en el registro de cambios.
671 - Cualquier comentario adicional que no sea adecuado para el registro de
678 lector de correo electrónico permite esto, ya que debido a que el número de
679 secuencia se rellena con ceros, el orden numérico y alfabético es el mismo.
681 El ``subsistema`` en el asunto del correo electrónico debe identificar qué
684 La ``frase de resumen`` en el Asunto del correo electrónico debe describir
685 de forma concisa el parche que contiene ese correo electrónico. La
693 hasta el registro de cambios de ``git``. La ``frase resumida`` se puede
701 Por estas razones, el ``resumen`` no debe tener más de 70-75 caracteres, y
702 debe describir tanto lo que cambia el parche como por qué el parche podría
709 cómo debería ser tratado el parche. Las etiquetas comunes pueden incluir un
716 desarrolladores entiendan el orden en que se deben aplicar los parches y
722 Asunto: [PATCH v2 27/01] x86: corregir el seguimiento de eflags
726 La línea ``from`` debe ser la primera línea en el cuerpo del mensaje,
731 La línea ``From`` especifica quién será acreditado como el autor del parche
732 en el registro de cambios permanente. Si falta la línea ``from``, entonces
734 determinar el autor del parche en el registro de cambios.
736 La explicación estará incluida en el commit del changelog permanente, por
739 este parche. Incluidos los síntomas del fallo que el parche trate
744 pueda dar al lector la información necesaria y detalles para comprender el
745 razonamiento de **por qué** se creó el parche.
749 que sea probable que alguien que busque el parche puede encontrarlo. Como
753 La línea marcadora ``---`` cumple el propósito esencial de marcar para
754 herramientas de manejo de parches donde termina el mensaje de registro de
758 para ``diffstat``, para mostrar qué archivos han cambiado, y el número de
767 Otros comentarios relevantes solo en el momento o para el maintainer, pero
768 no adecuados para el registro de cambios permanente, también debe ir aquí.
774 separa el registro de cambios del resto del parche. La información de la
775 versión no forma parte del registro de cambios que se incluye con el árbol
778 debajo de la línea de separación, se quita automáticamente al aplicar el
791 Revise más detalles sobre el formato de parche adecuado en las siguientes
799 Los "backtraces" (deshacer el camino) ayuda a documentar la cadena de
808 centrarse en el verdadero tema. Este es un ejemplo de un backtrace bien
824 (por ejemplo, al usar ``git send-email``) para asociar el parche con una
826 errores al correo electrónico con el informe de errores. Sin embargo, para
831 útil, puede usar el redirector https://lore.kernel.org/ (por ejemplo, en
832 el texto de la carta de introducción del correo electrónico) para vincular
839 Cuando otros desarrolladores reciben sus parches y comienzan el proceso de
843 establecer la calidad de su envío antes de que el maintainer comience la
847 incluir automáticamente la información del árbol base en su envío usando el
863 cuenta que tendrá el tráiler ``base-commit:`` al final, que proporciona al
881 el mismo tráiler ``base-commit`` para indicar el hash de confirmación del
883 o en el primer parche de la serie y debe colocarse ya sea bajo la línea