Lines Matching refs:para
8 Envío de parches: la guía esencial para incluir su código en el kernel
21 Documentation/process/submit-checklist.rst para obtener una lista de
26 Esta documentación asume que está usando ``git`` para preparar sus parches.
39 use ``git`` para obtener uno. Querrá comenzar con el repositorio principal,
47 preparados para esos árboles. Revise el campo **T:** para el subsistema
48 en el archivo MAINTAINERS para encontrar dicho árbol, o simplemente
57 línea o 5000 líneas para una nuevo "feature", debe haber un problema
80 optimización para que el revisor pueda comparar las perdidas con los
85 lenguaje sencillo para que el revisor verifique que el código se está
101 referencias URL para encontrar la descripción del parche y colocarla en el
109 Cambié xyzzy para que haga frotz", como si estuviera dando órdenes al
110 código fuente para cambiar su comportamiento.
114 del commit, para que sea más fácil para los revisores saber de qué se
145 Verifique el enlace para asegurarse de que realmente funciona y apunta al
157 regla "ajustar a 75 columnas" para simplificar análisis de scripts. Por
163 Las siguientes configuraciones de ``git config`` se pueden usar para
197 Si un parche depende de otro parche para que un cambio sea completo, eso
204 para rastrear un problema pueden terminar dividiendo su serie de parches en
215 Revise su parche para ver si hay violaciones de estilo básico, cuyos
245 MAINTAINERS y el historial de revisión del código fuente para ver quiénes
247 útil en este paso (pase rutas a sus parches como argumentos para
252 Normalmente, también debe elegir al menos una lista de correo para recibir
254 usarse de forma predeterminada para todos los parches, pero el volumen en
271 normalmente debe hacer todo lo posible para -evitar- enviarle un correo
290 Si los cambios afectan las interfaces del kernel para el usuario, envíe al
292 parche de páginas de manual, o al menos una notificación del cambio, para
302 los cambios que está enviando. Es importante para un desarrollador kernel
309 es muy recomendable. Un tutorial interactivo para ``git send-email`` está
322 en su código. Linus también necesita un poco más de tiempo para procesar un
329 Consulte Documentation/process/email-clients.rst para obtener sugerencias
330 sobre cómo configurar su cliente de correo electrónico para que envíe sus
340 responder a sus correos electrónicos para contestar a sus comentarios.
343 "changelog" para que el próximo revisor entienda lo que está pasando.
355 Consulte Documentation/process/email-clients.rst para obtener
449 serán ignoradas por ahora, pero puede hacer esto para marcar procedimientos
496 desarrolladores; se utiliza para dar atribución a los coautores (además del
539 use para acreditar peticiones de características.
543 de que se han realizado algunas pruebas, proporciona un medio para ubicar
545 para los testers.
555 (a) He llevado a cabo una revisión técnica de este parche para
556 evaluar su idoneidad y preparación para su inclusión en
576 puede ofrecer una etiqueta Reviewed-by para un parche. Esta etiqueta sirve
577 para dar crédito a revisores e informar a los maintainers del grado de
597 sentirán inspirados para ayudarnos nuevamente en el futuro.
600 anterior. Esto se utiliza para facilitar descubrir dónde se originó un
604 método preferido para indicar un error corregido por el parche. Revise
605 :ref:`describe_changes` para más detalles.
634 copiara en el registro de cambios permanente para describir este parche.
643 - Cualquier comentario adicional que no sea adecuado para el registro de
659 resumen`` para cada parche en una serie completa de parches (donde una
664 convierte en un identificador global único para ese parche. Se propaga por
667 parche. La gente querrá buscar en Google la ``frase de resumen`` para leer
683 en respuesta a comentarios (es decir, "v1, v2, v3") o "RFC" para indicar
705 la línea ``From:`` del encabezado del correo electrónico se usará para
709 lo que debería tener sentido para un lector competente que hace mucho tiempo
713 útiles para personas que podrían estar buscando en los registros de
716 pueda dar al lector la información necesaria y detalles para comprender el
720 incluir _todos_ los errores de compilación; pero lo suficiente como para
725 La línea marcadora ``---`` cumple el propósito esencial de marcar para
730 para ``diffstat``, para mostrar qué archivos han cambiado, y el número de
734 ``-p 1 -w 70`` para que los nombres de archivo se enumeran desde la parte
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í.
748 git. Es información adicional para los revisores. Si se coloca encima de la
749 etiquetas de commit, necesita interacción manual para eliminarlo. Si esta
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
798 errores al correo electrónico con el informe de errores. Sin embargo, para
800 In-Reply-To: para vincular a versiones anteriores de la serie. De esta
804 el texto de la carta de introducción del correo electrónico) para vincular
812 revisión, a menudo es útil para ellos saber en qué parte del historial del
813 árbol deben colocar su trabajo. Esto es particularmente útil para CI
814 automatizado de procesos que intentan ejecutar una serie de pruebas para
818 Si está utilizando ``git format-patch`` para generar sus parches, puede
834 Cuando abra ``outgoing/0000-cover-letter.patch`` para editar, tenga en
836 revisor y a las herramientas de CI suficiente información para realizar
845 Consulte ``man git-format-patch`` para obtener más información al respecto
852 Si no está utilizando git para dar forma a sus parches, aún puede incluir
853 el mismo tráiler ``base-commit`` para indicar el hash de confirmación del
891 Algunas estrategias para conseguir incluir cambios complicados o