diff options
Diffstat (limited to 'Documentation/translations/sp_SP')
21 files changed, 978 insertions, 12 deletions
diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst index c543b495c0..274ef4ad96 100644 --- a/Documentation/translations/sp_SP/index.rst +++ b/Documentation/translations/sp_SP/index.rst @@ -7,7 +7,7 @@ Traducción al español \kerneldocCJKoff -:maintainer: Carlos Bilbao <carlos.bilbao@amd.com> +:maintainer: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_disclaimer: diff --git a/Documentation/translations/sp_SP/memory-barriers.txt b/Documentation/translations/sp_SP/memory-barriers.txt index 27097a808c..153e571307 100644 --- a/Documentation/translations/sp_SP/memory-barriers.txt +++ b/Documentation/translations/sp_SP/memory-barriers.txt @@ -1,6 +1,6 @@ NOTE: This is a version of Documentation/memory-barriers.txt translated into -Spanish by Carlos Bilbao <carlos.bilbao@amd.com>. If you find any +Spanish by Carlos Bilbao <carlos.bilbao.osdev@gmail.com>. If you find any difference between this document and the original file or a problem with the translation, please contact the maintainer of this file. Please also note that the purpose of this file is to be easier to read for non English @@ -18,7 +18,7 @@ Documento original: David Howells <dhowells@redhat.com> Will Deacon <will.deacon@arm.com> Peter Zijlstra <peterz@infradead.org> -Traducido por: Carlos Bilbao <carlos.bilbao@amd.com> +Traducido por: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> Nota: Si tiene alguna duda sobre la exactitud del contenido de esta traducción, la única referencia válida es la documentación oficial en inglés. diff --git a/Documentation/translations/sp_SP/process/1.Intro.rst b/Documentation/translations/sp_SP/process/1.Intro.rst new file mode 100644 index 0000000000..9b92b6c852 --- /dev/null +++ b/Documentation/translations/sp_SP/process/1.Intro.rst @@ -0,0 +1,302 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/1.Intro.rst +:Translator: Avadhut Naik <avadhut.naik@amd.com> + +.. _sp_development_process_intro: + +Introducción +============ + +Resumen ejecutivo +----------------- + +El resto de esta sección cubre el alcance del proceso de desarrollo del +kernel y los tipos de frustraciones que los desarrolladores y sus +empleadores pueden encontrar allí. Hay muchas razones por las que el +código del kernel debe fusionarse con el kernel oficial (“mainline”), +incluyendo la disponibilidad automática para los usuarios, el apoyo de la +comunidad en muchas formas, y la capacidad de influir en la dirección del +desarrollo del kernel. El código contribuido al kernel de Linux debe +estar disponible bajo una licencia compatible con GPL. + +:ref:`sp_development_process` introduce el proceso de desarrollo, el ciclo +de lanzamiento del kernel y la mecánica de la "ventana de combinación" +(merge window). Se cubren las distintas fases en el desarrollo del parche, +la revisión y, el ciclo de fusión. Hay algunas discusiones sobre +herramientas y listas de correo. Se anima a los desarrolladores que deseen +comenzar con el desarrollo del kernel a encontrar y corregir errores como +ejercicio inicial. + +:ref:`sp_development_early_stage` cubre la planificación de proyectos en +etapas tempranas, con énfasis en involucrar a la comunidad de desarrollo +lo antes posible. + +:ref:`sp_development_coding` trata sobre el proceso de codificación. Se +discuten varios escollos encontrados por otros desarrolladores. Se cubren +algunos requisitos para los parches, y hay una introducción a algunas de +las herramientas que pueden ayudar a garantizar que los parches del kernel +sean correctos. + +:ref:`sp_development_posting` trata sobre el proceso de enviar parches para +su revisión. Para ser tomados en serio por la comunidad de desarrollo, +los parches deben estar correctamente formateados y descritos, y deben +enviarse al lugar correcto. Seguir los consejos de esta sección debería +ayudar a garantizar la mejor recepción posible para su trabajo. + +:ref:`sp_development_followthrough` cubre lo que sucede después de publicar +parches; el trabajo está lejos de terminar en ese momento. Trabajar con +revisores es una parte crucial del proceso de desarrollo; esta sección +ofrece varios consejos sobre cómo evitar problemas en esta importante +etapa. Se advierte a los desarrolladores que no asuman que el trabajo está +terminado cuando un parche se fusiona en mainline. + +:ref:`sp_development_advancedtopics` introduce un par de temas “avanzados”: +la administración de parches con git y la revisión de parches publicados +por otros. + +:ref:`sp_development_conclusion` concluye el documento con punteros a las +fuentes para obtener más información sobre el desarrollo del kernel. + +De qué trata este documento +--------------------------- + +El kernel de Linux, con más de 8 millones de líneas de código y más de +1000 colaboradores en cada versión, en uno de los proyectos de software +libre más grandes y activos que existen. Desde sus humildes comienzos en +1991, este kernel ha evolucionado hasta convertirse en el mejor componente +del sistema operativo que se ejecuta en reproductores de música digital +de bolsillo, PC de escritorio, las supercomputadoras más grandes que +existen y todo tipo de sistemas intermedios. Es una solución robusta, +eficiente, y escalable para casi cualquier situación. + +Con el crecimiento de Linux, ha llegado un aumento en el número de +desarrolladores (y empresas) que desean participar en su desarrollo. Los +vendedores de hardware quieren asegurarse de que Linux sea compatible con +sus productos, lo que hace que esos productos sean atractivos para los +usuarios de Linux. Los vendedores de sistemas embebidos, que utilizan +Linux como componente de un producto integrado, quieren que Linux sea lo +más capaz y adecuado posible para tarea en cuestión. Los distribuidores +y otros vendedores de software que basan sus productos en Linux tienen un +claro interés en las capacidades, el rendimiento, y la fiabilidad del +kernel de Linux. Y los usuarios finales, también, a menudo desearán +cambiar Linux para que se adapte mejor a sus necesidades. + +Una de las características más convincentes de Linux es que es accesible +a estos desarrolladores; cualquier persona con las habilidades necesarias +puede mejorar Linux e influir en la dirección de su desarrollo. Los +productos propietarios no pueden ofrecer este tipo de apertura, que es una +característica del proceso de software libre. Pero, en todo caso, el +kernel es aún más libre que la mayoría de los otros proyectos de software +libre. Un ciclo típico de desarrollo de kernel de tres meses puede +involucrar a más de 1000 desarrolladores que trabajan para más de 100 +empresas diferentes (o sin pertenecer a ninguna empresa). + +Trabajar con la comunidad de desarrollo del kernel no es especialmente +difícil. Pero, a pesar de eso, muchos colaboradores potenciales han +experimentado dificultades al tratar de hacer el trabajo del kernel. La +comunidad del kernel ha desarrollado sus propias formas distintivas de +operar, lo que le permite funcionar de manera fluida (y producir un +producto de alta calidad) en un entorno donde miles de líneas de código +se cambian todos los días. Por lo tanto, no es sorprendente que el +proceso de desarrollo del kernel de Linux difiera mucho de los métodos de +desarrollo propietarios. + +El proceso de desarrollo del kernel puede parecer extraño e intimidante +para los nuevos desarrolladores, pero hay buenas razones y una sólida +experiencia detrás de él. Un desarrollador que no entienda las formas de +la comunidad del kernel (o, peor aún, que intente burlarse o eludirlas) +tendrá una experiencia frustrante por delante. La comunidad de +desarrollo, si bien es servicial para aquellos que están tratando de +aprender, tiene poco tiempo para aquellos que no escuchan o que no se +preocupan por el proceso de desarrollo. + +Se espera que quienes lean este documento puedan evitar esa experiencia +frustrante. Hay mucho material aquí, pero el esfuerzo que implica leerlo +será recompensado en poco tiempo. La comunidad de desarrollo siempre +necesita desarrolladores que ayudan a mejorar el kernel; el siguiente +texto debería ayudarle – o a quienes trabajan para usted, a unirse a +nuestra comunidad. + +Créditos +-------- + +Este documento fue escrito por Jonathan Corbet, corbet@lwn.net. Ha sido +mejorado por los comentarios de Johannes Berg, James Berry, Alex Chiang, +Roland Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur +Marsh, Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata y +Jochen Voß. +Este trabajo fue respaldado por la Fundación Linux; gracias especialmente +a Amanda McPherson, quien reconoció el valor de este esfuerzo e hizo que +todo sucediera. + +Importancia de integrar el código en el mainline +------------------------------------------------ + +Algunas empresas y desarrolladores ocasionalmente se preguntan por qué +deberían molestarse en aprender cómo trabajar con la comunidad del +kernel y obtener su código en el kernel mainline (el “mainline” es el +kernel mantenido por Linus Torvalds y utilizado como base por los +distribuidores de Linux. A corto plazo, contribuir con código puede +parecer un gasto evitable; parece más fácil mantener el código separado +y dar soporte a los usuarios directamente. La verdad del asunto es que +mantener el código separado (“fuera del árbol”) es pan para hoy y hambre +para mañana. + +Para ilustrar los costos del código fuera-del-árbol, aquí hay algunos +aspectos relevantes del proceso de desarrollo del kernel. La mayoría de +estos se discutirán con mayor detalle más adelante en este documento. +Considerar: + +- El código que se ha fusionado con el kernel mainline está disponible + para todos los usuarios de Linux. Estará presente automáticamente en + todas las distribuciones que lo habiliten. No hay necesidad de discos + de controladores, descargas, o las molestias de admitir múltiples + versiones de múltiples distribuciones; todo simplemente funciona, para + el desarrollador y para el usuario. La incorporación al mainline + resuelve un gran número de problemas de distribución y soporte. + +- Mientras los desarrolladores del kernel se esfuerzan por mantener una + interfaz estable para el espacio de usuario, la API interna de kernel + está en constante cambio. La falta de una interfaz interna estable es + una decisión deliberada de diseño; permite realizar mejoras + fundamentales en cualquier momento y da como resultado un código de + mayor calidad. Pero uno resultado de esa política es que cualquier + código fuera-del-árbol requiere un mantenimiento constante si va a + funcionar con los nuevos kernels. Mantener el código fuera-del-árbol + requiere una cantidad significativa de trabajo sólo para que ese código + siga funcionando. + + En su lugar, el código en el mainline no requiere este trabajo como + resultado de una regla simple que requiere que cualquier desarrollador + que realice un cambio en la API también corrija cualquier código que + se rompa como resultado de ese cambio. Así que, el código fusionado en + el mainline tiene costos de mantenimiento significativamente más bajos. + +- Más allá de eso, el código que está en el kernel a menudo será + mejorado por otros desarrolladores. Resultados sorprendentes pueden + provenir de capacitar a su comunidad de usuarios y clientes para mejorar + su producto. + +- El código del kernel se somete a revisión, tanto antes como después + de fusionarse con el mainline. No importa cuán fuertes sean las + habilidades del desarrollador original, este proceso de revisión + invariablemente encuentra formas en las que se puede mejorar el código. + A menudo la revisión encuentra errores graves y problemas de seguridad. + Esto es especialmente cierto para el código que se ha desarrollado en + un entorno cerrado; dicho código se beneficia fuertemente de la + revisión por desarrolladores externos. El código fuera-del-árbol es + de menor calidad. + +- La participación en el proceso de desarrollo es su manera de influir en + la dirección del desarrollo del kernel. Los usuarios que se quejan + desde el sofa son escuchados, pero los desarrolladores activos tienen + una voz más fuerte – y la capacidad de implementar cambios que hacen + que el kernel funcione mejor para sus necesidades. + +- Cuando el código se mantiene por separado, siempre existe la posibilidad + de que un tercero contribuya a una implementación diferente de una + característica similar. Si eso sucede, conseguir que su código + fusionado será mucho más difícil – hasta el punto de la imposibilidad. + Entonces se enfrentará a las desagradables alternativas de (1) mantener + una característica no estándar fuera del árbol indefinidamente, o + (2) abandonar su código y migrar sus usuarios a la versión en el árbol. + +- La contribución del código es la acción fundamental que hace que todo + el proceso funcione. Al contribuir con su código, puede agregar nuevas + funcionalidades al kernel y proporcionar capacidades y ejemplos que son + útiles para otros desarrolladores del kernel. Si ha desarrollado código + para Linux (o está pensando en hacerlo), claramente tiene un interés + en el éxito continuo de esta plataforma; contribuir con código es una + de las mejores maneras de ayudar a garantizar ese éxito. + +Todo el razonamiento anterior se aplica a cualquier código de kernel +fuera-del-árbol, incluido el código que se distribuye en forma propietaria +y únicamente en binario. Sin embargo, hay factores adicionales que deben +tenerse en cuenta antes de considerar cualquier tipo de distribución de +código de kernel únicamente en binario. Estos incluyen: + +- Las cuestiones legales en torno a la distribución de módulos + propietarios del kernel son, en el mejor de los casos, confusas; + bastantes titulares de derechos de autor del kernel creen que la + mayoría de los módulos binarios son productos derivados del kernel y + que, como resultado, su distribución es una violación de la licencia + Pública General de GNU (sobre la que se dirá más adelante). El autor + de este texto no es abogado, y nada en este documento puede considerarse + asesoramiento legal. Solo los tribunales pueden determinar el verdadero + estatus legal de los módulos de código cerrado. Pero la incertidumbre + que acecha a esos módulos está ahí a pesar de todo. + +- Los módulos binarios aumentan enormemente la dificultad de depurar + problemas del kernel, hasta el punto de que la mayoría de los + desarrolladores del kernel ni siquiera lo intentarán. Por lo tanto, + la distribución de módulos únicamente en binario hará que sea más + difícil para sus usuarios obtener soporte de la comunidad. + +- El soporte también es más difícil para los distribuidores de módulos + únicamente en binario, que deben proporcionar una versión del módulo + para cada distribución y cada versión del kernel que deseen apoyar. + Podría requerir docenas de compilaciones de un solo módulo para + proporcionar una cobertura razonablemente completa, y sus usuarios + tendrán que actualizar su módulo por separado cada vez que + actualicen su kernel. + +- Todo lo que se dijo anteriormente sobre la revisión de código se aplica + doblemente al código cerrado. Dado que este código no está disponible + en absoluto, no puede haber sido revisado por la comunidad y, sin duda, + tendrá serios problemas. + +Los fabricantes de sistemas embebidos, en particular, pueden verse +tentados a ignorar gran parte de lo que se ha dicho en esta sección +creyendo que están enviando un producto autónomo que utiliza una +versión de kernel congelada y no requiere más desarrollo después de su +lanzamiento. Este argumento desaprovecha el valor de la revisión +generalizad del código y el valor de permitir que sus usuarios agreguen +capacidades a su producto. Pero estos productos también tienen una vida +comercial limitada, después de la cual se debe lanzar una nueva versión. +En ese punto, los vendedores cuyo código esté en el mainline y bien +mantenido estarán en una posición mucho mejor para preparar el nuevo +producto rápidamente para el mercado. + +Licencias +--------- + +El código se contribuye al kernel de Linux bajo varias licencias, pero +todo el código debe ser compatible con la versión 2 de la Licencia +Pública General de GNU (GPLv2), que cubre la distribución del kernel. En +la práctica, esto significa que todas las contribuciones de código están +cubiertas ya sea por la GPLv2 (con, opcionalmente, un lenguaje que permite +la distribución en versiones posteriores de la GPL) o por la licencia BSD +de tres cláusulas. Cualquier contribución que no esté cubierta por una +licencia compatible no será aceptada en el kernel. + +No se requieren (ni se solicitan) cesiones de derechos de autor para el +código aportado al kernel. Todo el código fusionado en el kernel +mainline conserva su propiedad original; como resultado, el kernel ahora +tiene miles de propietarios. + +Una implicación de esta estructura de propiedad es que cualquier intento +de cambiar la licencia del kernel está condenado a un fracaso casi seguro. +Hay pocos escenarios prácticos en los que se pueda obtener el acuerdo de +todos los titulares de derechos de autor (o eliminar su código del +kernel). Así que, en particular, no hay perspectivas de una migración a +la versión 3 de la GPL en un futuro previsible. + +Es imperativo que todo el código aportado al kernel sea legítimamente +software libre. Por esa razón, no se aceptará código de colaboradores +anónimos (o seudónimos). Todos los colaboradores están obligados a +“firmar” su código, indicando que el código puede ser distribuido con +el kernel bajo la GPL. El código que no ha sido licenciado como software +libre por su propietario, o que corre el riesgo de crear problemas +relacionadas con los derechos de autor para el kernel (como el código que +se deriva de esfuerzos de ingeniería inversa que carecen de las garantías +adecuadas) no puede ser contribuido. + +Las preguntas sobre cuestiones relacionadas con los derechos de autor son +comunes en las listas de correo de desarrollo de Linux. Normalmente, estas +preguntas no recibirán escasez de respuestas, pero se debe tener en cuenta +que las personas que responden a esas preguntas no son abogados y no +pueden proporcionar consejo legal. Si tiene preguntas legales relacionadas +con el código fuente de Linux, no hay sustituto para hablar con un abogado +que entienda este campo. Confiar en las respuestas obtenidas en listas +técnicas de correo es un asunto arriesgado. diff --git a/Documentation/translations/sp_SP/process/2.Process.rst b/Documentation/translations/sp_SP/process/2.Process.rst new file mode 100644 index 0000000000..5993eed715 --- /dev/null +++ b/Documentation/translations/sp_SP/process/2.Process.rst @@ -0,0 +1,542 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/2.Process.rst +:Translator: Avadhut Naik <avadhut.naik@amd.com> + +.. _sp_development_process: + +Cómo funciona el proceso de desarrollo +====================================== + +El desarrollo del kernel de Linux a principios de la década de 1990 fue +un asunto relajado, con un número relativamente pequeño de usuarios y +desarrolladores involucrados. Con una base de usuarios en los millones y +alrededor de 2,000 desarrolladores involucrados durante un año, el kernel +ha tenido que adaptar varios procesos para mantener el desarrollo sin +problemas. Se requiere una comprensión solida de cómo funciona el proceso +para ser una parte efectiva del mismo. + +El panorama general +------------------- + +Los desarrolladores del kernel utilizan un proceso de lanzamiento basado +en el tiempo de manera flexible, con uno nuevo lanzamiento principal del +kernel ocurriendo cada dos o tres meses. El historial reciente de +lanzamientos se ve así: + + ====== ================== + 5.0 Marzo 3, 2019 + 5.1 Mayo 5, 2019 + 5.2 Julio 7, 2019 + 5.3 Septiembre 15, 2019 + 5.4 Noviembre 24, 2019 + 5.5 Enero 6, 2020 + ====== ================== + +Cada lanzamiento 5.x es un lanzamiento principal del kernel con nuevas +características, cambios internos en la API y más. Un lanzamiento típico +puede contener alrededor de 13,000 conjuntos de cambios incluyendo en +varias centenas de miles de líneas de código. 5.x es la vanguardia del +desarrollo del kernel de Linux; el kernel utiliza un modelo de desarrollo +continuo que está integrando continuamente cambios importantes. + +Se sigue una disciplina relativamente sencilla con respecto a la fusión +de parches para cada lanzamiento. Al comienzo de cada ciclo de desarrollo, +se dice que la "merge window" (ventana de fusión) está abierta. En ese +momento, el código que se considera lo suficientemente estable (y que es +aceptado por la comunidad de desarrollo) se fusiona en el kernel mainline. +La mayor parte de los cambios para un nuevo ciclo de desarrollo (y todos +los cambios principales) se fusionarán durante este tiempo, a un ritmo +cercano a los 1,000 cambios (“parches” o “conjuntos de cambios”) por +día. + +(Aparte, vale la pena señalar que los cambios integrados durante la +ventana de fusión no surgen de la nada; han sido recolectados, probados +y montados con anticipación. Como funciona ese proceso se describirá en +detalle más adelante). + +La ventana de fusión dura aproximadamente dos semanas. Al final de este +tiempo, Linux Torvalds declarará que la ventana está cerrada y publicará +el primero de los kernels “rc”. Para el kernel destinado a ser 5.6, por +ejemplo, el lanzamiento al final de la ventana de fusión se llamará +5.6-rc1. El lanzamiento -rc1 señala que el tiempo para fusionar nuevas +características ha pasado y que el tiempo para estabilizar el siguiente +kernel ha comenzado. + +Durante las próximas seis a diez semanas, solo los parches que solucionen +problemas deben enviarse al mainline. En ocasiones, se permitirá un cambio +más significativo, pero tales ocasiones son raras; los desarrolladores que +intentan fusionar nuevas características fuera de la ventana de fusión +suelen recibir una recepción poco amistosa. Como regla general, si se +pierde la ventana de fusión de una característica determinada, lo mejor +que puede hacer es esperar al siguiente ciclo de desarrollo. (Se hace una +excepción ocasional para los drivers de hardware que no se admitía +anteriormente; si no afectan a ningún código en árbol, no pueden causar +regresiones y debería ser seguro agregarlos en cualquier momento). + +A medida que las correcciones se abren paso en el mainline, la tasa de +parches se ralentizará con el tiempo. Linus lanza nuevos kernels -rc +aproximadamente una vez a la semana; una serie normal llegará a algún +punto entre -rc6 y -rc9 antes de que se considere que el kernel es +suficientemente estable y realice el lanzamiento final. En ese momento, +todo el proceso vuelve a empezar. + +Como ejemplo, así fue el ciclo de desarrollo de 5.4 (todas las fechas son +de 2019): + + ============== ======================================= + Septiembre 15 5.3 lanzamiento estable + Septiembre 30 5.4-rc1, la ventana de fusion se cierra + Octubre 6 5.4-rc2 + Octubre 13 5.4-rc3 + Octubre 20 5.4-rc4 + Octubre 27 5.4-rc5 + Noviembre 3 5.4-rc6 + Noviembre 10 5.4-rc7 + Noviembre 17 5.4-rc8 + Noviembre 24 5.4 lanzamiento estable + ============== ======================================= + +¿Cómo deciden los desarrolladores cuándo cerrar el ciclo de desarrollo +y crear el lanzamiento estable? La métrica más significativa utilizada +es la lista de regresiones de lanzamientos anteriores. Ningunos errores +son bienvenidos, pero aquellos que rompen sistemas que funcionaron en el +pasado se consideran especialmente graves. Por esta razón, los parches +que causan regresiones se ven con malos ojos y es bastante probable que +se reviertan durante el periodo de estabilización. + +El objetivo de los desarrolladores es corregir todas las regresiones +conocidas antes de que se realice el lanzamiento estable. En el mundo +real, este tipo de perfección es difícil de lograr; hay demasiados +variables en un proyecto de este tamaño. Llega un punto en el que +retrasar el lanzamiento final solo empeora el problema; la pila de cambios +que esperan la siguiente ventana de fusión crecerá, creando aún más +regresiones la próxima vez. Por lo tanto, la mayoría de los kernels 5.x +se lanzan con un punado de regresiones conocidas, aunque, con suerte, +ninguna de ellas es seria. + +Una vez que se realiza un lanzamiento estable, su mantenimiento continuo +se transfiere al “equipo estable”, actualmente encabezado por Greg +Kroah-Hartman. El equipo estable lanzará actualizaciones ocasionales al +lanzamiento estable utilizando el esquema de numeración 5.x.y. Para ser +considerado para un lanzamiento de actualización, un parche debe +(1) corregir un error significativo y (2) ya estar fusionado en el +mainline para el siguiente kernel de desarrollo. Por lo general, los +kernels recibirán actualizaciones estables durante un poco más de un +ciclo de desarrollo después de su lanzamiento inicial. Así, por ejemplo, +la historia del kernel 5.2 se veía así (todas las fechas en 2019): + + ============== =============================== + Julio 7 5.2 lanzamiento estable + Julio 14 5.2.1 + Julio 21 5.2.2 + Julio 26 5.2.3 + Julio 28 5.2.4 + Julio 31 5.2.5 + ... ... + Octubre 11 5.2.21 + ============== =============================== + +5.2.21 fue la última actualización estable del lanzamiento 5.2. + +Algunos kernels se designan como kernels “a largo plazo”; recibirán +soporte durante un periodo más largo. Consulte el siguiente enlace para +obtener la lista de versiones activas del kernel a largo plazos y sus +maintainers: + + https://www.kernel.org/category/releases.html + +La selección de un kernel para soporte a largo plazo es puramente una +cuestión de que un maintainer tenga la necesidad y el tiempo para +mantener ese lanzamiento. No hay planes conocidos para ofrecer soporte a +largo plazo para ningún lanzamiento especifico próximo. + +Ciclo de vida de un parche +-------------------------- + +Los parches no van directamente desde el teclado del desarrollador al +kernel mainline. Hay, en cambio, un proceso algo complicado (aunque algo +informal) diseñado para garantizar que cada parche sea revisado en cuanto +a calidad y que cada parche implemente un cambio que es deseable tener en +el mainline. Este proceso puede ocurrir rápidamente para correcciones +menores, o, en el caso de cambios grandes y controvertidos, continuar +durante años. Gran parte de la frustración de los desarrolladores proviene +de la falta de compresión de este proceso o de sus intentos de eludirlo. + +Con la esperanza de reducir esa frustración, este documento describirá +cómo un parche entra en el kernel. Lo que sigue a continuación es una +introducción que describe el proceso de una manera tanto idealizada. Un +tratamiento mucho más detallado vendrá en secciones posteriores. + +Las etapas por las que pasa un parche son, generalmente: + + - Diseño. Aquí es donde se establecen los requisitos reales para el + parche – y la forma en que se cumplirán esos requisitos. El trabajo + de diseño a menudo se realiza sin involucrar a la comunidad, pero es + mejor hacer este trabajo de manera abierta si es posible; puede ahorrar + mucho tiempo rediseñando las cosas más tarde. + + - Revisión inicial. Los parches se publican en la lista de correo + relevante y los desarrolladores en esa lista responden con cualquier + comentario que puedan tener. Este proceso debería revelar cualquier + problema importante con un parche si todo va bien. + + - Revisión más amplia. Cuando el parche se acerca a estar listo para su + inclusión en el mainline, debe ser aceptado por un maintainer del + subsistema relevante – aunque esta aceptación no es una garantía de + que el parche llegara hasta el mainline. El parche aparecerá en el + árbol de subsistemas del maintainer y en los árboles -next (descritos + a continuación). Cuando el proceso funciona, este paso conduce a una + revisión exhaustiva del parche y al descubrimiento de cualquier + problema resultante de la integración de este parche con el trabajo + realizado por otros. + + - Tenga en cuenta que la mayoría de los maintainers también tienen + trabajos diurnos, por lo que fusionar su parche no puede ser su máxima + prioridad. Si su parche está recibiendo comentarios sobre los cambios + que se necesitan, debería realizar esos cambios o justificar por qué + no deberían realizarse. Si su parche no tiene quejas de revisión, pero + no está siendo fusionado por el maintainer apropiado del subsistema o + del driver, debe ser persistente en la actualización del parche + al kernel actual para que se aplique limpiamente y seguir enviándolo + para su revisión y fusión. + + - Fusión en el mainline. Eventualmente, un parche exitoso se fusionará + en el repositorio mainline administrado por Linux Torvalds. Mas + comentarios y/o problemas pueden surgir en este momento; es importante + que el desarrollador responda a estos y solucione cualquier problema + que surja. + + - Lanzamiento estable. El número de usuarios potencialmente afectados por + el parche es ahora grande, por lo que, una vez más, pueden surgir + nuevos problemas. + + - Mantenimiento a largo plazo. Si bien un desarrollador puede olvidarse + del código después de fusionarlo, ese comportamiento tiende a dejar + una impresión negativa en la comunidad de desarrollo. Fusionar el + código elimina parte de la carga de mantenimiento; otros solucionarán + los problemas causados por los cambios en la API. Sin embargo, el + desarrollador original debe seguir asumiendo la responsabilidad del + código si quiere seguir siendo útil a largo plazo. + +Uno de los peores errores cometidos por los desarrolladores del kernel +(o sus empleadores) es tratar de reducir el proceso a un solo paso de +“fusión en el mainline”. Este enfoque conduce invariablemente a la +frustración de todos los involucrados. + +Cómo se integran los parches en el kernel +----------------------------------------- + +Hay exactamente una persona que puede fusionar parches en el repositorio +mainline del kernel: Linus Torvalds. Pero, por ejemplo, de los más de +9,500 parches que se incluyeron en el kernel 2.6.38, solo 112 (alrededor +del 1.3%) fueron elegidos directamente por Linus mismo. El proyecto del +kernel ha crecido mucho desde hace tiempo a un tamaño en el que ningún +desarrollador individual podría inspeccionar y seleccionar todos los +parches sin ayuda. La forma que los desarrolladores del kernel han +abordado este crecimiento es a través del uso de un sistema jerárquico +alrededor de una cadena de confianza. + +La base de código del kernel se descompone lógicamente en un conjunto de +subsistemas: redes, soporte de arquitectura especifica, gestión de +memoria, dispositivos de video, etc. La mayoría de los subsistemas tienen +un maintainer designado, un desarrollador que tiene la responsabilidad +general del código dentro de ese subsistema. Estos maintainers de +subsistemas son los guardianes (en cierto modo) de la parte del kernel que +gestionan; son los que (usualmente) aceptarán un parche para incluirlo en +el kernel mainline. + +Cada uno de los maintainers del subsistema administra su propia versión +del árbol de fuentes del kernel, generalmente (pero, ciertamente no +siempre) usando la herramienta de administración de código fuente de git. +Herramientas como git (y herramientas relacionadas como quilt o mercurial) +permiten a los maintainers realizar un seguimiento de una lista de +parches, incluida la información de autoría y otros metadatos. En +cualquier momento, el maintainer puede identificar qué parches de su +repositorio no se encuentran en el mainline. + +Cuando se abre la ventana de fusión, los maintainers de nivel superior +le pedirán a Linus que “extraiga” los parches que han seleccionado para +fusionar de sus repositorios. Si Linus está de acuerdo, el flujo de +parches fluirá hacia su repositorio, convirtiéndose en parte del kernel +mainline. La cantidad de atención que Linus presta a los parches +específicos recibidos en una operación de extracción varia. Está claro +que, a veces, examina bastante de cerca. Pero, como regla general, Linus +confía en que los maintainers del subsistema no envíen parches +defectuosos al upstream. + +Los maintainers de subsistemas, a su vez, pueden extraer parches de otros +maintainers. Por ejemplo, el árbol de red se construye a partir de +parches que se acumulan primero en arboles dedicados a drivers de +dispositivos de red, redes inalámbricas, etc. Esta cadena de repositorios +puede ser arbitrariamente larga, aunque rara vez supera los dos o tres +enlaces. Dado que cada maintainer de la cadena confía en los que +administran árboles de nivel inferior, este proceso se conoce como la +“cadena de confianza”. + +Claramente, en un sistema como este, lograr que los parches se integren +en el kernel depende de encontrar el maintainer adecuado. Enviar parches +directamente a Linus no es normalmente la forma correcta de hacerlo. + +Árboles siguientes (next) +------------------------- + +La cadena de árboles de subsistemas guía el flujo de parches en el +kernel, pero también plantea una pregunta interesante: ¿Qué pasa si +alguien quiere ver todos los parches que se están preparando para la +próxima ventana de fusión? Los desarrolladores estarán interesados en +saber que otros cambios están pendientes para ver si hay algún conflicto +del que preocuparse; un parche que cambia un prototipo de función del +núcleo del kernel, por ejemplo, entrará en conflicto con cualquier otro +parche que utilice la forma anterior de esa función. Los revisores y +probadores quieren tener acceso a los cambios en su forma integrada antes +de que todos esos cambios se integren en el kernel mainline. Uno podría +extraer cambios de todos los árboles de subsistemas interesantes, pero +eso sería un trabajo tedioso y propenso a errores. + +La respuesta viene en forma de árboles -next, donde los árboles de +subsistemas se recopilan para pruebas y revisiones. El más antiguo de +estos árboles, mantenido por Andrew Morton, se llama “-mm” (por gestión +de la memoria, que es como comenzó). El árbol “-mm” integra parches +de una larga lista de árboles de subsistemas; también tiene algunos +parches destinados a ayudar con la depuración. + +Más allá de eso, -mm contiene una colección significativa de parches +que han sido seleccionados directamente por Andrew. Estos parches pueden +haber sido publicados en una lista de correo o aplicarse a una parte del +kernel para la que no hay un árbol de subsistemas designado. Como +resultado, -mm funciona como una especie de árbol de subsistemas de +último recurso; si no hay otro camino obvio para un parche en el mainline, +es probable que termine en -mm. Los parches misceláneos que se acumulan +en -mm eventualmente se enviarán a un árbol de subsistema apropiado o se +enviarán directamente a Linus. En un ciclo de desarrollo típico, +aproximadamente el 5-10% de los parches que van al mainline llegan allí +a través de -mm. + +El parche -mm actual está disponible en el directorio “mmotm” (-mm +del momento) en: + + https://www.ozlabs.org/~akpm/mmotm/ + +Sin embargo, es probable que el uso del árbol MMOTM sea una experiencia +frustrante; existe una posibilidad definitiva de que ni siquiera se +compile. + +El árbol principal para la fusión de parches del siguiente ciclo es +linux-next, mantenido por Stephen Rothwell. El árbol linux-next es, por +diseño, una instantánea de cómo se espera que se vea el mainline después +de que se cierre la siguiente ventana de fusión. Los árboles linux-next +se anuncian en las listas de correo linux-kernel y linux-next cuando se +ensamblan; Se pueden descargar desde: + + https://www.kernel.org/pub/linux/kernel/next/ + +Linux-next se ha convertido en una parte integral del proceso de +desarrollo del kernel; todos los parches fusionados durante una ventana +de fusión determinada deberían haber encontrado su camino en linux-next +en algún momento antes de que se abra la ventana de fusión. + +Árboles de staging +------------------ + +El árbol de fuentes del kernel contiene el directorio drivers/staging/, +donde residen muchos subdirectorios para drivers o sistemas de archivos +que están en proceso de ser agregados al árbol del kernel. Permanecen +en drivers/staging mientras aún necesitan más trabajo; una vez +completados, se pueden mover al kernel propiamente dicho. Esta es una +forma de realizar un seguimiento de los drivers drivers que no están a la +altura de la codificación o los estándares de calidad del kernel de +Linux, pero que las personas pueden querer usarlos y realizar un +seguimiento del desarrollo. + +Greg Kroah-Hartman mantiene actualmente el árbol de staging. Los drivers +que aun necesitan trabajo se le envían, y cada driver tiene su propio +subdirectorio en drivers/staging/. Junto con los archivos de origen del +driver, también debe haber un archivo TODO en el directorio. El archivo +TODO enumera el trabajo pendiente que el driver necesita para ser aceptado +en el kernel propiamente dicho, así como una lista de personas a las que +Cc’d para cualquier parche para el driver. Las reglas actuales exigen +que los drivers que contribuyen a staging deben, como mínimo, compilarse +correctamente. + +El staging puede ser una forma relativamente fácil de conseguir nuevos +drivers en el mainline donde, con suerte, llamarán la atención de otros +desarrolladores y mejorarán rápidamente. Sin embargo, la entrada en el +staging no es el final de la historia; el código que no está viendo +progreso regular eventualmente será eliminado. Los distribuidores también +tienden a ser relativamente reacios a habilitar los drivers de staging. +Por lo tanto, el staging es, en el mejor de los casos, una parada en el +camino para hacia convertirse en un apropiado driver del mainline. + +Herramientas +------------ + +Como se puede ver en el texto anterior, el proceso de desarrollo del +kernel depende en gran medida de la capacidad de dirigir colecciones de +parches en varias direcciones. Todo ello no funcionaría tan bien como lo +hace sin herramientas apropiadamente potentes. Los tutoriales sobre cómo +usar estas herramientas están mucho más allá del alcance de este +documento, pero hay espacio para algunos consejos. + +Con mucho, el sistema de gestión de código fuente dominante utilizado +por la comunidad del kernel es git. Git es uno de los varios sistemas de +control de versiones distribuidos que se están desarrollando en la +comunidad de software libre. Está bien ajustado para el desarrollo de +kernel, ya que funciona bastante bien cuando se trata de grandes +repositorios y grandes cantidades de parches. También tiene la reputación +de ser difícil de aprender y usar, aunque ha mejorado con el tiempo. +Algún tipo de familiaridad con git es casi un requisito para los +desarrolladores del kernel; incluso si no lo usan para su propio +trabajo, necesitarán git para mantenerse al día con lo que otros +desarrolladores (y el mainline) están haciendo. + +Git ahora está empaquetado por casi todas las distribuciones de Linux. +Hay una página de inicio en: + + https://git-scm.com/ + +Esa página tiene punteros a documentación y tutoriales. + +Entre los desarrolladores de kernel que no usan git, la opción más +popular es casi con certeza Mercurial: + + https://www.selenic.com/mercurial/ + +Mercurial comparte muchas características con git, pero proporciona una +interfaz que muchos encuentran más fácil de usar. + +Otra herramienta que vale la pena conocer es Quilt: + + https://savannah.nongnu.org/projects/quilt/ + +Quilt es un sistema de gestión de parches, en lugar de un sistema de +gestión de código fuente. No rastrea el historial a lo largo del tiempo; +en cambio, está orientado al seguimiento de un conjunto especifico de +cambios en relación con una base de código en evolución. Algunos de los +principales maintainers de subsistemas utilizan Quilt para gestionar los +parches destinados a ir upstream. Para la gestión de ciertos tipos de +árboles (por ejemplo, -mm) Quilt es la mejor herramienta para el trabajo. + +Listas de correo +---------------- + +Una gran parte del trabajo de desarrollo del kernel de Linux se realiza a +través de listas de correo. Es difícil ser un miembro plenamente funcional +de la comunidad sin unirse al menos a una lista en algún parte. Pero las +listas de correo de Linux también representan un peligro potencial para +los desarrolladores, que corren el riesgo de quedar enterrados bajo una +carga de correo electrónico, incumplir las convenciones utilizadas en las +listas de Linux, o ambas cosas. + +La mayoría de las listas de correo del kernel se ejecutan en +vger.kernel.org; la lista principal se puede encontrar en: + + http://vger.kernel.org/vger-lists.html + +Sim embargo, hay listas alojadas en otros lugares; varios de ellos se +encuentran en redhat.com/mailman/listinfo. + +La lista de correo principal para el desarrollo del kernel es, por +supuesto, linux-kernel. Esta lista es un lugar intimidante; el volumen +puede alcanzar 500 mensajes por día, la cantidad de ruido es alta, la +conversación puede ser muy técnica y los participantes no siempre se +preocupan por mostrar un alto grado de cortesía. Pero no hay otro lugar +donde la comunidad de desarrollo del kernel se reúna como un todo; los +desarrolladores que eviten esta lista se perderán información importante. + +Hay algunos consejos que pueden ayudar a sobrevivir en el kernel de Linux: + +- Haga que la lista se entregue en una carpeta separada, en lugar de su + buzón principal. Uno debe ser capaz de ignorar el flujo durante + periodos prolongados. + +- No trate de seguir cada conversación, nadie lo hace. Es importante + filtrar tanto por el tema de interés (aunque tenga en cuenta que las + conversaciones prolongadas pueden alejarse del asunto original sin + cambiar la línea de asunto del correo electrónico) por las personas + que participan. + +- No alimente a los trolls. Si alguien está tratando de provocar una + respuesta de enojo, ignórelos. + +- Al responder al correo electrónico del kernel de Linux (o al de otras + listas) conserve el encabezado Cc: para todos los involucrados. En + ausencia de una razón solida (como una solicitud explícita), nunca debe + eliminar destinarios. Asegúrese siempre de que la persona a la que está + respondiendo esté en la lista Cc:. Esta convención también hace que no + sea necesario solicitar explícitamente que se le copie en las respuestas + a sus publicaciones. + +- Busque en los archivos de la lista (y en la red en su conjunto) antes + de hacer preguntas. Algunos desarrolladores pueden impacientarse con + las personas que claramente no han hecho sus deberes. + +- Utilice respuestas intercaladas (“en línea”), lo que hace que su + respuesta sea más fácil de leer. (Es decir, evite top-posting – la + práctica de poner su respuesta encima del texto citado al que está + respondiendo.) Para obtener más información, consulte + :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_interleaved_replies>`. + +- Pregunte en la lista de correo correcta. linux-kernel puede ser el + punto de encuentro general, pero no es el mejor lugar para encontrar + desarrolladores de todos los subsistemas. + +El último punto, encontrar la lista de correo correcta, es una fuente +común de errores para desarrolladores principiantes. Alguien que haga +una pregunta relacionada con las redes en linux-kernel seguramente +recibirá una surgencia educada para preguntar en la lista de netdev en su +lugar, ya que esa es la lista frecuentada por la mayoría de los +desarrolladores de redes. Existen otras listas para los subsistemas SCSI, +video4linux, IDE, sistema de archivos, etc. El mejor lugar para buscar +listas de correo es en el archivo MAINTAINERS incluido con el código +fuente del kernel. + +Comenzar con el desarrollo del kernel +------------------------------------- + +Las preguntas sobre como comenzar con el proceso de desarrollo del kernel +son comunes, tanto de individuos como de empresas. Igualmente comunes son +los pasos en falso que hacen que el comienzo de la relación sea más +difícil de lo que tiene que ser. + +Las empresas a menudo buscan contratar desarrolladores conocidos para +iniciar un grupo de desarrollo. De hecho, esta puede ser una técnica +efectiva. Pero también tiende a ser caro y no hace mucho para crecer el +grupo de desarrolladores de kernel experimentados. Es posible poner al +día a los desarrolladores internos en el desarrollo de kernel de Linux, +dada la inversión de algún tiempo. Tomarse este tiempo puede dotar a un +empleador de un grupo de desarrolladores que comprendan tanto el kernel +como la empresa, y que también puedan ayudar a educar a otros. A medio +plazo, este es a menudo el enfoque más rentable. + +Los desarrolladores individuales, a menudo, comprensiblemente, no tienen +un lugar para empezar. Comenzar con un proyecto grande puede ser +intimidante; a menudo uno quiere probar las aguas con algo más pequeño +primero. Este es el punto en el que algunos desarrolladores se lanzan a +la creación de parches para corregir errores ortográficos o problemas +menores de estilo de codificación. Desafortunadamente, dicho parches +crean un nivel de ruido que distrae a la comunidad de desarrollo en su +conjunto, por lo que, cada vez más, se los mira con desprecio. Los nuevos +desarrolladores que deseen presentarse a la comunidad no recibirán la +recepción que desean por estos medios. + +Andrew Morton da este consejo (traducido) para los aspirantes a +desarrolladores de kernel. + +:: + + El proyecto #1 para los principiantes en el kernel seguramente debería + ser “asegúrese de que el kernel funcione perfectamente en todo momento + en todas las máquinas que pueda conseguir”. Por lo general, la forma + de hacer esto es trabajar con otros para arreglar las cosas (¡esto + puede requerir persistencia!), pero eso está bien, es parte del + desarrollo del kernel. + +(https://lwn.net/Articles/283982/) + +En ausencia de problemas obvios que solucionar, se aconseja a los +desarrolladores que consulten las listas actuales de regresiones y errores +abiertos en general. Nunca faltan problemas que necesitan solución; al +abordar estos problemas, los desarrolladores ganarán experiencia con el +proceso mientras, al mismo tiempo, se ganarán el respeto del resto de la +comunidad de desarrollo. diff --git a/Documentation/translations/sp_SP/process/3.Early-stage.rst b/Documentation/translations/sp_SP/process/3.Early-stage.rst new file mode 100644 index 0000000000..71cfb3fb0f --- /dev/null +++ b/Documentation/translations/sp_SP/process/3.Early-stage.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/3.Early-stage.rst + +.. _sp_development_early_stage: + +Planificación en etapa inicial +============================== + +.. warning:: + TODO aún no traducido diff --git a/Documentation/translations/sp_SP/process/4.Coding.rst b/Documentation/translations/sp_SP/process/4.Coding.rst new file mode 100644 index 0000000000..d9436e039b --- /dev/null +++ b/Documentation/translations/sp_SP/process/4.Coding.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/4.Coding.rst + +.. _sp_development_coding: + +Conseguir el código correcto +============================ + +.. warning:: + TODO aún no traducido diff --git a/Documentation/translations/sp_SP/process/5.Posting.rst b/Documentation/translations/sp_SP/process/5.Posting.rst new file mode 100644 index 0000000000..50a3bc5998 --- /dev/null +++ b/Documentation/translations/sp_SP/process/5.Posting.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/5.Posting.rst + +.. _sp_development_posting: + +Publicar parches +================ + +.. warning:: + TODO aún no traducido diff --git a/Documentation/translations/sp_SP/process/6.Followthrough.rst b/Documentation/translations/sp_SP/process/6.Followthrough.rst new file mode 100644 index 0000000000..f0acf9082b --- /dev/null +++ b/Documentation/translations/sp_SP/process/6.Followthrough.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/6.Followthrough.rst + +.. _sp_development_followthrough: + +Seguimiento +=========== + +.. warning:: + TODO aún no traducido diff --git a/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst b/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst new file mode 100644 index 0000000000..5537598573 --- /dev/null +++ b/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/7.AdvancedTopics.rst + +.. _sp_development_advancedtopics: + +Temas avanzados +=============== + +.. warning:: + TODO aún no traducido diff --git a/Documentation/translations/sp_SP/process/8.Conclusion.rst b/Documentation/translations/sp_SP/process/8.Conclusion.rst new file mode 100644 index 0000000000..dd181cb8ec --- /dev/null +++ b/Documentation/translations/sp_SP/process/8.Conclusion.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/8.Conclusion.rst + +.. _sp_development_conclusion: + +Para más información +==================== + +.. warning:: + TODO aún no traducido diff --git a/Documentation/translations/sp_SP/process/code-of-conduct.rst b/Documentation/translations/sp_SP/process/code-of-conduct.rst index adc6c770cc..a6c08613ae 100644 --- a/Documentation/translations/sp_SP/process/code-of-conduct.rst +++ b/Documentation/translations/sp_SP/process/code-of-conduct.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/code-of-conduct.rst <code_of_conduct>` -:Translator: Contributor Covenant and Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Contributor Covenant and Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_code_of_conduct: diff --git a/Documentation/translations/sp_SP/process/coding-style.rst b/Documentation/translations/sp_SP/process/coding-style.rst index a372747643..b5a84df44c 100644 --- a/Documentation/translations/sp_SP/process/coding-style.rst +++ b/Documentation/translations/sp_SP/process/coding-style.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/coding-style.rst <submittingpatches>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_codingstyle: diff --git a/Documentation/translations/sp_SP/process/development-process.rst b/Documentation/translations/sp_SP/process/development-process.rst new file mode 100644 index 0000000000..40d74086f2 --- /dev/null +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -0,0 +1,27 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/development-process.rst +:Translator: Avadhut Naik <avadhut.naik@amd.com> + +.. _sp_development_process_main: + +Guía del proceso de desarrollo del kernel +========================================= + +El propósito de este documento es ayudar a los desarrolladores (y sus +gerentes) a trabajar con la comunidad de desarrollo con un mínimo de +frustración. Es un intento de documentar cómo funciona esta comunidad +de una manera accesible para aquellos que no están familiarizados +íntimamente con el desarrollo del kernel de Linux (o, de hecho, el +desarrollo de software libre en general). Si bien hay algo de material +técnico aquí, este es en gran medida una discusión orientada al proceso +que no requiere un conocimiento profundo de la programación del kernel +para entenderla. + +.. toctree:: + :caption: Contenido + :numbered: + :maxdepth: 2 + + 1.Intro + 2.Process diff --git a/Documentation/translations/sp_SP/process/email-clients.rst b/Documentation/translations/sp_SP/process/email-clients.rst index fdf1e51b84..55d5803daf 100644 --- a/Documentation/translations/sp_SP/process/email-clients.rst +++ b/Documentation/translations/sp_SP/process/email-clients.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/email-clients.rst <email_clients>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_email_clients: diff --git a/Documentation/translations/sp_SP/process/howto.rst b/Documentation/translations/sp_SP/process/howto.rst index dd793c0f85..72ea855ac9 100644 --- a/Documentation/translations/sp_SP/process/howto.rst +++ b/Documentation/translations/sp_SP/process/howto.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/howto.rst <process_howto>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_process_howto: diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst index 2239373b39..4892159310 100644 --- a/Documentation/translations/sp_SP/process/index.rst +++ b/Documentation/translations/sp_SP/process/index.rst @@ -28,3 +28,4 @@ management-style submit-checklist howto + development-process diff --git a/Documentation/translations/sp_SP/process/kernel-docs.rst b/Documentation/translations/sp_SP/process/kernel-docs.rst index 2f9b3df8f8..a62c6854f5 100644 --- a/Documentation/translations/sp_SP/process/kernel-docs.rst +++ b/Documentation/translations/sp_SP/process/kernel-docs.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/kernel-docs.rst <kernel_docs>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_kernel_docs: diff --git a/Documentation/translations/sp_SP/process/kernel-enforcement-statement.rst b/Documentation/translations/sp_SP/process/kernel-enforcement-statement.rst index d669026940..d47a1c1546 100644 --- a/Documentation/translations/sp_SP/process/kernel-enforcement-statement.rst +++ b/Documentation/translations/sp_SP/process/kernel-enforcement-statement.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/kernel-enforcement-statement.rst <process_statement_kernel>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_process_statement_kernel: diff --git a/Documentation/translations/sp_SP/process/magic-number.rst b/Documentation/translations/sp_SP/process/magic-number.rst index 7c7dfb4ba8..32a99aac2f 100644 --- a/Documentation/translations/sp_SP/process/magic-number.rst +++ b/Documentation/translations/sp_SP/process/magic-number.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_magicnumbers: diff --git a/Documentation/translations/sp_SP/process/programming-language.rst b/Documentation/translations/sp_SP/process/programming-language.rst index 301f525372..ba2164057f 100644 --- a/Documentation/translations/sp_SP/process/programming-language.rst +++ b/Documentation/translations/sp_SP/process/programming-language.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/programming-language.rst <programming_language>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_programming_language: diff --git a/Documentation/translations/sp_SP/process/submitting-patches.rst b/Documentation/translations/sp_SP/process/submitting-patches.rst index c2757d9ab2..328ec80bd6 100644 --- a/Documentation/translations/sp_SP/process/submitting-patches.rst +++ b/Documentation/translations/sp_SP/process/submitting-patches.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst :Original: :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` -:Translator: Carlos Bilbao <carlos.bilbao@amd.com> +:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> .. _sp_submittingpatches: @@ -356,6 +356,34 @@ Consulte Documentation/process/email-clients.rst para obtener recomendaciones sobre clientes de correo electrónico y normas de etiqueta en la lista de correo. +.. _sp_interleaved_replies: + +Uso de respuestas intercaladas recortadas en las discusiones por correo electrónico +----------------------------------------------------------------------------------- + +Se desaconseja encarecidamente la publicación en la parte superior de las +discusiones sobre el desarrollo del kernel de Linux. Las respuestas +intercaladas (o "en línea") hacen que las conversaciones sean mucho más +fáciles de seguir. Para obtener más detalles, consulte: +https://en.wikipedia.org/wiki/Posting_style#Interleaved_style + +Como se cita frecuentemente en la lista de correo:: + + A: http://en.wikipedia.org/wiki/Top_post + Q: ¿Dónde puedo encontrar información sobre esto que se llama top-posting? + A: Porque desordena el orden en el que la gente normalmente lee el texto. + Q: ¿Por qué es tan malo el top-posting? + A: Top-posting. + Q: ¿Qué es lo más molesto del correo electrónico? + +Del mismo modo, por favor, recorte todas las citas innecesarias que no +sean relevantes para su respuesta. Esto hace que las respuestas sean más +fáciles de encontrar y ahorra tiempo y espacio. Para obtener más +información, consulte: http://daringfireball.net/2007/07/on_top :: + + A: No. + Q: ¿Debo incluir citas después de mi respuesta? + .. _sp_resend_reminders: No se desanime o impaciente |