Lines Matching refs:una
11 Para una persona o empresa que desee enviar un cambio al kernel Linux,
13 familiarizado con "el sistema". Este texto es una colección de sugerencias
17 Este documento contiene una gran cantidad de sugerencias en un formato
21 Documentation/process/submit-checklist.rst para obtener una lista de
56 Describa su problema. Sea su parche una corrección de un error de una
57 línea o 5000 líneas para una nuevo "feature", debe haber un problema
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
113 referencia al ID SHA-1 del commit. Incluya también el resumen de una línea
124 objetos, por lo que las colisiones con identificaciones más cortas son una
132 ejemplo, agregue una etiqueta con una URL que haga referencia al informe en
149 externos. Además de dar una URL a un archivo o error de la lista de correo,
155 con los primeros 12 caracteres del ID SHA-1 y el resumen de una línea. No
186 Si sus cambios incluyen una actualización de la API y una nueva controlador
201 Cuando divida su cambio en una serie de parches, tenga especial cuidado en
228 verificador de estilo debe ser visto como una guía, no como un reemplazo
229 del juicio humano. Si su código es mejor con una violación entonces
234 - WARNING: Advertencia. Cosas que requieren una revisión cuidadosa
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
256 archivo MAINTAINERS una lista específica de los subsistemas; su parche
282 hacia los maintainers estables poniendo una línea como esta::
292 parche de páginas de manual, o al menos una notificación del cambio, para
339 revisores es una buena manera de ser ignorado de vuelta. Simplemente puede
342 código deben casi con certeza generar un comentario o una entrada en el
367 Érase una vez, los parches solían desaparecer en el vacío sin comentarios,
369 recibir comentarios dentro de una semana más o menos; si eso no sucede,
371 de una semana antes de volver a enviar o hacer ping a los revisores,
381 No incluya "RESEND" cuando envíe una versión modificada de su parche o
406 La aprobación es una simple línea al final de la explicación del parche,
414 Al hacer una contribución a este proyecto, certifico que:
421 soy consciente, está cubierto por una licencia de código
425 (salvo que sea permitido presentar bajo una licencia diferente),
439 entonces simplemente incluya una línea que rece::
467 Si una persona no estuvo directamente involucrada en la preparación o
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
488 Si una persona ha tenido la oportunidad de comentar un parche, pero no lo
489 ha hecho, puede incluir opcionalmente una etiqueta ``Cc:`` al parche.
490 Esta es la única etiqueta que se puede agregar sin una acción explícita por
555 (a) He llevado a cabo una revisión técnica de este parche para
564 entrega, creo que es, en este momento, (1) una
573 Una etiqueta Reviewed-by es una declaración de opinión de que el parche es
574 una modificación apropiada al kernel sin que haya ningún problema grave
576 puede ofrecer una etiqueta Reviewed-by para un parche. Esta etiqueta sirve
583 Las etiquetas Tested-by y Reviewed-by, una vez recibidas en la lista de
601 error, lo que puede ayudar a revisar una corrección de errores. Esta
607 Nota: Adjuntar una etiqueta Fixes: no subvierte las reglas estables del
629 - Una línea ``from`` que especifica el autor del parche, seguida de una
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
684 una solicitud de comentarios.
686 Si hay cuatro parches en una serie de parches, los parches individuales
719 Si un parche corrige una falla de compilación, puede que no sea necesario
796 (por ejemplo, al usar ``git send-email``) para asociar el parche con una
797 discusión anterior relevante, por ejemplo para vincular una corrección de
799 una serie de parches múltiples, generalmente es mejor evitar usar
805 a una versión anterior de la serie de parches.
814 automatizado de procesos que intentan ejecutar una serie de pruebas para