Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

docs/sp_SP: Add translation of process/2.Process.rst

Translate Documentation/process/2.Process.rst into Spanish

Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
Reviewed-by: Carlos Bilbao <carlos.bilbao@amd.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20240305221839.2764380-5-avadhut.naik@amd.com

authored by

Avadhut Naik and committed by
Jonathan Corbet
3dfa8cd9 169e54c2

+534 -2
+533 -2
Documentation/translations/sp_SP/process/2.Process.rst
··· 1 1 .. include:: ../disclaimer-sp.rst 2 2 3 3 :Original: Documentation/process/2.Process.rst 4 + :Translator: Avadhut Naik <avadhut.naik@amd.com> 4 5 5 6 .. _sp_development_process: 6 7 7 8 Cómo funciona el proceso de desarrollo 8 9 ====================================== 9 10 10 - .. warning:: 11 - TODO aún no traducido 11 + El desarrollo del kernel de Linux a principios de la década de 1990 fue 12 + un asunto relajado, con un número relativamente pequeño de usuarios y 13 + desarrolladores involucrados. Con una base de usuarios en los millones y 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 17 + para ser una parte efectiva del mismo. 18 + 19 + El panorama general 20 + ------------------- 21 + 22 + Los desarrolladores del kernel utilizan un proceso de lanzamiento basado 23 + en el tiempo de manera flexible, con uno nuevo lanzamiento principal del 24 + kernel ocurriendo cada dos o tres meses. El historial reciente de 25 + lanzamientos se ve así: 26 + 27 + ====== ================== 28 + 5.0 Marzo 3, 2019 29 + 5.1 Mayo 5, 2019 30 + 5.2 Julio 7, 2019 31 + 5.3 Septiembre 15, 2019 32 + 5.4 Noviembre 24, 2019 33 + 5.5 Enero 6, 2020 34 + ====== ================== 35 + 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 38 + puede contener alrededor de 13,000 conjuntos de cambios incluyendo en 39 + varias centenas de miles de líneas de código. 5.x es la vanguardia del 40 + desarrollo del kernel de Linux; el kernel utiliza un modelo de desarrollo 41 + continuo que está integrando continuamente cambios importantes. 42 + 43 + Se sigue una disciplina relativamente sencilla con respecto a la fusión 44 + de parches para cada lanzamiento. Al comienzo de cada ciclo de desarrollo, 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. 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 50 + cercano a los 1,000 cambios (“parches” o “conjuntos de cambios”) por 51 + día. 52 + 53 + (Aparte, vale la pena señalar que los cambios integrados durante la 54 + ventana de fusión no surgen de la nada; han sido recolectados, probados 55 + y montados con anticipación. Como funciona ese proceso se describirá en 56 + detalle más adelante). 57 + 58 + La ventana de fusión dura aproximadamente dos semanas. Al final de este 59 + tiempo, Linux Torvalds declarará que la ventana está cerrada y publicará 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 64 + kernel ha comenzado. 65 + 66 + Durante las próximas seis a diez semanas, solo los parches que solucionen 67 + problemas deben enviarse al mainline. En ocasiones, se permitirá un cambio 68 + más significativo, pero tales ocasiones son raras; los desarrolladores que 69 + intentan fusionar nuevas características fuera de la ventana de fusión 70 + suelen recibir una recepción poco amistosa. Como regla general, si se 71 + pierde la ventana de fusión de una característica determinada, lo mejor 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 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). 76 + 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 79 + aproximadamente una vez a la semana; una serie normal llegará a algún 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. 83 + 84 + Como ejemplo, así fue el ciclo de desarrollo de 5.4 (todas las fechas son 85 + de 2019): 86 + 87 + ============== ======================================= 88 + Septiembre 15 5.3 lanzamiento estable 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 97 + Noviembre 24 5.4 lanzamiento estable 98 + ============== ======================================= 99 + 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 102 + es la lista de regresiones de lanzamientos anteriores. Ningunos errores 103 + son bienvenidos, pero aquellos que rompen sistemas que funcionaron en el 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. 107 + 108 + El objetivo de los desarrolladores es corregir todas las regresiones 109 + conocidas antes de que se realice el lanzamiento estable. En el mundo 110 + real, este tipo de perfección es difícil de lograr; hay demasiados 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 113 + que esperan la siguiente ventana de fusión crecerá, creando aún más 114 + regresiones la próxima vez. Por lo tanto, la mayoría de los kernels 5.x 115 + se lanzan con un punado de regresiones conocidas, aunque, con suerte, 116 + ninguna de ellas es seria. 117 + 118 + Una vez que se realiza un lanzamiento estable, su mantenimiento continuo 119 + se transfiere al “equipo estable”, actualmente encabezado por Greg 120 + Kroah-Hartman. El equipo estable lanzará actualizaciones ocasionales al 121 + lanzamiento estable utilizando el esquema de numeración 5.x.y. Para ser 122 + considerado para un lanzamiento de actualización, un parche debe 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 125 + kernels recibirán actualizaciones estables durante un poco más de un 126 + ciclo de desarrollo después de su lanzamiento inicial. Así, por ejemplo, 127 + la historia del kernel 5.2 se veía así (todas las fechas en 2019): 128 + 129 + ============== =============================== 130 + Julio 7 5.2 lanzamiento estable 131 + Julio 14 5.2.1 132 + Julio 21 5.2.2 133 + Julio 26 5.2.3 134 + Julio 28 5.2.4 135 + Julio 31 5.2.5 136 + ... ... 137 + Octubre 11 5.2.21 138 + ============== =============================== 139 + 140 + 5.2.21 fue la última actualización estable del lanzamiento 5.2. 141 + 142 + Algunos kernels se designan como kernels “a largo plazo”; recibirán 143 + soporte durante un periodo más largo. Consulte el siguiente enlace para 144 + obtener la lista de versiones activas del kernel a largo plazos y sus 145 + maintainers: 146 + 147 + https://www.kernel.org/category/releases.html 148 + 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 151 + mantener ese lanzamiento. No hay planes conocidos para ofrecer soporte a 152 + largo plazo para ningún lanzamiento especifico próximo. 153 + 154 + Ciclo de vida de un parche 155 + -------------------------- 156 + 157 + Los parches no van directamente desde el teclado del desarrollador al 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 161 + el mainline. Este proceso puede ocurrir rápidamente para correcciones 162 + menores, o, en el caso de cambios grandes y controvertidos, continuar 163 + durante años. Gran parte de la frustración de los desarrolladores proviene 164 + de la falta de compresión de este proceso o de sus intentos de eludirlo. 165 + 166 + Con la esperanza de reducir esa frustración, este documento describirá 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 169 + tratamiento mucho más detallado vendrá en secciones posteriores. 170 + 171 + Las etapas por las que pasa un parche son, generalmente: 172 + 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 176 + mejor hacer este trabajo de manera abierta si es posible; puede ahorrar 177 + mucho tiempo rediseñando las cosas más tarde. 178 + 179 + - Revisión inicial. Los parches se publican en la lista de correo 180 + relevante y los desarrolladores en esa lista responden con cualquier 181 + comentario que puedan tener. Este proceso debería revelar cualquier 182 + problema importante con un parche si todo va bien. 183 + 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 186 + subsistema relevante – aunque esta aceptación no es una garantía de 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 189 + a continuación). Cuando el proceso funciona, este paso conduce a una 190 + revisión exhaustiva del parche y al descubrimiento de cualquier 191 + problema resultante de la integración de este parche con el trabajo 192 + realizado por otros. 193 + 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 196 + prioridad. Si su parche está recibiendo comentarios sobre los cambios 197 + que se necesitan, debería realizar esos cambios o justificar por qué 198 + no deberían realizarse. Si su parche no tiene quejas de revisión, pero 199 + no está siendo fusionado por el maintainer apropiado del subsistema o 200 + del driver, debe ser persistente en la actualización del parche 201 + al kernel actual para que se aplique limpiamente y seguir enviándolo 202 + para su revisión y fusión. 203 + 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 207 + que el desarrollador responda a estos y solucione cualquier problema 208 + que surja. 209 + 210 + - Lanzamiento estable. El número de usuarios potencialmente afectados por 211 + el parche es ahora grande, por lo que, una vez más, pueden surgir 212 + nuevos problemas. 213 + 214 + - Mantenimiento a largo plazo. Si bien un desarrollador puede olvidarse 215 + del código después de fusionarlo, ese comportamiento tiende a dejar 216 + una impresión negativa en la comunidad de desarrollo. Fusionar el 217 + código elimina parte de la carga de mantenimiento; otros solucionarán 218 + los problemas causados por los cambios en la API. Sin embargo, el 219 + desarrollador original debe seguir asumiendo la responsabilidad del 220 + código si quiere seguir siendo útil a largo plazo. 221 + 222 + Uno de los peores errores cometidos por los desarrolladores del kernel 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 225 + frustración de todos los involucrados. 226 + 227 + Cómo se integran los parches en el kernel 228 + ----------------------------------------- 229 + 230 + Hay exactamente una persona que puede fusionar parches en el repositorio 231 + mainline del kernel: Linus Torvalds. Pero, por ejemplo, de los más de 232 + 9,500 parches que se incluyeron en el kernel 2.6.38, solo 112 (alrededor 233 + del 1.3%) fueron elegidos directamente por Linus mismo. El proyecto del 234 + kernel ha crecido mucho desde hace tiempo a un tamaño en el que ningún 235 + desarrollador individual podría inspeccionar y seleccionar todos los 236 + parches sin ayuda. La forma que los desarrolladores del kernel han 237 + abordado este crecimiento es a través del uso de un sistema jerárquico 238 + alrededor de una cadena de confianza. 239 + 240 + La base de código del kernel se descompone lógicamente en un conjunto de 241 + subsistemas: redes, soporte de arquitectura especifica, gestión de 242 + memoria, dispositivos de video, etc. La mayoría de los subsistemas tienen 243 + un maintainer designado, un desarrollador que tiene la responsabilidad 244 + general del código dentro de ese subsistema. Estos maintainers 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 247 + el kernel mainline. 248 + 249 + Cada uno de los maintainers del subsistema administra su propia versión 250 + del árbol de fuentes del kernel, generalmente (pero, ciertamente no 251 + siempre) usando la herramienta de administración de código fuente de git. 252 + Herramientas como git (y herramientas relacionadas como quilt o mercurial) 253 + permiten a los maintainers realizar un seguimiento de una lista de 254 + parches, incluida la información de autoría y otros metadatos. En 255 + cualquier momento, el maintainer puede identificar qué parches de su 256 + repositorio no se encuentran en el mainline. 257 + 258 + Cuando se abre la ventana de fusión, los maintainers de nivel superior 259 + le pedirán a Linus que “extraiga” los parches que han seleccionado para 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 262 + mainline. La cantidad de atención que Linus presta a los parches 263 + específicos recibidos en una operación de extracción varia. Está claro 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 266 + defectuosos al upstream. 267 + 268 + Los maintainers de subsistemas, a su vez, pueden extraer parches de otros 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 271 + dispositivos de red, redes inalámbricas, etc. Esta cadena de repositorios 272 + puede ser arbitrariamente larga, aunque rara vez supera los dos o tres 273 + enlaces. Dado que cada maintainer de la cadena confía en los que 274 + administran árboles de nivel inferior, este proceso se conoce como la 275 + “cadena de confianza”. 276 + 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 279 + directamente a Linus no es normalmente la forma correcta de hacerlo. 280 + 281 + Árboles siguientes (next) 282 + ------------------------- 283 + 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 286 + alguien quiere ver todos los parches que se están preparando para la 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 289 + del que preocuparse; un parche que cambia un prototipo de función del 290 + núcleo del kernel, por ejemplo, entrará en conflicto con cualquier otro 291 + parche que utilice la forma anterior de esa función. Los revisores y 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 294 + extraer cambios de todos los árboles de subsistemas interesantes, pero 295 + eso sería un trabajo tedioso y propenso a errores. 296 + 297 + La respuesta viene en forma de árboles -next, donde los árboles de 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 300 + de la memoria, que es como comenzó). El árbol “-mm” integra parches 301 + de una larga lista de árboles de subsistemas; también tiene algunos 302 + parches destinados a ayudar con la depuración. 303 + 304 + Más allá de eso, -mm contiene una colección significativa de parches 305 + que han sido seleccionados directamente por Andrew. Estos parches pueden 306 + haber sido publicados en una lista de correo o aplicarse a una parte del 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. 315 + 316 + El parche -mm actual está disponible en el directorio “mmotm” (-mm 317 + del momento) en: 318 + 319 + https://www.ozlabs.org/~akpm/mmotm/ 320 + 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 323 + compile. 324 + 325 + El árbol principal para la fusión de parches del siguiente ciclo es 326 + linux-next, mantenido por Stephen Rothwell. El árbol linux-next es, por 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: 331 + 332 + https://www.kernel.org/pub/linux/kernel/next/ 333 + 334 + Linux-next se ha convertido en una parte integral del proceso de 335 + desarrollo del kernel; todos los parches fusionados durante una ventana 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. 338 + 339 + Árboles de staging 340 + ------------------ 341 + 342 + El árbol de fuentes del kernel contiene el directorio drivers/staging/, 343 + donde residen muchos subdirectorios para drivers o sistemas de archivos 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 346 + completados, se pueden mover al kernel propiamente dicho. Esta es una 347 + forma de realizar un seguimiento de los drivers drivers que no están a la 348 + altura de la codificación o los estándares de calidad del kernel de 349 + Linux, pero que las personas pueden querer usarlos y realizar un 350 + seguimiento del desarrollo. 351 + 352 + Greg Kroah-Hartman mantiene actualmente el árbol de staging. Los drivers 353 + que aun necesitan trabajo se le envían, y cada driver tiene su propio 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 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 359 + que los drivers que contribuyen a staging deben, como mínimo, compilarse 360 + correctamente. 361 + 362 + El staging puede ser una forma relativamente fácil de conseguir nuevos 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 366 + progreso regular eventualmente será eliminado. Los distribuidores también 367 + tienden a ser relativamente reacios a habilitar los drivers de staging. 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. 370 + 371 + Herramientas 372 + ------------ 373 + 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 377 + hace sin herramientas apropiadamente potentes. Los tutoriales sobre cómo 378 + usar estas herramientas están mucho más allá del alcance de este 379 + documento, pero hay espacio para algunos consejos. 380 + 381 + Con mucho, el sistema de gestión de código fuente dominante utilizado 382 + por la comunidad del kernel es git. Git es uno de los varios sistemas de 383 + control de versiones distribuidos que se están desarrollando en la 384 + comunidad de software libre. Está bien ajustado para el desarrollo de 385 + kernel, ya que funciona bastante bien cuando se trata de grandes 386 + repositorios y grandes cantidades de parches. También tiene la reputación 387 + de ser difícil de aprender y usar, aunque ha mejorado con el tiempo. 388 + Algún tipo de familiaridad con git es casi un requisito para los 389 + desarrolladores del kernel; incluso si no lo usan para su propio 390 + trabajo, necesitarán git para mantenerse al día con lo que otros 391 + desarrolladores (y el mainline) están haciendo. 392 + 393 + Git ahora está empaquetado por casi todas las distribuciones de Linux. 394 + Hay una página de inicio en: 395 + 396 + https://git-scm.com/ 397 + 398 + Esa página tiene punteros a documentación y tutoriales. 399 + 400 + Entre los desarrolladores de kernel que no usan git, la opción más 401 + popular es casi con certeza Mercurial: 402 + 403 + https://www.selenic.com/mercurial/ 404 + 405 + Mercurial comparte muchas características con git, pero proporciona una 406 + interfaz que muchos encuentran más fácil de usar. 407 + 408 + Otra herramienta que vale la pena conocer es Quilt: 409 + 410 + https://savannah.nongnu.org/projects/quilt/ 411 + 412 + Quilt es un sistema de gestión de parches, en lugar de un sistema de 413 + gestión de código fuente. No rastrea el historial a lo largo del tiempo; 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 416 + principales maintainers de subsistemas utilizan Quilt para gestionar los 417 + parches destinados a ir upstream. Para la gestión de ciertos tipos de 418 + árboles (por ejemplo, -mm) Quilt es la mejor herramienta para el trabajo. 419 + 420 + Listas de correo 421 + ---------------- 422 + 423 + Una gran parte del trabajo de desarrollo del kernel de Linux se realiza a 424 + través de listas de correo. Es difícil ser un miembro plenamente funcional 425 + de la comunidad sin unirse al menos a una lista en algún parte. Pero las 426 + listas de correo de Linux también representan un peligro potencial para 427 + los desarrolladores, que corren el riesgo de quedar enterrados bajo una 428 + carga de correo electrónico, incumplir las convenciones utilizadas en las 429 + listas de Linux, o ambas cosas. 430 + 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: 433 + 434 + http://vger.kernel.org/vger-lists.html 435 + 436 + Sim embargo, hay listas alojadas en otros lugares; varios de ellos se 437 + encuentran en redhat.com/mailman/listinfo. 438 + 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 441 + puede alcanzar 500 mensajes por día, la cantidad de ruido es alta, la 442 + conversación puede ser muy técnica y los participantes no siempre se 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 445 + desarrolladores que eviten esta lista se perderán información importante. 446 + 447 + Hay algunos consejos que pueden ayudar a sobrevivir en el kernel de Linux: 448 + 449 + - Haga que la lista se entregue en una carpeta separada, en lugar de su 450 + buzón principal. Uno debe ser capaz de ignorar el flujo durante 451 + periodos prolongados. 452 + 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 455 + conversaciones prolongadas pueden alejarse del asunto original sin 456 + cambiar la línea de asunto del correo electrónico) por las personas 457 + que participan. 458 + 459 + - No alimente a los trolls. Si alguien está tratando de provocar una 460 + respuesta de enojo, ignórelos. 461 + 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 464 + ausencia de una razón solida (como una solicitud explícita), nunca debe 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 468 + a sus publicaciones. 469 + 470 + - Busque en los archivos de la lista (y en la red en su conjunto) antes 471 + de hacer preguntas. Algunos desarrolladores pueden impacientarse con 472 + las personas que claramente no han hecho sus deberes. 473 + 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 476 + práctica de poner su respuesta encima del texto citado al que está 477 + respondiendo.) Para obtener más información, consulte 478 + :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_interleaved_replies>`. 479 + 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 482 + desarrolladores de todos los subsistemas. 483 + 484 + El último punto, encontrar la lista de correo correcta, es una fuente 485 + común de errores para desarrolladores principiantes. Alguien que haga 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 488 + lugar, ya que esa es la lista frecuentada por la mayoría de los 489 + desarrolladores de redes. Existen otras listas para los subsistemas SCSI, 490 + video4linux, IDE, sistema de archivos, etc. El mejor lugar para buscar 491 + listas de correo es en el archivo MAINTAINERS incluido con el código 492 + fuente del kernel. 493 + 494 + Comenzar con el desarrollo del kernel 495 + ------------------------------------- 496 + 497 + Las preguntas sobre como comenzar con el proceso de desarrollo del kernel 498 + son comunes, tanto de individuos como de empresas. Igualmente comunes son 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. 501 + 502 + Las empresas a menudo buscan contratar desarrolladores conocidos para 503 + iniciar un grupo de desarrollo. De hecho, esta puede ser una técnica 504 + efectiva. Pero también tiende a ser caro y no hace mucho para crecer el 505 + grupo de desarrolladores de kernel experimentados. Es posible poner al 506 + día a los desarrolladores internos en el desarrollo de kernel de Linux, 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 509 + como la empresa, y que también puedan ayudar a educar a otros. A medio 510 + plazo, este es a menudo el enfoque más rentable. 511 + 512 + Los desarrolladores individuales, a menudo, comprensiblemente, no tienen 513 + un lugar para empezar. Comenzar con un proyecto grande puede ser 514 + intimidante; a menudo uno quiere probar las aguas con algo más pequeño 515 + primero. Este es el punto en el que algunos desarrolladores se lanzan a 516 + la creación de parches para corregir errores ortográficos o problemas 517 + menores de estilo de codificación. Desafortunadamente, dicho parches 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. 522 + 523 + Andrew Morton da este consejo (traducido) para los aspirantes a 524 + desarrolladores de kernel. 525 + 526 + :: 527 + 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 531 + de hacer esto es trabajar con otros para arreglar las cosas (¡esto 532 + puede requerir persistencia!), pero eso está bien, es parte del 533 + desarrollo del kernel. 534 + 535 + (https://lwn.net/Articles/283982/) 536 + 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 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 542 + comunidad de desarrollo.
+1
Documentation/translations/sp_SP/process/development-process.rst
··· 24 24 :maxdepth: 2 25 25 26 26 1.Intro 27 + 2.Process