Spanish is the second most spoken language in the world. This patch set
starts the process of translating critical kernel documentation into the
Spanish language.
Link to v2: https://lkml.org/lkml/2022/10/13/866
Changes since v2:
- Apply improvements proposed by Miguel Ojeda
- Added Reviewed-By of Miguel Ojeda for first commit
- Added Reviwed-By of Bagas Sanjaya for second commit
Changes since v1:
- Added me as MAINTAINER
- Fixed warnings of kernel test robot
- Use imperative form in second commit
- Improved minor translation details
Carlos Bilbao (2):
Documentation: Start translations to Spanish
Documentation: Add HOWTO Spanish translation into rst based build system
Documentation/translations/index.rst | 1 +
.../translations/sp_SP/disclaimer-sp.rst | 6 +
Documentation/translations/sp_SP/howto.rst | 617 ++++++++++++++++++
Documentation/translations/sp_SP/index.rst | 80 +++
MAINTAINERS | 5 +
5 files changed, 709 insertions(+)
create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
create mode 100644 Documentation/translations/sp_SP/howto.rst
create mode 100644 Documentation/translations/sp_SP/index.rst
Add Spanish translation of HOWTO document into rst based documentation
build system.
Reviewed-by: Bagas Sanjaya <[email protected]>
Signed-off-by: Carlos Bilbao <[email protected]>
---
Documentation/translations/sp_SP/howto.rst | 617 +++++++++++++++++++++
Documentation/translations/sp_SP/index.rst | 8 +
2 files changed, 625 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..f1375651a1a8
--- /dev/null
+++ b/Documentation/translations/sp_SP/howto.rst
@@ -0,0 +1,617 @@
+.. include:: ./disclaimer-sp.rst
+
+:Original: :ref:`Documentation/process/howto.rst <process_howto>`
+:Translator: Carlos Bilbao <[email protected]>
+
+.. _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 estas. 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 código, 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
+la forma de hacer las cosas en su empresa.
+
+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
+código 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. La gente 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
+
+Documentación
+--------------
+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 [email protected], y CC la lista [email protected].
+
+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 tiempo real, y una gran cantidad de documentación ú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 código
+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 código 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 el kernel nuevo lo más estable ("solido") posible. La mayoría
+ de los parches en este punto deben 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, pues esto sucede
+ según el estado de los bugs, no de una cronología 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"
+<[email protected]>, 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 código). 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?
+
+ - críticas
+ - 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 que 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.
+Recuerde, 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 así 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 aquí 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 qué 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 <[email protected]>
diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst
index 816d45e081e9..5b3f45d84955 100644
--- a/Documentation/translations/sp_SP/index.rst
+++ b/Documentation/translations/sp_SP/index.rst
@@ -70,3 +70,11 @@ En términos más generales, la documentación, como el kernel mismo, están en
constante desarrollo. Las mejoras en la documentación siempre son
bienvenidas; de modo que, si desea ayudar, únase a la lista de correo
linux-doc en vger.kernel.org.
+
+Traducciones al español
+=======================
+
+.. toctree::
+ :maxdepth: 1
+
+ howto
--
2.34.1
Start the process of translating kernel documentation to Spanish. Create
directory sp_SP/ instead of es_ES/ (diverging from format of prior
translated directories) since this directory should accept any dialects of
Spanish. Include an index and a disclaimer, following the approach of
prior translations. Add Carlos Bilbao as MAINTAINER of this effort.
Reviewed-by: Miguel Ojeda <[email protected]>
Signed-off-by: Carlos Bilbao <[email protected]>
---
Documentation/translations/index.rst | 1 +
.../translations/sp_SP/disclaimer-sp.rst | 6 ++
Documentation/translations/sp_SP/index.rst | 72 +++++++++++++++++++
MAINTAINERS | 5 ++
4 files changed, 84 insertions(+)
create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
create mode 100644 Documentation/translations/sp_SP/index.rst
diff --git a/Documentation/translations/index.rst b/Documentation/translations/index.rst
index 1175a47d07f0..b826c34791c0 100644
--- a/Documentation/translations/index.rst
+++ b/Documentation/translations/index.rst
@@ -12,6 +12,7 @@ Translations
it_IT/index
ko_KR/index
ja_JP/index
+ sp_SP/index
.. _translations_disclaimer:
diff --git a/Documentation/translations/sp_SP/disclaimer-sp.rst b/Documentation/translations/sp_SP/disclaimer-sp.rst
new file mode 100644
index 000000000000..a400034e95f9
--- /dev/null
+++ b/Documentation/translations/sp_SP/disclaimer-sp.rst
@@ -0,0 +1,6 @@
+:orphan:
+
+.. warning::
+ 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/index.rst b/Documentation/translations/sp_SP/index.rst
new file mode 100644
index 000000000000..816d45e081e9
--- /dev/null
+++ b/Documentation/translations/sp_SP/index.rst
@@ -0,0 +1,72 @@
+.. _sp_linux_doc:
+
+=====================
+Traducción al español
+=====================
+
+.. raw:: latex
+
+ \kerneldocCJKoff
+
+:maintainer: Carlos Bilbao <[email protected]>
+
+.. _sp_disclaimer:
+
+Advertencia
+===========
+
+El objetivo de esta traducción es facilitar la lectura y comprensión para
+aquellos que no entiendan inglés o duden de sus interpretaciones, o
+simplemente para aquellos que prefieran leer en el idioma español. Sin
+embargo, tenga en cuenta que la *única* documentación oficial es la que
+está en inglés: :ref:`linux_doc`
+
+La propagación simultánea de la traducción de una modificación en
+:ref:`linux_doc` es altamente improbable. Los maintainers y colaboradores
+de la traducción intentan mantener sus traducciones al día, en tanto les
+es posible. Por tanto, no existe ninguna garantía de que una traducción
+esté actualizada con las últimas modificaciones. Si lo que lee en una
+traducción no se corresponde con lo que ve en el código fuente, informe
+al maintainer de la traducción y, si puede, consulte la documentación en
+inglés.
+
+Una traducción no es una * bifurcación * de la documentación oficial, por
+lo que los usuarios no encontrarán aquí ninguna información que no sea la
+versión oficial. Cualquier adición, supresión o modificación de los
+contenidos deberá ser realizada anteriormente en los documentos en inglés.
+Posteriormente, y cuando sea posible, dicho cambio debería aplicarse
+también a las traducciones. Los maintainers de las traducciones aceptan
+contribuciones que son puramente de interés relativo a la traducción (por
+ejemplo, nuevas traducciones, actualizaciones, correcciones, etc.).
+
+Las traducciones tratan de ser lo más precisas posible pero no es posible
+convertir directamente un idioma a otro. Cada idioma tiene su propia
+gramática, y una cultura tras ella, por lo tanto, la traducción de una
+oración al inglés se podría modificar para adaptarla al español. Por esta
+razón, cuando lea esta traducción, puede encontrar algunas diferencias en
+la forma, pero todavía transmiten el mensaje original. A pesar de la gran
+difusión del inglés en el idioma hablado, cuando sea posible, expresiones
+en inglés serán reemplazadas por las palabras correspondientes en español.
+
+Si necesita ayuda para comunicarse con la comunidad de Linux pero no se
+siente cómodo escribiendo en inglés, puede pedir ayuda al maintainer para
+obtener una traducción.
+
+Muchos países hablan español, cada uno con su propia cultura, expresiones,
+y diferencias gramaticales en ocasiones significativas. Las traducciones de
+los maintainers pueden utilizar el español con el que dichos maintainers se
+sientan más cómodos. En principio, estas pequeñas diferencias no deberían
+suponer una gran barrera para hablantes de distintas versiones del español,
+pero en caso de duda se puede consultar a los maintainers.
+
+La documentación del kernel Linux
+=================================
+
+Este es el nivel superior de la documentación del kernel en idioma español.
+La traducción es incompleta, y podría encontrar advertencias que indiquen
+la falta de una traducción o de un grupo de traducciones.
+
+En términos más generales, la documentación, como el kernel mismo, están en
+constante desarrollo. Las mejoras en la documentación siempre son
+bienvenidas; de modo que, si desea ayudar, únase a la lista de correo
+linux-doc en vger.kernel.org.
diff --git a/MAINTAINERS b/MAINTAINERS
index 944dc265b64d..b3133f013efb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19150,6 +19150,11 @@ W: https://linuxtv.org
Q: http://patchwork.linuxtv.org/project/linux-media/list/
F: drivers/media/dvb-frontends/sp2*
+SPANISH DOCUMENTATION
+M: Carlos Bilbao <[email protected]>
+S: Maintained
+F: Documentation/translations/sp_SP/
+
SPARC + UltraSPARC (sparc/sparc64)
M: "David S. Miller" <[email protected]>
L: [email protected]
--
2.34.1
Carlos Bilbao <[email protected]> writes:
> Spanish is the second most spoken language in the world. This patch set
> starts the process of translating critical kernel documentation into the
> Spanish language.
>
> Link to v2: https://lkml.org/lkml/2022/10/13/866
> Changes since v2:
> - Apply improvements proposed by Miguel Ojeda
> - Added Reviewed-By of Miguel Ojeda for first commit
> - Added Reviwed-By of Bagas Sanjaya for second commit
>
> Changes since v1:
> - Added me as MAINTAINER
> - Fixed warnings of kernel test robot
> - Use imperative form in second commit
> - Improved minor translation details
>
> Carlos Bilbao (2):
> Documentation: Start translations to Spanish
> Documentation: Add HOWTO Spanish translation into rst based build system
>
> Documentation/translations/index.rst | 1 +
> .../translations/sp_SP/disclaimer-sp.rst | 6 +
> Documentation/translations/sp_SP/howto.rst | 617 ++++++++++++++++++
> Documentation/translations/sp_SP/index.rst | 80 +++
> MAINTAINERS | 5 +
> 5 files changed, 709 insertions(+)
> create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
> create mode 100644 Documentation/translations/sp_SP/howto.rst
> create mode 100644 Documentation/translations/sp_SP/index.rst
I went to apply this series just now, and got the following from "git
am":
WARNING: Message contains suspicious unicode control characters!
Subject: [PATCH v3 2/2] Documentation: Add HOWTO Spanish translation into rst based build system
Line: +estable más reciente del kernel, y no están interesados en ayudar a probar
---------------------------------------------------------------^
Char: ZERO WIDTH SPACE (0x200b)
If you are sure about this, rerun with the right flag to allow.
Any idea what the story is there? Could I get a resend without that
problem?
Thanks,
jon
Carlos Bilbao <[email protected]> writes:
> On 11/1/22 16:30, Jonathan Corbet wrote:
>
>>
>>
>> I went to apply this series just now, and got the following from "git
>> am":
>>
>> WARNING: Message contains suspicious unicode control characters!
>> Subject: [PATCH v3 2/2] Documentation: Add HOWTO Spanish translation into rst based build system
>> Line: +estable más reciente del kernel, y no están interesados en ayudar a probar
>> ---------------------------------------------------------------^
>> Char: ZERO WIDTH SPACE (0x200b)
>> If you are sure about this, rerun with the right flag to allow.
>>
>> Any idea what the story is there? Could I get a resend without that
>> problem?
> Just tried to apply git am and didn't get any warning. Maybe you are using
> an extra flag? I'm running with git version 2.34.1. Could you try replacing
> the offending char with a space? Hopefully that solves it.
I'm sorry, it was b4 that complained, not git. To see it happen, try:
b4 am [email protected]
There were, in fact, two zero-width spaces in there, and two more in
Junio Hamano's name. I've taken them all out, and learned all about
searching for weird characters in Emacs as a side benefit :)
Series is now applied, thanks.
jon
On 11/1/22 16:30, Jonathan Corbet wrote:
> Carlos Bilbao <[email protected]> writes:
>
>> Spanish is the second most spoken language in the world. This patch set
>> starts the process of translating critical kernel documentation into the
>> Spanish language.
>>
>> Link to v2: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2022%2F10%2F13%2F866&data=05%7C01%7Ccarlos.bilbao%40amd.com%7Cc3cb093ef27e484b78fa08dabc503ce0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638029350093417289%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dKxHmWM4ljRyAZUw%2BpZ%2BxVM1KxIM5pR098RqnV7w2gs%3D&reserved=0
>> Changes since v2:
>> - Apply improvements proposed by Miguel Ojeda
>> - Added Reviewed-By of Miguel Ojeda for first commit
>> - Added Reviwed-By of Bagas Sanjaya for second commit
>>
>> Changes since v1:
>> - Added me as MAINTAINER
>> - Fixed warnings of kernel test robot
>> - Use imperative form in second commit
>> - Improved minor translation details
>>
>> Carlos Bilbao (2):
>> Documentation: Start translations to Spanish
>> Documentation: Add HOWTO Spanish translation into rst based build system
>>
>> Documentation/translations/index.rst | 1 +
>> .../translations/sp_SP/disclaimer-sp.rst | 6 +
>> Documentation/translations/sp_SP/howto.rst | 617 ++++++++++++++++++
>> Documentation/translations/sp_SP/index.rst | 80 +++
>> MAINTAINERS | 5 +
>> 5 files changed, 709 insertions(+)
>> create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
>> create mode 100644 Documentation/translations/sp_SP/howto.rst
>> create mode 100644 Documentation/translations/sp_SP/index.rst
> I went to apply this series just now, and got the following from "git
> am":
>
> WARNING: Message contains suspicious unicode control characters!
> Subject: [PATCH v3 2/2] Documentation: Add HOWTO Spanish translation into rst based build system
> Line: +estable más reciente del kernel, y no están interesados en ayudar a probar
> ---------------------------------------------------------------^
> Char: ZERO WIDTH SPACE (0x200b)
> If you are sure about this, rerun with the right flag to allow.
>
> Any idea what the story is there? Could I get a resend without that
> problem?
Just tried to apply git am and didn't get any warning. Maybe you are using
an extra flag? I'm running with git version 2.34.1. Could you try replacing
the offending char with a space? Hopefully that solves it.
I apologize for the inconvenience.
Carlos.
>
> Thanks,
>
> jon
On 11/2/22 05:59, Jonathan Corbet wrote:
>
> I'm sorry, it was b4 that complained, not git. To see it happen, try:
>
> b4 am [email protected]
>
> There were, in fact, two zero-width spaces in there, and two more in
> Junio Hamano's name. I've taken them all out, and learned all about
> searching for weird characters in Emacs as a side benefit :)
>
> Series is now applied, thanks.
>
Hi jon,
There is still outstanding issue regarding language identifier slug [1],
which isn't addressed yet.
[1]: https://lore.kernel.org/linux-doc/[email protected]/
[2]: https://lore.kernel.org/linux-doc/[email protected]/
Thanks.
--
An old man doll... just what I always wanted! - Clara
On Wed, 2 Nov 2022 16:13:57 +0700, Bagas Sanjaya wrote:
> On 11/2/22 05:59, Jonathan Corbet wrote:
>>
>> I'm sorry, it was b4 that complained, not git. To see it happen, try:
>>
>> b4 am [email protected]
>>
>> There were, in fact, two zero-width spaces in there, and two more in
>> Junio Hamano's name. I've taken them all out, and learned all about
>> searching for weird characters in Emacs as a side benefit :)
>>
>> Series is now applied, thanks.
>>
>
> Hi jon,
>
> There is still outstanding issue regarding language identifier slug [1],
> which isn't addressed yet.
>
> [1]: https://lore.kernel.org/linux-doc/[email protected]/
To be clear, I'm OK with sp_SP/ with the explanation given in the changelog
of v3 1/2.
Regards,
Akira
> [2]: https://lore.kernel.org/linux-doc/[email protected]/
>
> Thanks.
>
Bagas Sanjaya <[email protected]> writes:
> On 11/2/22 05:59, Jonathan Corbet wrote:
>>
>> I'm sorry, it was b4 that complained, not git. To see it happen, try:
>>
>> b4 am [email protected]
>>
>> There were, in fact, two zero-width spaces in there, and two more in
>> Junio Hamano's name. I've taken them all out, and learned all about
>> searching for weird characters in Emacs as a side benefit :)
>>
>> Series is now applied, thanks.
>>
>
> Hi jon,
>
> There is still outstanding issue regarding language identifier slug [1],
> which isn't addressed yet.
>
> [1]: https://lore.kernel.org/linux-doc/[email protected]/
> [2]: https://lore.kernel.org/linux-doc/[email protected]/
Well, it's clearly somewhat resolved in that I took the patches.
If we want a policy: I think that names not tied to geography are
probably better and that's what we should do in the future. I don't
think it's worth forcing a change on any of the other translations,
though; they can be renamed if the developers involved choose to do so.
jon