¡Hola Carlos! Gracias for start writing Spanish translations. However, the patch can be improved, see below. 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". > Signed-off-by: Carlos Bilbao <carlos.bilbao@xxxxxxx> > --- > 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@xxxxxxx> > + > +.. _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@xxxxxxxxx, y CC la lista linux-api@xxxxxxxxxxxxxxx. > + > +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@xxxxxxxxxxxxxxx>, 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@xxxxxxxxx> kernel test robot have already reported documentation warnings at [1], so I have applied the fixup: ---- >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). [1]: https://lore.kernel.org/linux-doc/202210141348.7UGXRUp8-lkp@xxxxxxxxx/ -- An old man doll... just what I always wanted! - Clara
Attachment:
signature.asc
Description: PGP signature
