Re: [PATCH 2/2] Documentation: Add HOWTO Spanish translation into rst based build system

[Carlos Bilbao <carlos.bilbao@amd.com>]

On 10/14/22 04:21, Bagas Sanjaya wrote:

> ¡Hola Carlos! Gracias for start writing Spanish translations. However,
> the patch can be improved, see below.
Hola Bagas, thanks for your feedback :)
>
> On Thu, Oct 13, 2022 at 01:48:16PM -0500, Carlos Bilbao wrote:
>> This commit adds Spanish translation of HOWTO document into rst based
>> documentation build system.
>>
> Better say "Translate HOWTO document into Spanish".
So, for the commit message here I just replicated what prior folks did,
see:

For Japanese:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/translations/ja_JP?h=v6.0&id=f012733894d36ff687862e9cd3b02ee980c61416

For Korean:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/translations/ko_KR/howto.rst?h=v6.0&id=ba42c574fc8b803ec206785b7b91325c05810422

I think I will leave that commit message, it is slightly more informative
than "Translate HOWTO document into Spanish".

>
>> Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com>
>> ---
>>   Documentation/translations/sp_SP/howto.rst | 619 +++++++++++++++++++++
>>   Documentation/translations/sp_SP/index.rst |   7 +
>>   2 files changed, 626 insertions(+)
>>   create mode 100644 Documentation/translations/sp_SP/howto.rst
>>
>> diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst
>> new file mode 100644
>> index 000000000000..4cf8fa6b9f7c
>> --- /dev/null
>> +++ b/Documentation/translations/sp_SP/howto.rst
>> @@ -0,0 +1,619 @@
>> +.. include:: ./disclaimer-sp.rst
>> +
>> +:Original: :ref:`Documentation/process/howto.rst <process_howto>`
>> +:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
>> +
>> +.. _sp_process_howto:
>> +
>> +Cómo participar en el desarrollo del kernel de Linux
>> +====================================================
>> +
>> +Este documento es el principal punto de partida. Contiene instrucciones
>> +sobre cómo convertirse en desarrollador del kernel de Linux y explica cómo
>> +trabajar con el y en su desarrollo. El documento no tratará ningún aspecto
>> +técnico relacionado con la programación del kernel, pero le ayudará
>> +guiándole por el camino correcto.
>> +
>> +Si algo en este documento quedara obsoleto, envíe parches al maintainer de
>> +este archivo, que se encuentra en la parte superior del documento.
>> +
>> +Introducción
>> +------------
>> +¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del
>> +kernel de Linux? Tal vez su jefe le haya dicho, "Escriba un driver de
>> +Linux para este dispositivo." El objetivo de este documento en enseñarle
>> +todo cuanto necesita para conseguir esto, describiendo el proceso por el
>> +que debe pasar, y con indicaciones de como trabajar con la comunidad.
>> +También trata de explicar las razones por las cuales la comunidad trabaja
>> +de la forma en que lo hace.
>> +
>> +El kernel esta principalmente escrito en C, con algunas partes que son
>> +dependientes de la arquitectura en ensamblador. Un buen conocimiento de C
>> +es necesario para desarrollar en el kernel. Lenguaje ensamblador (en
>> +cualquier arquitectura) no es necesario excepto que planee realizar
>> +desarrollo de bajo nivel para dicha arquitectura. Aunque no es un perfecto
>> +sustituto para una educación sólida en C y/o años de experiencia, los
>> +siguientes libros sirven, como mínimo, como referencia:
>> +
>> +- "The C Programming Language" de Kernighan e Ritchie [Prentice Hall]
>> +- "Practical C Programming" de Steve Oualline [O'Reilly]
>> +- "C:  A Reference Manual" de Harbison and Steele [Prentice Hall]
>> +
>> +El kernel está escrito usando GNU C y la cadena de herramientas GNU. Si
>> +bien se adhiere al estándar ISO C89, utiliza una serie de extensiones que
>> +no aparecen en dicho estándar. El kernel usa un C independiente de entorno,
>> +sin depender de la biblioteca C estándar, por lo que algunas partes del
>> +estándar C no son compatibles. Divisiones de long long arbitrarios o
>> +de coma flotante no son permitidas. En ocasiones, puede ser difícil de
>> +entender las suposiciones que el kernel hace respecto a la cadena de
>> +herramientas y las extensiones que usa, y desafortunadamente no hay
>> +referencia definitiva para estos. Consulte las páginas de información de
>> +gcc (`info gcc`) para obtener información al respecto.
>> +
>> +Recuerde que está tratando de aprender a trabajar con una comunidad de
>> +desarrollo existente. Es un grupo diverso de personas, con altos estándares
>> +de codificación, estilo y procedimiento. Estas normas han sido creadas a lo
>> +largo del tiempo en función de lo que se ha encontrado que funciona mejor
>> +para un equipo tan grande y geográficamente disperso. Trate de aprender
>> +tanto como le sea posible acerca de estos estándares antes de tiempo, ya
>> +que están bien documentados; no espere que la gente se adapte a usted o a
>> +su forma de ser de hacer las cosas.
>> +
>> +Cuestiones legales
>> +------------------
>> +El código fuente del kernel de Linux se publica bajo licencia GPL. Por
>> +favor, revise el archivo COPYING, presente en la carpeta principal del
>> +fuente, para detalles de la licencia. Si tiene alguna otra pregunta
>> +sobre licencias, contacte a un abogado, no pregunte en listas de discusión
>> +del kernel de Linux. Las personas en estas listas no son abogadas, y no
>> +debe confiar en sus opiniones en materia legal.
>> +
>> +Para preguntas y respuestas más frecuentes sobre la licencia GPL, consulte:
>> +
>> +	https://www.gnu.org/licenses/gpl-faq.html
>> +
>> +Documentacion
>> +--------------
>> +El código fuente del kernel de Linux tiene una gran variedad de documentos
>> +que son increíblemente valiosos para aprender a interactuar con la
>> +comunidad del kernel. Cuando se agregan nuevas funciones al kernel, se
>> +recomienda que se incluyan nuevos archivos de documentación que expliquen
>> +cómo usar la función. Cuando un cambio en el kernel hace que la interfaz
>> +que el kernel expone espacio de usuario cambie, se recomienda que envíe la
>> +información o un parche en las páginas del manual que expliquen el cambio
>> +a mtk.manpages@gmail.com, y CC la lista linux-api@vger.kernel.org.
>> +
>> +Esta es la lista de archivos que están en el código fuente del kernel y son
>> +de obligada lectura:
>> +
>> +  :ref:`Documentation/admin-guide/README.rst <readme>`
>> +    Este archivo ofrece una breve descripción del kernel de Linux y
>> +    describe lo que es necesario hacer para configurar y compilar el
>> +    kernel. Quienes sean nuevos en el kernel deben comenzar aquí.
>> +
>> +  :ref:`Documentation/process/changes.rst <changes>`
>> +    Este archivo proporciona una lista de los niveles mínimos de varios
>> +    paquetes que son necesarios para construir y ejecutar el kernel
>> +    exitosamente.
>> +
>> +  :ref:`Documentation/process/coding-style.rst <codingstyle>`
>> +    Esto describe el estilo de código del kernel de Linux y algunas de los
>> +    razones detrás de esto. Se espera que todo el código nuevo siga las
>> +    directrices de este documento. La mayoría de los maintainers solo
>> +    aceptarán parches si se siguen estas reglas, y muchas personas solo
>> +    revisan el código si tiene el estilo adecuado.
>> +
>> +  :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
>> +    Este archivo describe en gran detalle cómo crear con éxito y enviar un
>> +    parche, que incluye (pero no se limita a):
>> +
>> +       - Contenidos del correo electrónico (email)
>> +       - Formato del email
>> +       - A quien se debe enviar
>> +
>> +    Seguir estas reglas no garantiza el éxito (ya que todos los parches son
>> +    sujetos a escrutinio de contenido y estilo), pero en caso de no seguir
>> +    dichas reglas, el fracaso es prácticamente garantizado.
>> +    Otras excelentes descripciones de cómo crear parches correctamente son:
>> +
>> +	"The Perfect Patch"
>> +		https://www.ozlabs.org/~akpm/stuff/tpp.txt
>> +
>> +	"Linux kernel patch submission format"
>> +		https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
>> +
>> +  :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
>> +    Este archivo describe la lógica detrás de la decisión consciente de
>> +    no tener una API estable dentro del kernel, incluidas cosas como:
>> +
>> +      - Capas intermedias del subsistema (por compatibilidad?)
>> +      - Portabilidad de drivers entre sistemas operativos
>> +      - Mitigar el cambio rápido dentro del árbol de fuentes del kernel (o
>> +        prevenir cambios rápidos)
>> +
>> +     Este documento es crucial para comprender la filosofía del desarrollo
>> +     de Linux y es muy importante para las personas que se mudan a Linux
>> +     tras desarrollar otros sistemas operativos.
>> +
>> +  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
>> +    Si cree que ha encontrado un problema de seguridad en el kernel de
>> +    Linux, siga los pasos de este documento para ayudar a notificar a los
>> +    desarrolladores del kernel y ayudar a resolver el problema.
>> +
>> +  :ref:`Documentation/process/management-style.rst <managementstyle>`
>> +    Este documento describe cómo operan los maintainers del kernel de Linux
>> +    y los valores compartidos detrás de sus metodologías. Esta es una
>> +    lectura importante para cualquier persona nueva en el desarrollo del
>> +    kernel (o cualquier persona que simplemente sienta curiosidad por
>> +    el campo IT), ya que clarifica muchos conceptos erróneos y confusiones
>> +    comunes sobre el comportamiento único de los maintainers del kernel.
>> +
>> +  :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
>> +    Este archivo describe las reglas sobre cómo se suceden las versiones
>> +    del kernel estable, y qué hacer si desea obtener un cambio en una de
>> +    estas publicaciones.
>> +
>> +  :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
>> +    Una lista de documentación externa relativa al desarrollo del kernel.
>> +    Por favor consulte esta lista si no encuentra lo que están buscando
>> +    dentro de la documentación del kernel.
>> +
>> +  :ref:`Documentation/process/applying-patches.rst <applying_patches>`
>> +    Una buena introducción que describe exactamente qué es un parche y cómo
>> +    aplicarlo a las diferentes ramas de desarrollo del kernel.
>> +
>> +El kernel también tiene una gran cantidad de documentos que pueden ser
>> +generados automáticamente desde el propio código fuente o desde
>> +ReStructuredText markups (ReST), como este. Esto incluye un descripción
>> +completa de la API en el kernel y reglas sobre cómo manejar cerrojos
>> +(locking) correctamente.
>> +
>> +Todos estos documentos se pueden generar como PDF o HTML ejecutando::
>> +
>> +	make pdfdocs
>> +	make htmldocs
>> +
>> +respectivamente desde el directorio fuente principal del kernel.
>> +
>> +Los documentos que utilizan el markup ReST se generarán en
>> +Documentation/output. También se pueden generar en formatos LaTeX y ePub
>> +con::
>> +
>> +	make latexdocs
>> +	make epubdocs
>> +
>> +Convertirse en un/a desarrollador/a de kernel
>> +-------------------------------------------
>> +
>> +Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar
>> +el proyecto Linux KernelNewbies:
>> +
>> +	https://kernelnewbies.org
>> +
>> +Consiste en una útil lista de correo donde puede preguntar casi cualquier
>> +tipo de pregunta básica de desarrollo del kernel (asegúrese de buscar en
>> +los archivos primero, antes de preguntar algo que ya ha sido respondido en
>> +el pasado.) También tiene un canal IRC que puede usar para hacer preguntas
>> +en en tiempo real, y una gran cantidad de documentación útil que es útil
>> +para ir aprendiendo sobre el desarrollo del kernel de Linux.
>> +
>> +El sitio web tiene información básica sobre la organización del código,
>> +subsistemas, y proyectos actuales (tanto dentro como fuera del árbol).
>> +También describe alguna información logística básica, como cómo compilar
>> +un kernel y aplicar un parche.
>> +
>> +Si no sabe por dónde quiere empezar, pero quieres buscar alguna tarea que
>> +comenzar a hacer para unirse a la comunidad de desarrollo del kernel,
>> +acuda al proyecto Linux Kernel Janitor:
>> +
>> +	https://kernelnewbies.org/KernelJanitors
>> +
>> +Es un gran lugar para comenzar. Describe una lista de problemas
>> +relativamente simples que deben limpiarse y corregirse dentro del codigo
>> +fuente del kernel de Linux árbol de fuentes. Trabajando con los
>> +desarrolladores a cargo de este proyecto, aprenderá los conceptos básicos
>> +para incluir su parche en el árbol del kernel de Linux, y posiblemente
>> +descubrir en la dirección en que trabajar a continuación, si no tiene ya
>> +una idea.
>> +
>> +Antes de realizar cualquier modificación real al código del kernel de
>> +Linux, es imperativo entender cómo funciona el código en cuestión. Para
>> +este propósito, nada es mejor que leerlo directamente (lo más complicado
>> +está bien comentado), tal vez incluso con la ayuda de herramientas
>> +especializadas. Una de esas herramientas que se recomienda especialmente
>> +es el proyecto Linux Cross-Reference, que es capaz de presentar el código
>> +fuente en un formato de página web indexada y autorreferencial. Una
>> +excelente puesta al día del repositorio del código del kernel se puede
>> +encontrar en:
>> +
>> +	https://elixir.bootlin.com/
>> +
>> +El proceso de desarrollo
>> +------------------------
>> +
>> +El proceso de desarrollo del kernel de Linux consiste actualmente de
>> +diferentes "branches" (ramas) con muchos distintos subsistemas específicos
>> +a cada una de ellas. Las diferentes ramas son:
>> +
>> +  - El código principal de Linus (mainline tree)
>> +  - Varios árboles estables con múltiples major numbers
>> +  - Subsistemas específicos
>> +  - linux-next, para integración y testing
>> +
>> +Mainline tree (Árbol principal)
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +El mainline tree es mantenido por Linus Torvalds, y puede encontrarse en
>> +https://kernel.org o en su repo.  El proceso de desarrollo es el siguiente:
>> +
>> +  - Tan pronto como se lanza un nuevo kernel, se abre una ventana de dos
>> +    semanas, durante este período de tiempo, los maintainers pueden enviar
>> +    grandes modificaciones a Linus, por lo general los parches que ya se
>> +    han incluido en el linux-next durante unas semanas. La forma preferida
>> +    de enviar grandes cambios es usando git (la herramienta de
>> +    administración de codigo fuente del kernel, más información al respecto
>> +    en https://git-scm.com/), pero los parches simples también son validos.
>> +  - Después de dos semanas, se lanza un kernel -rc1 y la atención se centra
>> +    en hacer que el kernel nuevo lo más estable ("solido") posible. La
>> +    mayoría de los parches en este punto debe arreglar una regresión. Los
>> +    errores que siempre han existido no son regresiones, por lo tanto, solo
>> +    envíe este tipo de correcciones si son importantes. Tenga en cuenta que
>> +    se podría aceptar un controlador (o sistema de archivos) completamente
>> +    nuevo después de -rc1 porque no hay riesgo de causar regresiones con
>> +    tal cambio, siempre y cuando el cambio sea autónomo y no afecte áreas
>> +    fuera del código que se está agregando. git se puede usar para enviar
>> +    parches a Linus después de que se lance -rc1, pero los parches también
>> +    deben ser enviado a una lista de correo pública para su revisión.
>> +  - Se lanza un nuevo -rc cada vez que Linus considera que el árbol git
>> +    actual esta en un estado razonablemente sano y adecuado para la prueba.
>> +    La meta es lanzar un nuevo kernel -rc cada semana.
>> +  - El proceso continúa hasta que el kernel se considera "listo", y esto
>> +    puede durar alrededor de 6 semanas.
>> +
>> +Vale la pena mencionar lo que Andrew Morton escribió en las listas de
>> +correo del kernel de Linux, sobre lanzamientos del kernel (traducido):
>> +
>> +	*"Nadie sabe cuándo se publicara un nuevo kernel, porque esto sucede
>> +    de acuerdo con el estado de bugs (error) percibido, no de acuerdo con
>> +    una línea temporal preconcebida."*
>> +
>> +Varios árboles estables con múltiples major numbers
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +Los kernels con versiones de 3 partes son kernels estables. Estos contienen
>> +correcciones relativamente pequeñas y críticas para problemas de seguridad
>> +o importantes regresiones descubiertas para una publicación de código.
>> +Cada lanzamiento en una gran serie estable incrementa la tercera parte de
>> +la versión número, manteniendo las dos primeras partes iguales.
>> +
>> +Esta es la rama recomendada para los usuarios que quieren la versión
>> +estable más reciente del kernel, y no están interesados ​​en ayudar a probar
>> +versiones en desarrollo/experimentales.
>> +
>> +Los árboles estables son mantenidos por el equipo "estable"
>> +<stable@vger.kernel.org>, y se liberan (publican) según lo dicten las
>> +necesidades. El período de liberación normal es de aproximadamente dos
>> +semanas, pero puede ser más largo si no hay problemas apremiantes. Un
>> +problema relacionado con la seguridad, en cambio, puede causar un
>> +lanzamiento casi instantáneamente.
>> +
>> +El archivo :ref:`Documentación/proceso/stable-kernel-rules.rst <stable_kernel_rules>`
>> +en el árbol del kernel documenta qué tipos de cambios son aceptables para
>> +el árbol estable y cómo funciona el proceso de lanzamiento.
>> +
>> +Subsistemas específicos
>> +~~~~~~~~~~~~~~~~~~~~~~~~
>> +Los maintainers de los diversos subsistemas del kernel --- y también muchos
>> +desarrolladores de subsistemas del kernel --- exponen su estado actual de
>> +desarrollo en repositorios fuente. De esta manera, otros pueden ver lo que
>> +está sucediendo en las diferentes áreas del kernel. En áreas donde el
>> +desarrollo es rápido, se le puede pedir a un desarrollador que base sus
>> +envíos en tal árbol del subsistema del kernel, para evitar conflictos entre
>> +este y otros trabajos ya en curso.
>> +
>> +La mayoría de estos repositorios son árboles git, pero también hay otros
>> +SCM en uso, o colas de parches que se publican como series quilt. Las
>> +direcciones de estos repositorios de subsistemas se enumeran en el archivo
>> +MAINTAINERS. Muchos de estos se pueden ver en https://git.kernel.org/.
>> +
>> +Antes de que un parche propuesto se incluya con dicho árbol de subsistemas,
>> +es sujeto a revisión, que ocurre principalmente en las listas de correo
>> +(ver la sección respectiva a continuación). Para varios subsistemas del
>> +kernel, esta revisión se rastrea con la herramienta patchwork. Patchwork
>> +ofrece una interfaz web que muestra publicaciones de parches, cualquier
>> +comentario sobre un parche o revisiones a él, y los maintainers pueden
>> +marcar los parches como en revisión, aceptado, o rechazado. La mayoría de
>> +estos sitios de trabajo de parches se enumeran en
>> +
>> +https://patchwork.kernel.org/.
>> +
>> +linux-next, para integración y testing
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +Antes de que las actualizaciones de los árboles de subsistemas se combinen
>> +con el árbol principal, necesitan probar su integración. Para ello, existe
>> +un repositorio especial de pruebas en el que se encuentran casi todos los
>> +árboles de subsistema, actualizado casi a diario:
>> +
>> +	https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
>> +
>> +De esta manera, linux-next ofrece una perspectiva resumida de lo que se
>> +espera que entre en el kernel principal en el próximo período de "merge"
>> +(fusión de codigo). Los testers aventureros son bienvenidos a probar
>> +linux-next en ejecución.
>> +
>> +Reportar bugs
>> +-------------
>> +
>> +El archivo 'Documentación/admin-guide/reporting-issues.rst' en el
>> +directorio principal del kernel describe cómo informar un posible bug del
>> +kernel y detalles sobre qué tipo de información necesitan los
>> +desarrolladores del kernel para ayudar a rastrear la fuente del problema.
>> +
>> +Gestión de informes de bugs
>> +------------------------------
>> +
>> +Una de las mejores formas de poner en práctica sus habilidades de hacking
>> +es arreglando errores reportados por otras personas. No solo ayudará a
>> +hacer el kernel más estable, también aprenderá a solucionar problemas del
>> +mundo real y mejora sus habilidades, y otros desarrolladores se darán
>> +cuenta de tu presencia. La corrección de errores es una de las mejores
>> +formas de ganar méritos entre desarrolladores, porque no a muchas personas
>> +les gusta perder el tiempo arreglando los errores de otras personas.
>> +
>> +Para trabajar en informes de errores ya reportados, busque un subsistema
>> +que le interese. Verifique el archivo MAINTAINERS donde se informan los
>> +errores de ese subsistema; con frecuencia será una lista de correo, rara
>> +vez un rastreador de errores (bugtracker). Busque en los archivos de dicho
>> +lugar para informes recientes y ayude donde lo crea conveniente. También es
>> +posible que desee revisar https://bugzilla.kernel.org para informes de
>> +errores; solo un puñado de subsistemas del kernel lo emplean activamente
>> +para informar o rastrear; sin embargo, todos los errores para todo el kernel
>> +se archivan allí.
>> +
>> +Listas de correo
>> +-----------------
>> +
>> +Como se explica en algunos de los documentos anteriores, la mayoría de
>> +desarrolladores del kernel participan en la lista de correo del kernel de
>> +Linux. Detalles sobre cómo para suscribirse y darse de baja de la lista se
>> +pueden encontrar en:
>> +
>> +	http://vger.kernel.org/vger-lists.html#linux-kernel
>> +
>> +Existen archivos de la lista de correo en la web en muchos lugares
>> +distintos. Utilice un motor de búsqueda para encontrar estos archivos. Por
>> +ejemplo:
>> +
>> +	http://dir.gmane.org/gmane.linux.kernel
>> +
>> +Es muy recomendable que busque en los archivos sobre el tema que desea
>> +tratar, antes de publicarlo en la lista. Un montón de cosas ya discutidas
>> +en detalle solo se registran en los archivos de la lista de correo.
>> +
>> +La mayoría de los subsistemas individuales del kernel también tienen sus
>> +propias lista de correo donde hacen sus esfuerzos de desarrollo. Revise el
>> +archivo MAINTAINERS para obtener referencias de lo que estas listas para
>> +los diferentes grupos.
>> +
>> +Muchas de las listas están alojadas en kernel.org. La información sobre
>> +estas puede ser encontrada en:
>> +
>> +	http://vger.kernel.org/vger-lists.html
>> +
>> +Recuerde mantener buenos hábitos de comportamiento al usar las listas.
>> +Aunque un poco cursi, la siguiente URL tiene algunas pautas simples para
>> +interactuar con la lista (o cualquier lista):
>> +
>> +	http://www.albion.com/netiquette/
>> +
>> +Si varias personas responden a su correo, el CC (lista de destinatarios)
>> +puede hacerse bastante grande. No elimine a nadie de la lista CC: sin una
>> +buena razón, o no responda solo a la dirección de la lista. Acostúmbrese
>> +a recibir correos dos veces, una del remitente y otra de la lista, y no
>> +intente ajustar esto agregando encabezados de correo astutos, a la gente no
>> +le gustará.
>> +
>> +Recuerde mantener intacto el contexto y la atribución de sus respuestas,
>> +mantenga las líneas "El hacker John Kernel escribió ...:" en la parte
>> +superior de su respuesta, y agregue sus declaraciones entre las secciones
>> +individuales citadas en lugar de escribiendo en la parte superior del
>> +correo electrónico.
>> +
>> +Si incluye parches en su correo, asegúrese de que sean texto legible sin
>> +formato como se indica en :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
>> +Los desarrolladores del kernel no quieren lidiar con archivos adjuntos o
>> +parches comprimidos; y pueden querer comentar líneas individuales de su
>> +parche, que funciona sólo de esa manera. Asegúrese de emplear un programa
>> +de correo que no altere los espacios ni los tabuladores. Una buena primera
>> +prueba es enviarse el correo a usted mismo, e intentar aplicar su
>> +propio parche. Si eso no funciona, arregle su programa de correo o
>> +reemplace hasta que funcione.
>> +
>> +Sobretodo, recuerde de ser respetuoso con otros subscriptores.
>> +
>> +Colaborando con la comunidad
>> +----------------------------
>> +
>> +El objetivo de la comunidad del kernel es proporcionar el mejor kernel
>> +posible. Cuando envíe un parche para su aceptación, se revisará en sus
>> +méritos técnicos solamente. Entonces, ¿qué deberías ser?
>> +
>> +  - criticas
>> +  - comentarios
>> +  - peticiones de cambios
>> +  - peticiones de justificaciones
>> +  - silencio
>> +
>> +Recuerde, esto es parte de introducir su parche en el kernel. Tiene que ser
>> +capaz de recibir críticas y comentarios sobre sus parches, evaluar
>> +a nivel técnico y re-elaborar sus parches o proporcionar razonamiento claro
>> +y conciso de por qué no se deben hacer tales cambios. Si no hay respuestas
>> +a su publicación, espere unos días e intente de nuevo, a veces las cosas se
>> +pierden dado el gran volumen.
>> +
>> +¿Qué no debería hacer?
>> +
>> +  - esperar ue su parche se acepte sin preguntas
>> +  - actuar de forma defensiva
>> +  - ignorar comentarios
>> +  - enviar el parche de nuevo, sin haber aplicados los cambios pertinentes
>> +
>> +En una comunidad que busca la mejor solución técnica posible, siempre habrá
>> +diferentes opiniones sobre lo beneficioso que es un parche. Tiene que ser
>> +cooperativo y estar dispuesto a adaptar su idea para que encaje dentro
>> +del kernel, o al menos esté dispuesto a demostrar que su idea vale la pena.
>> +Recuerea, estar equivocado es aceptable siempre y cuando estés dispuesto a
>> +trabajar hacia una solución que sea correcta.
>> +
>> +Es normal que las respuestas a su primer parche sean simplemente una lista
>> +de una docena de cosas que debe corregir. Esto **no** implica que su
>> +parche no será aceptado, y **no** es personal. Simplemente corrija todos
>> +los problemas planteados en su parche, y envié otra vez.
>> +
>> +Diferencias entre la comunidad kernel y las estructuras corporativas
>> +--------------------------------------------------------------------
>> +
>> +La comunidad del kernel funciona de manera diferente a la mayoría de los
>> +entornos de desarrollo tradicionales en empresas. Aquí hay una lista de
>> +cosas que puede intentar hacer para evitar problemas:
>> +
>> +  Cosas buenas que decir respecto a los cambios propuestos:
>> +
>> +    - "Esto arregla múltiples problemas."
>> +    - "Esto elimina 2000 lineas de código."
>> +    - "Aquí hay un parche que explica lo que intento describir."
>> +    - "Lo he testeado en 5 arquitecturas distintas..."
>> +    - "Aquí hay una serie de parches menores que..."
>> +    - "Esto mejora el rendimiento en maquinas típicas..."
>> +
>> +  Cosas negativas que debe evitar decir:
>> +
>> +    - "Lo hicimos asi en AIX/ptx/Solaris, de modo que debe ser bueno..."
>> +    - "LLevo haciendo esto 20 años, de modo que..."
>> +    - "Esto lo necesita mi empresa para ganar dinero"
>> +    - "Esto es para la linea de nuestros productos Enterprise"
>> +    - "Aquí esta el documento de 1000 paginas describiendo mi idea"
>> +    - "Llevo 6 meses trabajando en esto..."
>> +    - "Aquí esta un parche de 5000 lineas que..."
>> +    - "He rescrito todo el desastre actual, y aqui esta..."
>> +    - "Tengo un deadline, y este parche debe aplicarse ahora."
>> +
>> +Otra forma en que la comunidad del kernel es diferente a la mayoría de los
>> +entornos de trabajo tradicionales en ingeniería de software, es la
>> +naturaleza sin rostro de interacción. Una de las ventajas de utilizar el
>> +correo electrónico y el IRC como formas principales de comunicación es la
>> +no discriminación por motivos de género o raza. El entorno de trabajo del
>> +kernel de Linux acepta a mujeres y minorías porque todo lo que eres es una
>> +dirección de correo electrónico. El aspecto internacional también ayuda a
>> +nivelar el campo de juego porque no puede adivinar el género basado en
>> +el nombre de una persona. Un hombre puede llamarse Andrea y una mujer puede
>> +llamarse Pat. La mayoría de las mujeres que han trabajado en el kernel de
>> +Linux y han expresado una opinión han tenido experiencias positivas.
>> +
>> +La barrera del idioma puede causar problemas a algunas personas que no se
>> +sientes cómodas con el inglés. Un buen dominio del idioma puede ser
>> +necesario para transmitir ideas correctamente en las listas de correo, por
>> +lo que le recomendamos que revise sus correos electrónicos para asegurarse
>> +de que tengan sentido en inglés antes de enviarlos.
>> +
>> +Divida sus cambios
>> +---------------------
>> +
>> +La comunidad del kernel de Linux no acepta con gusto grandes fragmentos de
>> +código, sobretodo a la vez. Los cambios deben introducirse correctamente,
>> +discutidos y divididos en pequeñas porciones individuales. Esto es casi
>> +exactamente lo contrario de lo que las empresas están acostumbradas a hacer.
>> +Su propuesta también debe introducirse muy temprano en el proceso de
>> +desarrollo, de modo que pueda recibir comentarios sobre lo que está
>> +haciendo. También deje que la comunidad sienta que está trabajando con
>> +ellos, y no simplemente usándolos como un vertedero para su función. Sin
>> +embargo, no envíe 50 correos electrónicos a una vez a una lista de correo,
>> +su serie de parches debe casi siempre ser más pequeña que eso.
>> +
>> +Las razones para dividir las cosas son las siguientes:
>> +
>> +1) Los cambios pequeños aumentan la probabilidad de que sus parches sean
>> +   aplicados, ya que no requieren mucho tiempo o esfuerzo para verificar su
>> +   exactitud. Un parche de 5 líneas puede ser aplicado por un maintainer
>> +   con apenas una segunda mirada. Sin embargo, un parche de 500 líneas
>> +   puede tardar horas en ser revisado en términos de corrección (el tiempo
>> +   que toma es exponencialmente proporcional al tamaño del parche, o algo
>> +   así).
>> +
>> +   Los parches pequeños también facilitan la depuración cuando algo falla.
>> +   Es mucho más fácil retirar los parches uno por uno que diseccionar un
>> +   parche muy grande después de haber sido aplicado (y roto alguna cosa).
>> +
>> +2) Es importante no solo enviar pequeños parches, sino también reescribir
>> +   y simplificar (o simplemente reordenar) los parches antes de enviarlos.
>> +
>> +Esta es una analogía del desarrollador del kernel Al Viro (traducida):
>> +
>> +	*"Piense en un maestro que califica la tarea de un estudiante de
>> +	matemáticas. El maestro no quiere ver los intentos y errores del
>> +	estudiante antes de que se les ocurriera la solución. Quiere ver la
>> +	respuesta más limpia y elegante. Un buen estudiante lo sabe, y nunca
>> +	presentaría su trabajo intermedio antes de tener la solución final.*
>> +
>> +	* Lo mismo ocurre con el desarrollo del kernel. Los maintainers y
>> +	revisores no quieren ver el proceso de pensamiento detrás de la solución
>> +	al problema que se está resolviendo. Quieren ver un solución simple y
>> +	elegante."*
>> +
>> +Puede resultar un reto mantener el equilibrio entre presentar una solución
>> +elegante y trabajar junto a la comunidad, discutiendo su trabajo inacabado.
>> +Por lo tanto, es bueno comenzar temprano en el proceso para obtener
>> +"feedback" y mejorar su trabajo, pero también mantenga sus cambios en
>> +pequeños trozos que pueden ser aceptados, incluso cuando toda su labor no
>> +está listo para inclusión en un momento dado.
>> +
>> +También tenga en cuenta que no es aceptable enviar parches para su
>> +inclusión que están sin terminar y serán "arreglados más tarde".
>> +
>> +Justifique sus cambios
>> +----------------------
>> +
>> +Además de dividir sus parches, es muy importante que deje a la comunidad de
>> +Linux sabe por qué deberían agregar este cambio. Nuevas características
>> +debe justificarse como necesarias y útiles.
>> +
>> +Documente sus cambios
>> +--------------------
>> +
>> +Cuando envíe sus parches, preste especial atención a lo que dice en el
>> +texto de su correo electrónico. Esta información se convertirá en el
>> +ChangeLog del parche, y se conservará para que todos la vean, todo el
>> +tiempo. Debe describir el parche por completo y contener:
>> +
>> +  - por que los cambios son necesarios
>> +  - el diseño general de su propuesta
>> +  - detalles de implementación
>> +  - resultados de sus experimentos
>> +
>> +Para obtener más detalles sobre cómo debería quedar todo esto, consulte la
>> +sección ChangeLog del documento:
>> +
>> +  "The Perfect Patch"
>> +      https://www.ozlabs.org/~akpm/stuff/tpp.txt
>> +
>> +Todas estas cuestiones son a veces son muy difíciles de conseguir. Puede
>> +llevar años perfeccionar estas prácticas (si es que lo hace). Es un proceso
>> +continuo de mejora que requiere mucha paciencia y determinación. Pero no se
>> +rinda, es posible. Muchos lo han hecho antes, y cada uno tuvo que comenzar
>> +exactamente donde está usted ahora.
>> +
>> +
>> +----------
>> +
>> +Gracias a Paolo Ciarrocchi que permitió que la sección "Development Process"
>> +se basara en el texto que había escrito (https://lwn.net/Articles/94386/),
>> +y a Randy Dunlap y Gerrit Huizenga por algunas de la lista de cosas que
>> +debes y no debes decir. También gracias a Pat Mochel, Hanna Linder, Randy
>> +Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook,
>> +Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk,
>> +Keri Harris, Frans Pop, David A. Wheeler, Junio ​​Hamano, Michael Kerrisk y
>> +Alex Shepard por su revisión, comentarios y contribuciones. Sin su ayuda,
>> +este documento no hubiera sido posible.
>> +
>> +Maintainer: Greg Kroah-Hartman <greg@kroah.com>
> kernel test robot have already reported documentation warnings at [1],
> so I have applied the fixup:
Nice, I'll make sure to include this in v2
>
> ---- >8 ----
>
> diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst
> index 4cf8fa6b9f7c2e..0c072b9a69df30 100644
> --- a/Documentation/translations/sp_SP/howto.rst
> +++ b/Documentation/translations/sp_SP/howto.rst
> @@ -183,7 +183,7 @@ con::
>   	make epubdocs
>   
>   Convertirse en un/a desarrollador/a de kernel
> --------------------------------------------
> +---------------------------------------------
>   
>   Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar
>   el proyecto Linux KernelNewbies:
> @@ -274,8 +274,8 @@ Vale la pena mencionar lo que Andrew Morton escribió en las listas de
>   correo del kernel de Linux, sobre lanzamientos del kernel (traducido):
>   
>   	*"Nadie sabe cuándo se publicara un nuevo kernel, porque esto sucede
> -    de acuerdo con el estado de bugs (error) percibido, no de acuerdo con
> -    una línea temporal preconcebida."*
> +        de acuerdo con el estado de bugs (error) percibido, no de acuerdo con
> +        una línea temporal preconcebida."*
>   
>   Varios árboles estables con múltiples major numbers
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> @@ -556,7 +556,7 @@ Esta es una analogía del desarrollador del kernel Al Viro (traducida):
>   	respuesta más limpia y elegante. Un buen estudiante lo sabe, y nunca
>   	presentaría su trabajo intermedio antes de tener la solución final.*
>   
> -	* Lo mismo ocurre con el desarrollo del kernel. Los maintainers y
> +	*Lo mismo ocurre con el desarrollo del kernel. Los maintainers y
>   	revisores no quieren ver el proceso de pensamiento detrás de la solución
>   	al problema que se está resolviendo. Quieren ver un solución simple y
>   	elegante."*
> @@ -579,7 +579,7 @@ Linux sabe por qué deberían agregar este cambio. Nuevas características
>   debe justificarse como necesarias y útiles.
>   
>   Documente sus cambios
> ---------------------
> +---------------------
>   
>   Cuando envíe sus parches, preste especial atención a lo que dice en el
>   texto de su correo electrónico. Esta información se convertirá en el
>
> Muchas gracias (thanks very much).
Cheers!
>
> [1]: https://lore.kernel.org/linux-doc/202210141348.7UGXRUp8-lkp@intel.com/