Lines Matching refs:en
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á
17 Este documento contiene una gran cantidad de sugerencias en un formato
28 usarlo, le hará la vida como desarrollador del kernel y en general mucho
44 Tenga en cuenta, sin embargo, que es posible que no desee desarrollar con
48 en el archivo MAINTAINERS para encontrar dicho árbol, o simplemente
65 código, describa el impacto que cree pueda tener en los usuarios. Tenga en
74 Cuantifique optimizaciones y beneficios/perdidas. Si asegura mejoras en
84 al respecto en detalles técnicos. Es importante describir el cambio en
88 El maintainer le agradecerá que escriba la descripción de su parche en un
89 formato que se pueda incorporar fácilmente en la gestión del código fuente
101 referencias URL para encontrar la descripción del parche y colocarla en el
107 Describa sus cambios en la forma imperativa, por ejemplo, "hacer que xyzzy
108 haga frotz" en lugar de "[Este parche] hace que xyzzy haga frotz" o "[Yo]
125 posibilidad real. Tenga en cuenta que, aunque no hay colisión con su
130 cambio se pueden encontrar en la web, agregue las etiquetas 'Link:' que
132 ejemplo, agregue una etiqueta con una URL que haga referencia al informe en
135 algo documentado en la web, referencie esto.
153 Si su parche corrige un error en un commit específico, por ejemplo
156 divida la etiqueta en varias líneas, las etiquetas están exentas de la
182 Separe cada **cambio lógico** en un parche separado.
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.
187 que usa esta nueva API, sepárelos en dos 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.
199 en la descripción de su parche.
201 Cuando divida su cambio en una serie de parches, tenga especial cuidado en
203 cada parche en la serie. Los desarrolladores que usan ``git bisect``
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
212 Revise el estilo en sus cambios
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
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í.
227 enviarlos (scripts/checkpatch.pl). Tenga en cuenta, sin embargo, que el
237 Debe poder justificar todas las violaciones que permanezcan en su parche.
243 Siempre debe incluir en copia a los apropiados maintainers del subsistema
244 en cualquier parche con código que mantengan; revise a través del archivo
247 útil en este paso (pase rutas a sus parches como argumentos para
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;
261 puedes encontrar un listado de estas en
263 kernel alojadas en otros lugares, no obstante.
267 Linus Torvalds es el árbitro final de todos los cambios aceptados en el
269 <torvalds@linux-foundation.org>. Recibe muchos correos electrónicos y, en
277 los usuarios; en esos casos, obviamente, el parche no debe enviarse a
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
293 que alguna información se abra paso en las páginas del manual. Los cambios
294 de la API del espacio de usuario también deben copiarse en
310 disponible en https://git-send-email.io.
322 en su código. Linus también necesita un poco más de tiempo para procesar un
324 cambio adjunto en MIME.
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
348 embargo, incluso en ese caso, responda cortésmente y aborde los problemas
350 ``patch changelog`` (registro de cambios en los parches) a la carta de
357 en la lista de correo.
367 Érase una vez, los parches solían desaparecer en el vacío sin comentarios,
387 Incluya PATCH en el asunto
404 en parches que se envían por correo electrónico.
416 (a) La contribución fue creada en su totalidad o en parte por mí y
418 indicada en el documento; o
420 (b) La contribución se basa en trabajo previo que, hasta donde yo
423 presentar tal trabajo con modificaciones, ya sean creadas en su
424 totalidad o en parte por mí, bajo la misma licencia de código
426 tal y como se indica en el documento; o
454 personas que manipulen y transporten el parche, pero no participaron en su
456 de cómo se propagó a los maintainers y, en última instancia, a Linus, con
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
467 Si una persona no estuvo directamente involucrada en la preparación o
478 de un acker en un Acked-by: (pero tenga en cuenta que por lo general es
486 debe consultar la discusión original en los archivos de la lista de correo.
492 fue copiada en el parche. Esta etiqueta documenta que las partes
493 potencialmente interesadas han sido incluidas en la discusión.
497 autor atribuido por la etiqueta From:) cuando varias personas trabajan en
502 parche en la medida de lo posible, independientemente de si el autor se
506 Tenga en cuenta que la etiqueta From: es opcional cuando el autor From: es
507 también la persona (y correo electrónico) enumerados en la línea From: del
536 encuentran errores y los reportan. Por favor, tenga en cuenta que si se
537 informó de un error en privado, debe pedir primero permiso antes de usar la
541 Una etiqueta Tested-by: indica que el parche se probó con éxito (en algún
547 Reviewed-by: en cambio, indica que el parche ha sido revisado y encontrado
556 evaluar su idoneidad y preparación para su inclusión en
564 entrega, creo que es, en este momento, (1) una
566 cuestiones que argumentarían en contra de su inclusión.
569 no hago (a menos que se indique explícitamente en otro lugar) ninguna
571 propósito o función en cualquier situación dada.
578 revisión que se ha hecho en el parche. Las etiquetas Reviewed-by, cuando
581 parche entre en el kernel.
583 Las etiquetas Tested-by y Reviewed-by, una vez recibidas en la lista de
586 ha cambiado sustancialmente en la siguiente versión, es posible que estas
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
595 especialmente si la idea no fue publicada en un foro público. Dicho esto,
597 sentirán inspirados para ayudarnos nuevamente en el futuro.
599 Una etiqueta Fixes: indica que el parche corrige un problema en un commit
608 proceso del kernel ni el requisito de CC: stable@vger.kernel.org en todos
617 Esta sección describe cómo debe darse formato al propio parche. Tenga en
618 cuenta que, si tiene sus parches almacenados en un repositorio ``git``, el
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.
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
659 resumen`` para cada parche en una serie completa de parches (donde una
663 Tenga en cuenta que la ``frase de resumen`` de su correo electrónico se
664 convierte en un identificador global único para ese parche. Se propaga por
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
678 La ``frase de resumen`` puede estar precedida por etiquetas encerradas en
683 en respuesta a comentarios (es decir, "v1, v2, v3") o "RFC" para indicar
686 Si hay cuatro parches en una serie de parches, los parches individuales
688 desarrolladores entiendan el orden en que se deben aplicar los parches y
698 La línea ``from`` debe ser la primera línea en el cuerpo del mensaje,
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
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
722 en la ``frase de resumen``, es importante ser tanto sucinto como
732 especialmente útil en parches más grandes. Si va a incluir un ``diffstat``
736 horizontal (que encaje fácilmente en 80 columnas, tal vez con alguna
739 Otros comentarios relevantes solo en el momento o para el maintainer, pero
763 Revise más detalles sobre el formato de parche adecuado en las siguientes
768 Retrocesos en mensajes de confirmación
780 centrarse en el verdadero tema. Este es un ejemplo de un backtrace bien
784 en rIP: 0xffffffffae059994 (native_write_msr+0x4/0x20)
792 In-Reply-To explicitos en las cabeceras
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
803 útil, puede usar el redirector https://lore.kernel.org/ (por ejemplo, en
812 revisión, a menudo es útil para ellos saber en qué parte del historial del
819 incluir automáticamente la información del árbol base en su envío usando el
834 Cuando abra ``outgoing/0000-cover-letter.patch`` para editar, tenga en
850 La función ``--base`` se introdujo en la versión 2.9.0 de git.
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