Lines Matching full: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
131 apunten a estos. En caso de que su parche corrija un error, por poner un
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.
361 Uso de respuestas intercaladas recortadas en las discusiones por correo electrónico
364 Se desaconseja encarecidamente la publicación en la parte superior de las
366 intercaladas (o "en línea") hacen que las conversaciones sean mucho más
368 https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
370 Como se cita frecuentemente en la lista de correo::
372 A: http://en.wikipedia.org/wiki/Top_post
374 A: Porque desordena el orden en el que la gente normalmente lee el texto.
395 Érase una vez, los parches solían desaparecer en el vacío sin comentarios,
415 Incluya PATCH en el asunto
432 en parches que se envían por correo electrónico.
444 (a) La contribución fue creada en su totalidad o en parte por mí y
446 indicada en el documento; o
448 (b) La contribución se basa en trabajo previo que, hasta donde yo
451 presentar tal trabajo con modificaciones, ya sean creadas en su
452 totalidad o en parte por mí, bajo la misma licencia de código
454 tal y como se indica en el documento; o
482 personas que manipulen y transporten el parche, pero no participaron en su
484 de cómo se propagó a los maintainers y, en última instancia, a Linus, con
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
495 Si una persona no estuvo directamente involucrada en la preparación o
506 de un acker en un Acked-by: (pero tenga en cuenta que por lo general es
513 maintainer. Buen juicio debe ejercitarse aquí. En caso de duda, la gente
514 debe consultar la discusión original en los archivos de la lista de correo.
520 fue copiada en el parche. Esta etiqueta documenta que las partes
521 potencialmente interesadas han sido incluidas en la discusión.
525 autor atribuido por la etiqueta From:) cuando varias personas trabajan en
530 parche en la medida de lo posible, independientemente de si el autor se
534 Tenga en cuenta que la etiqueta From: es opcional cuando el autor From: es
535 también la persona (y correo electrónico) enumerados en la línea From: del
564 encuentran errores y los reportan. Por favor, tenga en cuenta que si se
565 informó de un error en privado, debe pedir primero permiso antes de usar la
569 Una etiqueta Tested-by: indica que el parche se probó con éxito (en algún
575 Reviewed-by: en cambio, indica que el parche ha sido revisado y encontrado
584 evaluar su idoneidad y preparación para su inclusión en
592 entrega, creo que es, en este momento, (1) una
594 cuestiones que argumentarían en contra de su inclusión.
597 no hago (a menos que se indique explícitamente en otro lugar) ninguna
599 propósito o función en cualquier situación dada.
606 revisión que se ha hecho en el parche. Las etiquetas Reviewed-by, cuando
609 parche entre en el kernel.
611 Las etiquetas Tested-by y Reviewed-by, una vez recibidas en la lista de
614 ha cambiado sustancialmente en la siguiente versión, es posible que estas
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
623 especialmente si la idea no fue publicada en un foro público. Dicho esto,
625 sentirán inspirados para ayudarnos nuevamente en el futuro.
627 Una etiqueta Fixes: indica que el parche corrige un problema en un commit
636 proceso del kernel ni el requisito de CC: stable@vger.kernel.org en todos
645 Esta sección describe cómo debe darse formato al propio parche. Tenga en
646 cuenta que, si tiene sus parches almacenados en un repositorio ``git``, el
661 - El cuerpo de la explicación, línea envuelta en 75 columnas, que se
662 copiara en el registro de cambios permanente para describir este parche.
667 también vaya en el registro de cambios.
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
687 resumen`` para cada parche en una serie completa de parches (donde una
691 Tenga en cuenta que la ``frase de resumen`` de su correo electrónico se
692 convierte en un identificador global único para ese parche. Se propaga por
694 usar más adelante en discusiones de desarrolladores que se refieran al
695 parche. La gente querrá buscar en Google la ``frase de resumen`` para leer
706 La ``frase de resumen`` puede estar precedida por etiquetas encerradas en
711 en respuesta a comentarios (es decir, "v1, v2, v3") o "RFC" para indicar
714 Si hay cuatro parches en una serie de parches, los parches individuales
716 desarrolladores entiendan el orden en que se deben aplicar los parches y
726 La línea ``from`` debe ser la primera línea en el cuerpo del mensaje,
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
741 útiles para personas que podrían estar buscando en los registros de
742 commits en busca de la aplicación del parche. El texto debe estar escrito
750 en la ``frase de resumen``, es importante ser tanto sucinto como
760 especialmente útil en parches más grandes. Si va a incluir un ``diffstat``
764 horizontal (que encaje fácilmente en 80 columnas, tal vez con alguna
767 Otros comentarios relevantes solo en el momento o para el maintainer, pero
791 Revise más detalles sobre el formato de parche adecuado en las siguientes
796 Retrocesos en mensajes de confirmación
808 centrarse en el verdadero tema. Este es un ejemplo de un backtrace bien
812 en rIP: 0xffffffffae059994 (native_write_msr+0x4/0x20)
820 In-Reply-To explicitos en las cabeceras
829 forma, varias versiones del parche no se convierten en un inmanejable
830 bosque de referencias en clientes de correo electrónico. Si un enlace es
831 útil, puede usar el redirector https://lore.kernel.org/ (por ejemplo, en
840 revisión, a menudo es útil para ellos saber en qué parte del historial del
847 incluir automáticamente la información del árbol base en su envío usando el
862 Cuando abra ``outgoing/0000-cover-letter.patch`` para editar, tenga en
878 La función ``--base`` se introdujo en la versión 2.9.0 de git.
882 árbol en que se basa su trabajo. Debe agregarlo en la carta de presentación
883 o en el primer parche de la serie y debe colocarse ya sea bajo la línea
884 ``---`` o en la parte inferior de todos los demás contenido, justo antes de