Lines Matching +full:si +full:- +full:en
1 .. include:: ../disclaimer-sp.rst
13 desarrolladores involucrados. Con una base de usuarios en los millones y
20 -------------------
23 en el tiempo de manera flexible, con uno nuevo lanzamiento principal del
37 características, cambios internos en la API y más. Un lanzamiento típico
38 puede contener alrededor de 13,000 conjuntos de cambios incluyendo en
45 se dice que la "merge window" (ventana de fusión) está abierta. En ese
47 aceptado por la comunidad de desarrollo) se fusiona en el kernel mainline.
55 y montados con anticipación. Como funciona ese proceso se describirá en
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
70 suelen recibir una recepción poco amistosa. Como regla general, si se
74 anteriormente; si no afectan a ningún código en árbol, no pueden causar
75 regresiones y debería ser seguro agregarlos en cualquier momento).
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,
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
103 son bienvenidos, pero aquellos que rompen sistemas que funcionaron en el
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
120 Kroah-Hartman. El equipo estable lanzará actualizaciones ocasionales al
123 (1) corregir un error significativo y (2) ya estar fusionado en el
127 la historia del kernel 5.2 se veía así (todas las fechas en 2019):
155 --------------------------
158 kernel mainline. Hay, en cambio, un proceso algo complicado (aunque algo
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
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
169 tratamiento mucho más detallado vendrá en secciones posteriores.
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
176 mejor hacer este trabajo de manera abierta si es posible; puede ahorrar
179 - Revisión inicial. Los parches se publican en la lista de correo
180 relevante y los desarrolladores en esa lista responden con cualquier
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
187 que el parche llegara hasta el mainline. El parche aparecerá en el
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
196 prioridad. Si su parche está recibiendo comentarios sobre los cambios
198 no deberían realizarse. Si su parche no tiene quejas de revisión, pero
200 del driver, debe ser persistente en la actualización del parche
204 - Fusión en el mainline. Eventualmente, un parche exitoso se fusionará
205 en el repositorio mainline administrado por Linux Torvalds. Mas
206 comentarios y/o problemas pueden surgir en este momento; es importante
210 - Lanzamiento estable. El número de usuarios potencialmente afectados por
214 - Mantenimiento a largo plazo. Si bien un desarrollador puede olvidarse
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
220 código si quiere seguir siendo útil a largo plazo.
224 “fusión en el mainline”. Este enfoque conduce invariablemente a la
227 Cómo se integran los parches en el kernel
228 -----------------------------------------
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
240 La base de código del kernel se descompone lógicamente en un conjunto de
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
254 parches, incluida la información de autoría y otros metadatos. En
256 repositorio no se encuentran en el mainline.
260 fusionar de sus repositorios. Si Linus está de acuerdo, el flujo de
261 parches fluirá hacia su repositorio, convirtiéndose en parte del kernel
263 específicos recibidos en una operación de extracción varia. Está claro
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
278 en el kernel depende de encontrar el maintainer adecuado. Enviar parches
282 -------------------------
284 La cadena de árboles de subsistemas guía el flujo de parches en el
285 kernel, pero también plantea una pregunta interesante: ¿Qué pasa si
287 próxima ventana de fusión? Los desarrolladores estarán interesados en
288 saber que otros cambios están pendientes para ver si hay algún conflicto
290 núcleo del kernel, por ejemplo, entrará en conflicto con cualquier otro
292 probadores quieren tener acceso a los cambios en su forma integrada antes
293 de que todos esos cambios se integren en el kernel mainline. Uno podría
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
306 haber sido publicados en una lista de correo o aplicarse a una parte del
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
317 del momento) en:
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
337 en algún momento antes de que se abra la ventana de fusión.
340 ------------------
344 que están en proceso de ser agregados al árbol del kernel. Permanecen
345 en drivers/staging mientras aún necesitan más trabajo; una vez
352 Greg Kroah-Hartman mantiene actualmente el árbol de staging. Los drivers
354 subdirectorio en drivers/staging/. Junto con los archivos de origen del
355 driver, también debe haber un archivo TODO en el directorio. El archivo
357 en el kernel propiamente dicho, así como una lista de personas a las que
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
368 Por lo tanto, el staging es, en el mejor de los casos, una parada en el
369 camino para hacia convertirse en un apropiado driver del mainline.
372 ------------
374 Como se puede ver en el texto anterior, el proceso de desarrollo del
375 kernel depende en gran medida de la capacidad de dirigir colecciones de
376 parches en varias direcciones. Todo ello no funcionaría tan bien como lo
383 control de versiones distribuidos que se están desarrollando en la
389 desarrolladores del kernel; incluso si no lo usan para su propio
394 Hay una página de inicio en:
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
415 cambios en relación con una base de código en evolución. Algunos de los
418 árboles (por ejemplo, -mm) Quilt es la mejor herramienta para el trabajo.
421 ----------------
425 de la comunidad sin unirse al menos a una lista en algún parte. Pero las
428 carga de correo electrónico, incumplir las convenciones utilizadas en las
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:
434 http://vger.kernel.org/vger-lists.html
436 Sim embargo, hay listas alojadas en otros lugares; varios de ellos se
437 encuentran en redhat.com/mailman/listinfo.
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:
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
454 filtrar tanto por el tema de interés (aunque tenga en cuenta que las
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
463 listas) conserve el encabezado Cc: para todos los involucrados. En
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
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
487 recibirá una surgencia educada para preguntar en la lista de netdev en su
491 listas de correo es en el archivo MAINTAINERS incluido con el código
495 -------------------------------------
499 los pasos en falso que hacen que el comienzo de la relación sea más
506 día a los desarrolladores internos en el desarrollo de kernel de Linux,
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
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
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
539 abiertos en general. Nunca faltan problemas que necesitan solución; al