Lines Matching refs:el
8 Cómo funciona el proceso de desarrollo
14 alrededor de 2,000 desarrolladores involucrados durante un año, el kernel
15 ha tenido que adaptar varios procesos para mantener el desarrollo sin
16 problemas. Se requiere una comprensión solida de cómo funciona el proceso
23 en el tiempo de manera flexible, con uno nuevo lanzamiento principal del
40 desarrollo del kernel de Linux; el kernel utiliza un modelo de desarrollo
46 momento, el código que se considera lo suficientemente estable (y que es
47 aceptado por la comunidad de desarrollo) se fusiona en el kernel mainline.
60 el primero de los kernels “rc”. Para el kernel destinado a ser 5.6, por
61 ejemplo, el lanzamiento al final de la ventana de fusión se llamará
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
77 A medida que las correcciones se abren paso en el mainline, la tasa de
78 parches se ralentizará con el tiempo. Linus lanza nuevos kernels -rc
80 punto entre -rc6 y -rc9 antes de que se considere que el kernel es
81 suficientemente estable y realice el lanzamiento final. En ese momento,
82 todo el proceso vuelve a empezar.
84 Como ejemplo, así fue el ciclo de desarrollo de 5.4 (todas las fechas son
100 ¿Cómo deciden los desarrolladores cuándo cerrar el ciclo de desarrollo
101 y crear el lanzamiento estable? La métrica más significativa utilizada
103 son bienvenidos, pero aquellos que rompen sistemas que funcionaron en el
106 se reviertan durante el periodo de estabilización.
109 conocidas antes de que se realice el lanzamiento estable. En el mundo
111 variables en un proyecto de este tamaño. Llega un punto en el que
112 retrasar el lanzamiento final solo empeora el problema; la pila de cambios
121 lanzamiento estable utilizando el esquema de numeración 5.x.y. Para ser
123 (1) corregir un error significativo y (2) ya estar fusionado en el
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
150 cuestión de que un maintainer tenga la necesidad y el tiempo para
157 Los parches no van directamente desde el teclado del desarrollador al
161 el mainline. Este proceso puede ocurrir rápidamente para correcciones
162 menores, o, en el caso de cambios grandes y controvertidos, continuar
167 cómo un parche entra en el kernel. Lo que sigue a continuación es una
168 introducción que describe el proceso de una manera tanto idealizada. Un
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
185 inclusión en el mainline, debe ser aceptado por un maintainer del
187 que el parche llegara hasta el mainline. El parche aparecerá en el
189 a continuación). Cuando el proceso funciona, este paso conduce a una
191 problema resultante de la integración de este parche con el trabajo
199 no está siendo fusionado por el maintainer apropiado del subsistema o
204 - Fusión en el mainline. Eventualmente, un parche exitoso se fusionará
205 en el repositorio mainline administrado por Linux Torvalds. Mas
207 que el desarrollador responda a estos y solucione cualquier problema
211 el parche es ahora grande, por lo que, una vez más, pueden surgir
216 una impresión negativa en la comunidad de desarrollo. Fusionar el
218 los problemas causados por los cambios en la API. Sin embargo, el
223 (o sus empleadores) es tratar de reducir el proceso a un solo paso de
224 “fusión en el mainline”. Este enfoque conduce invariablemente a la
227 Cómo se integran los parches en el kernel
230 Hay exactamente una persona que puede fusionar parches en el repositorio
232 9,500 parches que se incluyeron en el kernel 2.6.38, solo 112 (alrededor
234 kernel ha crecido mucho desde hace tiempo a un tamaño en el que ningún
247 el kernel mainline.
255 cualquier momento, el maintainer puede identificar qué parches de su
256 repositorio no se encuentran en el mainline.
260 fusionar de sus repositorios. Si Linus está de acuerdo, el flujo de
269 maintainers. Por ejemplo, el árbol de red se construye a partir de
278 en el kernel depende de encontrar el maintainer adecuado. Enviar parches
284 La cadena de árboles de subsistemas guía el flujo de parches en el
293 de que todos esos cambios se integren en el kernel mainline. Uno podría
309 último recurso; si no hay otro camino obvio para un parche en el mainline,
313 aproximadamente el 5-10% de los parches que van al mainline llegan allí
316 El parche -mm actual está disponible en el directorio “mmotm” (-mm
321 Sin embargo, es probable que el uso del árbol MMOTM sea una experiencia
327 diseño, una instantánea de cómo se espera que se vea el mainline después
342 El árbol de fuentes del kernel contiene el directorio drivers/staging/,
352 Greg Kroah-Hartman mantiene actualmente el árbol de staging. Los drivers
355 driver, también debe haber un archivo TODO en el directorio. El archivo
356 TODO enumera el trabajo pendiente que el driver necesita para ser aceptado
357 en el kernel propiamente dicho, así como una lista de personas a las que
358 Cc’d para cualquier parche para el driver. Las reglas actuales exigen
363 drivers en el mainline donde, con suerte, llamarán la atención de otros
364 desarrolladores y mejorarán rápidamente. Sin embargo, la entrada en el
365 staging no es el final de la historia; el código que no está viendo
368 Por lo tanto, el staging es, en el mejor de los casos, una parada en el
374 Como se puede ver en el texto anterior, el proceso de desarrollo del
381 Con mucho, el sistema de gestión de código fuente dominante utilizado
384 comunidad de software libre. Está bien ajustado para el desarrollo de
387 de ser difícil de aprender y usar, aunque ha mejorado con el tiempo.
391 desarrolladores (y el mainline) están haciendo.
413 gestión de código fuente. No rastrea el historial a lo largo del tiempo;
418 árboles (por ejemplo, -mm) Quilt es la mejor herramienta para el trabajo.
427 los desarrolladores, que corren el riesgo de quedar enterrados bajo una
439 La lista de correo principal para el desarrollo del kernel es, por
440 supuesto, linux-kernel. Esta lista es un lugar intimidante; el volumen
447 Hay algunos consejos que pueden ayudar a sobrevivir en el kernel de Linux:
450 buzón principal. Uno debe ser capaz de ignorar el flujo durante
454 filtrar tanto por el tema de interés (aunque tenga en cuenta que las
463 listas) conserve el encabezado Cc: para todos los involucrados. En
480 - Pregunte en la lista de correo correcta. linux-kernel puede ser el
481 punto de encuentro general, pero no es el mejor lugar para encontrar
491 listas de correo es en el archivo MAINTAINERS incluido con el código
494 Comenzar con el desarrollo del kernel
497 Las preguntas sobre como comenzar con el proceso de desarrollo del kernel
499 los pasos en falso que hacen que el comienzo de la relación sea más
504 efectiva. Pero también tiende a ser caro y no hace mucho para crecer el
506 día a los desarrolladores internos en el desarrollo de kernel de Linux,
508 empleador de un grupo de desarrolladores que comprendan tanto el kernel
510 plazo, este es a menudo el enfoque más rentable.
515 primero. Este es el punto en el que algunos desarrolladores se lanzan a
528 El proyecto #1 para los principiantes en el kernel seguramente debería
529 ser “asegúrese de que el kernel funcione perfectamente en todo momento
540 abordar estos problemas, los desarrolladores ganarán experiencia con el
541 proceso mientras, al mismo tiempo, se ganarán el respeto del resto de la