Lines Matching refs:para
15 ha tenido que adaptar varios procesos para mantener el desarrollo sin
17 para ser una parte efectiva del mismo.
44 de parches para cada lanzamiento. Al comienzo de cada ciclo de desarrollo,
48 La mayor parte de los cambios para un nuevo ciclo de desarrollo (y todos
62 5.6-rc1. El lanzamiento -rc1 señala que el tiempo para fusionar nuevas
63 características ha pasado y que el tiempo para estabilizar el siguiente
73 excepción ocasional para los drivers de hardware que no se admitía
122 considerado para un lanzamiento de actualización, un parche debe
124 mainline para el siguiente kernel de desarrollo. Por lo general, los
143 soporte durante un periodo más largo. Consulte el siguiente enlace para
149 La selección de un kernel para soporte a largo plazo es puramente una
150 cuestión de que un maintainer tenga la necesidad y el tiempo para
151 mantener ese lanzamiento. No hay planes conocidos para ofrecer soporte a
152 largo plazo para ningún lanzamiento especifico próximo.
159 informal) diseñado para garantizar que cada parche sea revisado en cuanto
161 el mainline. Este proceso puede ocurrir rápidamente para correcciones
173 - Diseño. Aquí es donde se establecen los requisitos reales para el
184 - Revisión más amplia. Cuando el parche se acerca a estar listo para su
201 al kernel actual para que se aplique limpiamente y seguir enviándolo
202 para su revisión y fusión.
246 gestionan; son los que (usualmente) aceptarán un parche para incluirlo en
259 le pedirán a Linus que “extraiga” los parches que han seleccionado para
286 alguien quiere ver todos los parches que se están preparando para la
288 saber que otros cambios están pendientes para ver si hay algún conflicto
298 subsistemas se recopilan para pruebas y revisiones. El más antiguo de
307 kernel para la que no hay un árbol de subsistemas designado. Como
309 último recurso; si no hay otro camino obvio para un parche en el mainline,
325 El árbol principal para la fusión de parches del siguiente ciclo es
343 donde residen muchos subdirectorios para drivers o sistemas de archivos
356 TODO enumera el trabajo pendiente que el driver necesita para ser aceptado
358 Cc’d para cualquier parche para el driver. Las reglas actuales exigen
369 camino para hacia convertirse en un apropiado driver del mainline.
379 documento, pero hay espacio para algunos consejos.
384 comunidad de software libre. Está bien ajustado para el desarrollo de
388 Algún tipo de familiaridad con git es casi un requisito para los
389 desarrolladores del kernel; incluso si no lo usan para su propio
390 trabajo, necesitarán git para mantenerse al día con lo que otros
416 principales maintainers de subsistemas utilizan Quilt para gestionar los
418 árboles (por ejemplo, -mm) Quilt es la mejor herramienta para el trabajo.
426 listas de correo de Linux también representan un peligro potencial para
439 La lista de correo principal para el desarrollo del kernel es, por
463 listas) conserve el encabezado Cc: para todos los involucrados. En
481 punto de encuentro general, pero no es el mejor lugar para encontrar
485 común de errores para desarrolladores principiantes. Alguien que haga
487 recibirá una surgencia educada para preguntar en la lista de netdev en su
489 desarrolladores de redes. Existen otras listas para los subsistemas SCSI,
490 video4linux, IDE, sistema de archivos, etc. El mejor lugar para buscar
502 Las empresas a menudo buscan contratar desarrolladores conocidos para
504 efectiva. Pero también tiende a ser caro y no hace mucho para crecer el
513 un lugar para empezar. Comenzar con un proyecto grande puede ser
516 la creación de parches para corregir errores ortográficos o problemas
523 Andrew Morton da este consejo (traducido) para los aspirantes a
528 El proyecto #1 para los principiantes en el kernel seguramente debería
531 de hacer esto es trabajar con otros para arreglar las cosas (¡esto