Lines Matching refs:que
15 ha tenido que adaptar varios procesos para mantener el desarrollo sin
41 continuo que está integrando continuamente cambios importantes.
45 se dice que la "merge window" (ventana de fusión) está abierta. En ese
46 momento, el código que se considera lo suficientemente estable (y que es
53 (Aparte, vale la pena señalar que los cambios integrados durante la
59 tiempo, Linux Torvalds declarará que la ventana está cerrada y publicará
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
66 Durante las próximas seis a diez semanas, solo los parches que solucionen
68 más significativo, pero tales ocasiones son raras; los desarrolladores que
72 que puede hacer es esperar al siguiente ciclo de desarrollo. (Se hace una
73 excepción ocasional para los drivers de hardware que no se admitía
77 A medida que las correcciones se abren paso en el mainline, la tasa de
80 punto entre -rc6 y -rc9 antes de que se considere que el kernel es
103 son bienvenidos, pero aquellos que rompen sistemas que funcionaron en el
105 que causan regresiones se ven con malos ojos y es bastante probable que
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
113 que esperan la siguiente ventana de fusión crecerá, creando aún más
118 Una vez que se realiza un lanzamiento estable, su mantenimiento continuo
150 cuestión de que un maintainer tenga la necesidad y el tiempo para
159 informal) diseñado para garantizar que cada parche sea revisado en cuanto
160 a calidad y que cada parche implemente un cambio que es deseable tener en
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
171 Las etapas por las que pasa un parche son, generalmente:
174 parche – y la forma en que se cumplirán esos requisitos. El trabajo
181 comentario que puedan tener. Este proceso debería revelar cualquier
187 que el parche llegara hasta el mainline. El parche aparecerá en el
194 - Tenga en cuenta que la mayoría de los maintainers también tienen
195 trabajos diurnos, por lo que fusionar su parche no puede ser su máxima
197 que se necesitan, debería realizar esos cambios o justificar por qué
201 al kernel actual para que se aplique limpiamente y seguir enviándolo
207 que el desarrollador responda a estos y solucione cualquier problema
208 que surja.
211 el parche es ahora grande, por lo que, una vez más, pueden surgir
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
236 parches sin ayuda. La forma que los desarrolladores del kernel han
243 un maintainer designado, un desarrollador que tiene la responsabilidad
245 subsistemas son los guardianes (en cierto modo) de la parte del kernel que
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
262 mainline. La cantidad de atención que Linus presta a los parches
264 que, a veces, examina bastante de cerca. Pero, como regla general, Linus
265 confía en que los maintainers del subsistema no envíen parches
270 parches que se acumulan primero en arboles dedicados a drivers de
273 enlaces. Dado que cada maintainer de la cadena confía en los que
277 Claramente, en un sistema como este, lograr que los parches se integren
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
289 del que preocuparse; un parche que cambia un prototipo de función del
291 parche que utilice la forma anterior de esa función. Los revisores y
293 de que todos esos cambios se integren en el kernel mainline. Uno podría
300 de la memoria, que es como comenzó). El árbol “-mm” integra parches
305 que han sido seleccionados directamente por Andrew. Estos parches pueden
307 kernel para la que no hay un árbol de subsistemas designado. Como
310 es probable que termine en -mm. Los parches misceláneos que se acumulan
313 aproximadamente el 5-10% de los parches que van al mainline llegan allí
321 Sin embargo, es probable que el uso del árbol MMOTM sea una experiencia
322 frustrante; existe una posibilidad definitiva de que ni siquiera se
327 diseño, una instantánea de cómo se espera que se vea el mainline después
328 de que se cierre la siguiente ventana de fusión. Los árboles linux-next
337 en algún momento antes de que se abra la ventana de fusión.
344 que están en proceso de ser agregados al árbol del kernel. Permanecen
347 forma de realizar un seguimiento de los drivers drivers que no están a la
349 Linux, pero que las personas pueden querer usarlos y realizar un
353 que aun necesitan trabajo se le envían, y cada driver tiene su propio
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
359 que los drivers que contribuyen a staging deben, como mínimo, compilarse
365 staging no es el final de la historia; el código que no está viendo
383 control de versiones distribuidos que se están desarrollando en la
385 kernel, ya que funciona bastante bien cuando se trata de grandes
390 trabajo, necesitarán git para mantenerse al día con lo que otros
400 Entre los desarrolladores de kernel que no usan git, la opción más
406 interfaz que muchos encuentran más fácil de usar.
408 Otra herramienta que vale la pena conocer es Quilt:
427 los desarrolladores, que corren el riesgo de quedar enterrados bajo una
445 desarrolladores que eviten esta lista se perderán información importante.
447 Hay algunos consejos que pueden ayudar a sobrevivir en el kernel de Linux:
449 - Haga que la lista se entregue en una carpeta separada, en lugar de su
454 filtrar tanto por el tema de interés (aunque tenga en cuenta que las
457 que participan.
465 eliminar destinarios. Asegúrese siempre de que la persona a la que está
466 respondiendo esté en la lista Cc:. Esta convención también hace que no
467 sea necesario solicitar explícitamente que se le copie en las respuestas
472 las personas que claramente no han hecho sus deberes.
474 - Utilice respuestas intercaladas (“en línea”), lo que hace que su
476 práctica de poner su respuesta encima del texto citado al que está
485 común de errores para desarrolladores principiantes. Alguien que haga
488 lugar, ya que esa es la lista frecuentada por la mayoría de los
499 los pasos en falso que hacen que el comienzo de la relación sea más
500 difícil de lo que tiene que ser.
508 empleador de un grupo de desarrolladores que comprendan tanto el kernel
509 como la empresa, y que también puedan ayudar a educar a otros. A medio
515 primero. Este es el punto en el que algunos desarrolladores se lanzan a
518 crean un nivel de ruido que distrae a la comunidad de desarrollo en su
519 conjunto, por lo que, cada vez más, se los mira con desprecio. Los nuevos
520 desarrolladores que deseen presentarse a la comunidad no recibirán la
521 recepción que desean por estos medios.
529 ser “asegúrese de que el kernel funcione perfectamente en todo momento
530 en todas las máquinas que pueda conseguir”. Por lo general, la forma
537 En ausencia de problemas obvios que solucionar, se aconseja a los
538 desarrolladores que consulten las listas actuales de regresiones y errores
539 abiertos en general. Nunca faltan problemas que necesitan solución; al