diff options
author | Avadhut Naik <avadhut.naik@amd.com> | 2024-03-06 01:18:38 +0300 |
---|---|---|
committer | Jonathan Corbet <corbet@lwn.net> | 2024-04-02 19:07:51 +0300 |
commit | 169e54c2d705f5865a94d151e32de0326fdd5894 (patch) | |
tree | 944f5b6589c6ff6116cf20a3330de182083eaa18 | |
parent | 4ab16eb6f25988788c6d573298caede56889336b (diff) | |
download | linux-169e54c2d705f5865a94d151e32de0326fdd5894.tar.xz |
docs/sp_SP: Add translation of process/1.Intro.rst
Translate Documentation/process/1.Intro.rst into Spanish
In order to avoid broken links in the translated document, empty files
have been created for documents which have not yet been translated.
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-4-avadhut.naik@amd.com
9 files changed, 381 insertions, 0 deletions
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 000000000000..9b92b6c85221 --- /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 000000000000..768c43dfd805 --- /dev/null +++ b/Documentation/translations/sp_SP/process/2.Process.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/2.Process.rst + +.. _sp_development_process: + +Cómo funciona el proceso de desarrollo +====================================== + +.. warning:: + TODO aún no traducido 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 000000000000..71cfb3fb0fda --- /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 000000000000..d9436e039b4b --- /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 000000000000..50a3bc5998a8 --- /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 000000000000..f0acf9082bb3 --- /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 000000000000..553759857339 --- /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 000000000000..dd181cb8ec9a --- /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/development-process.rst b/Documentation/translations/sp_SP/process/development-process.rst index 41616249aa9e..17fb168418ac 100644 --- a/Documentation/translations/sp_SP/process/development-process.rst +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -22,3 +22,5 @@ para entenderla. :caption: Contenido :numbered: :maxdepth: 2 + + 1.Intro |