Lines Matching full:se
16 problemas. Se requiere una comprensión solida de cómo funciona el proceso
25 lanzamientos se ve así:
43 Se sigue una disciplina relativamente sencilla con respecto a la fusión
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
47 aceptado por la comunidad de desarrollo) se fusiona en el kernel mainline.
49 los cambios principales) se fusionarán durante este tiempo, a un ritmo
55 y montados con anticipación. Como funciona ese proceso se describirá en
61 ejemplo, el lanzamiento al final de la ventana de fusión se llamará
67 problemas deben enviarse al mainline. En ocasiones, se permitirá un cambio
70 suelen recibir una recepción poco amistosa. Como regla general, si se
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
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
89 Septiembre 30 5.4-rc1, la ventana de fusion se cierra
104 pasado se consideran especialmente graves. Por esta razón, los parches
105 que causan regresiones se ven con malos ojos y es bastante probable que
106 se reviertan durante el periodo de estabilización.
109 conocidas antes de que se realice el lanzamiento estable. En el mundo
115 se lanzan con un punado de regresiones conocidas, aunque, con suerte,
118 Una vez que se realiza un lanzamiento estable, su mantenimiento continuo
119 se transfiere al “equipo estable”, actualmente encabezado por Greg
127 la historia del kernel 5.2 se veía así (todas las fechas en 2019):
142 Algunos kernels se designan como kernels “a largo plazo”; recibirán
173 - Diseño. Aquí es donde se establecen los requisitos reales para el
174 parche – y la forma en que se cumplirán esos requisitos. El trabajo
175 de diseño a menudo se realiza sin involucrar a la comunidad, pero es
179 - Revisión inicial. Los parches se publican en la lista de correo
184 - Revisión más amplia. Cuando el parche se acerca a estar listo para su
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
204 - Fusión en el mainline. Eventualmente, un parche exitoso se fusionará
227 Cómo se integran los parches en el kernel
232 9,500 parches que se incluyeron en el kernel 2.6.38, solo 112 (alrededor
240 La base de código del kernel se descompone lógicamente en un conjunto de
256 repositorio no se encuentran en el mainline.
258 Cuando se abre la ventana de fusión, los maintainers de nivel superior
269 maintainers. Por ejemplo, el árbol de red se construye a partir de
270 parches que se acumulan primero en arboles dedicados a drivers de
274 administran árboles de nivel inferior, este proceso se conoce como la
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
293 de que todos esos cambios se integren en el kernel mainline. Uno podría
298 subsistemas se recopilan para pruebas y revisiones. El más antiguo de
299 estos árboles, mantenido por Andrew Morton, se llama “-mm” (por gestión
310 es probable que termine en -mm. Los parches misceláneos que se acumulan
311 en -mm eventualmente se enviarán a un árbol de subsistema apropiado o se
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
329 se anuncian en las listas de correo linux-kernel y linux-next cuando se
330 ensamblan; Se pueden descargar desde:
334 Linux-next se ha convertido en una parte integral del proceso de
337 en algún momento antes de que se abra la ventana de fusión.
346 completados, se pueden mover al kernel propiamente dicho. Esta es una
353 que aun necesitan trabajo se le envían, y cada driver tiene su propio
374 Como se puede ver en el texto anterior, el proceso de desarrollo del
383 control de versiones distribuidos que se están desarrollando en la
385 kernel, ya que funciona bastante bien cuando se trata de grandes
423 Una gran parte del trabajo de desarrollo del kernel de Linux se realiza a
431 La mayoría de las listas de correo del kernel se ejecutan en
432 vger.kernel.org; la lista principal se puede encontrar en:
436 Sim embargo, hay listas alojadas en otros lugares; varios de ellos se
442 conversación puede ser muy técnica y los participantes no siempre se
444 donde la comunidad de desarrollo del kernel se reúna como un todo; los
445 desarrolladores que eviten esta lista se perderán información importante.
449 - Haga que la lista se entregue en una carpeta separada, en lugar de su
467 sea necesario solicitar explícitamente que se le copie en las respuestas
515 primero. Este es el punto en el que algunos desarrolladores se lanzan a
519 conjunto, por lo que, cada vez más, se los mira con desprecio. Los nuevos
537 En ausencia de problemas obvios que solucionar, se aconseja a los
541 proceso mientras, al mismo tiempo, se ganarán el respeto del resto de la