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
380 sean relevantes para su respuesta. Esto hace que las respuestas sean más
477 serán ignoradas por ahora, pero puede hacer esto para marcar procedimientos
524 desarrolladores; se utiliza para dar atribución a los coautores (además del
567 use para acreditar peticiones de características.
571 de que se han realizado algunas pruebas, proporciona un medio para ubicar
573 para los testers.
583 (a) He llevado a cabo una revisión técnica de este parche para
584 evaluar su idoneidad y preparación para su inclusión en
604 puede ofrecer una etiqueta Reviewed-by para un parche. Esta etiqueta sirve
605 para dar crédito a revisores e informar a los maintainers del grado de
625 sentirán inspirados para ayudarnos nuevamente en el futuro.
628 anterior. Esto se utiliza para facilitar descubrir dónde se originó un
632 método preferido para indicar un error corregido por el parche. Revise
633 :ref:`describe_changes` para más detalles.
662 copiara en el registro de cambios permanente para describir este parche.
671 - Cualquier comentario adicional que no sea adecuado para el registro de
687 resumen`` para cada parche en una serie completa de parches (donde una
692 convierte en un identificador global único para ese parche. Se propaga por
695 parche. La gente querrá buscar en Google la ``frase de resumen`` para leer
711 en respuesta a comentarios (es decir, "v1, v2, v3") o "RFC" para indicar
733 la línea ``From:`` del encabezado del correo electrónico se usará para
737 lo que debería tener sentido para un lector competente que hace mucho tiempo
741 útiles para personas que podrían estar buscando en los registros de
744 pueda dar al lector la información necesaria y detalles para comprender el
748 incluir _todos_ los errores de compilación; pero lo suficiente como para
753 La línea marcadora ``---`` cumple el propósito esencial de marcar para
758 para ``diffstat``, para mostrar qué archivos han cambiado, y el número de
762 ``-p 1 -w 70`` para que los nombres de archivo se enumeran desde la parte
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í.
776 git. Es información adicional para los revisores. Si se coloca encima de la
777 etiquetas de commit, necesita interacción manual para eliminarlo. Si esta
824 (por ejemplo, al usar ``git send-email``) para asociar el parche con una
825 discusión anterior relevante, por ejemplo para vincular una corrección de
826 errores al correo electrónico con el informe de errores. Sin embargo, para
828 In-Reply-To: para vincular a versiones anteriores de la serie. De esta
832 el texto de la carta de introducción del correo electrónico) para vincular
840 revisión, a menudo es útil para ellos saber en qué parte del historial del
841 árbol deben colocar su trabajo. Esto es particularmente útil para CI
842 automatizado de procesos que intentan ejecutar una serie de pruebas para
846 Si está utilizando ``git format-patch`` para generar sus parches, puede
862 Cuando abra ``outgoing/0000-cover-letter.patch`` para editar, tenga en
864 revisor y a las herramientas de CI suficiente información para realizar
873 Consulte ``man git-format-patch`` para obtener más información al respecto
880 Si no está utilizando git para dar forma a sus parches, aún puede incluir
881 el mismo tráiler ``base-commit`` para indicar el hash de confirmación del
919 Algunas estrategias para conseguir incluir cambios complicados o