Lines Matching +full:un +full:-
1 .. include:: ../disclaimer-sp.rst
12 un asunto relajado, con un número relativamente pequeño de usuarios y
14 alrededor de 2,000 desarrolladores involucrados durante un año, el kernel
20 -------------------
22 Los desarrolladores del kernel utilizan un proceso de lanzamiento basado
36 Cada lanzamiento 5.x es un lanzamiento principal del kernel con nuevas
37 características, cambios internos en la API y más. Un lanzamiento típico
40 desarrollo del kernel de Linux; el kernel utiliza un modelo de desarrollo
48 La mayor parte de los cambios para un nuevo ciclo de desarrollo (y todos
49 los cambios principales) se fusionarán durante este tiempo, a un ritmo
62 5.6-rc1. El lanzamiento -rc1 señala que el tiempo para fusionar nuevas
67 problemas deben enviarse al mainline. En ocasiones, se permitirá un cambio
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
90 Octubre 6 5.4-rc2
91 Octubre 13 5.4-rc3
92 Octubre 20 5.4-rc4
93 Octubre 27 5.4-rc5
94 Noviembre 3 5.4-rc6
95 Noviembre 10 5.4-rc7
96 Noviembre 17 5.4-rc8
111 variables en un proyecto de este tamaño. Llega un punto en el que
115 se lanzan con un punado de regresiones conocidas, aunque, con suerte,
118 Una vez que se realiza un lanzamiento estable, su mantenimiento continuo
120 Kroah-Hartman. El equipo estable lanzará actualizaciones ocasionales al
122 considerado para un lanzamiento de actualización, un parche debe
123 (1) corregir un error significativo y (2) ya estar fusionado en el
125 kernels recibirán actualizaciones estables durante un poco más de un
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
154 Ciclo de vida de un parche
155 --------------------------
158 kernel mainline. Hay, en cambio, un proceso algo complicado (aunque algo
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:
173 - Diseño. Aquí es donde se establecen los requisitos reales para el
179 - Revisión inicial. Los parches se publican en la lista de correo
182 problema importante con un parche si todo va bien.
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
188 árbol de subsistemas del maintainer y en los árboles -next (descritos
194 - Tenga en cuenta que la mayoría de los maintainers también tienen
204 - Fusión en el mainline. Eventualmente, un parche exitoso se fusionará
210 - Lanzamiento estable. El número de usuarios potencialmente afectados por
214 - Mantenimiento a largo plazo. Si bien un desarrollador puede olvidarse
223 (o sus empleadores) es tratar de reducir el proceso a un solo paso de
228 -----------------------------------------
234 kernel ha crecido mucho desde hace tiempo a un tamaño en el que ningún
237 abordado este crecimiento es a través del uso de un sistema jerárquico
240 La base de código del kernel se descompone lógicamente en un conjunto de
243 un maintainer designado, un desarrollador que tiene la responsabilidad
246 gestionan; son los que (usualmente) aceptarán un parche para incluirlo en
253 permiten a los maintainers realizar un seguimiento de una lista de
277 Claramente, en un sistema como este, lograr que los parches se integren
282 -------------------------
289 del que preocuparse; un parche que cambia un prototipo de función del
295 eso sería un trabajo tedioso y propenso a errores.
297 La respuesta viene en forma de árboles -next, donde los árboles de
299 estos árboles, mantenido por Andrew Morton, se llama “-mm” (por gestión
300 de la memoria, que es como comenzó). El árbol “-mm” integra parches
304 Más allá de eso, -mm contiene una colección significativa de parches
307 kernel para la que no hay un árbol de subsistemas designado. Como
308 resultado, -mm funciona como una especie de árbol de subsistemas de
309 último recurso; si no hay otro camino obvio para un parche en el mainline,
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
312 enviarán directamente a Linus. En un ciclo de desarrollo típico,
313 aproximadamente el 5-10% de los parches que van al mainline llegan allí
314 a través de -mm.
316 El parche -mm actual está disponible en el directorio “mmotm” (-mm
326 linux-next, mantenido por Stephen Rothwell. El árbol linux-next es, por
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
334 Linux-next se ha convertido en una parte integral del proceso de
336 de fusión determinada deberían haber encontrado su camino en linux-next
340 ------------------
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
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
369 camino para hacia convertirse en un apropiado driver del mainline.
372 ------------
388 Algún tipo de familiaridad con git es casi un requisito para los
396 https://git-scm.com/
412 Quilt es un sistema de gestión de parches, en lugar de un sistema de
414 en cambio, está orientado al seguimiento de un conjunto especifico de
418 árboles (por ejemplo, -mm) Quilt es la mejor herramienta para el trabajo.
421 ----------------
424 través de listas de correo. Es difícil ser un miembro plenamente funcional
426 listas de correo de Linux también representan un peligro potencial para
434 http://vger.kernel.org/vger-lists.html
440 supuesto, linux-kernel. Esta lista es un lugar intimidante; el volumen
443 preocupan por mostrar un alto grado de cortesía. Pero no hay otro lugar
444 donde la comunidad de desarrollo del kernel se reúna como un todo; los
449 - Haga que la lista se entregue en una carpeta separada, en lugar de su
453 - No trate de seguir cada conversación, nadie lo hace. Es importante
459 - No alimente a los trolls. Si alguien está tratando de provocar una
462 - Al responder al correo electrónico del kernel de Linux (o al de otras
470 - Busque en los archivos de la lista (y en la red en su conjunto) antes
474 - Utilice respuestas intercaladas (“en línea”), lo que hace que su
475 respuesta sea más fácil de leer. (Es decir, evite top-posting – la
478 :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_interleaved_replies>`.
480 - Pregunte en la lista de correo correcta. linux-kernel puede ser el
486 una pregunta relacionada con las redes en linux-kernel seguramente
495 -------------------------------------
503 iniciar un grupo de desarrollo. De hecho, esta puede ser una técnica
507 dada la inversión de algún tiempo. Tomarse este tiempo puede dotar a un
508 empleador de un grupo de desarrolladores que comprendan tanto el kernel
513 un lugar para empezar. Comenzar con un proyecto grande puede ser
518 crean un nivel de ruido que distrae a la comunidad de desarrollo en su