From 3a21a218a7b6cc92588e6c7a11bfa9b723020094 Mon Sep 17 00:00:00 2001 From: Avadhut Naik Date: Sun, 10 Dec 2023 20:37:30 -0600 Subject: docs/sp_SP: Move howto.rst into /sp_SP/process/ Move the howto.rst file in Spanish translation to /sp_SP/process/ to ensure its location is symmetrical to its corresponding version in English. Signed-off-by: Avadhut Naik Reviewed-by: Carlos Bilbao Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20231211023730.2026204-5-avadhut.naik@amd.com --- Documentation/translations/sp_SP/howto.rst | 617 --------------------- Documentation/translations/sp_SP/index.rst | 1 - Documentation/translations/sp_SP/process/howto.rst | 617 +++++++++++++++++++++ Documentation/translations/sp_SP/process/index.rst | 1 + 4 files changed, 618 insertions(+), 618 deletions(-) delete mode 100644 Documentation/translations/sp_SP/howto.rst create mode 100644 Documentation/translations/sp_SP/process/howto.rst (limited to 'Documentation/translations') diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst deleted file mode 100644 index f1629738b49d..000000000000 --- a/Documentation/translations/sp_SP/howto.rst +++ /dev/null @@ -1,617 +0,0 @@ -.. include:: ./disclaimer-sp.rst - -:Original: :ref:`Documentation/process/howto.rst ` -:Translator: Carlos Bilbao - -.. _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 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 ` - 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 ` - 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 ` - 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 ` - 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 ` - 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/process/security-bugs.rst ` - 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 ` - 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 ` - 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 ` - 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 ` - 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" -, 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 ` -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 `. -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 diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst index 5c2a2131524b..c543b495c042 100644 --- a/Documentation/translations/sp_SP/index.rst +++ b/Documentation/translations/sp_SP/index.rst @@ -76,6 +76,5 @@ Traducciones al español .. toctree:: :maxdepth: 1 - howto process/index wrappers/memory-barriers diff --git a/Documentation/translations/sp_SP/process/howto.rst b/Documentation/translations/sp_SP/process/howto.rst new file mode 100644 index 000000000000..dd793c0f8574 --- /dev/null +++ b/Documentation/translations/sp_SP/process/howto.rst @@ -0,0 +1,617 @@ +.. include:: ../disclaimer-sp.rst + +:Original: :ref:`Documentation/process/howto.rst ` +:Translator: Carlos Bilbao + +.. _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 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 ` + 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 ` + 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 ` + 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 ` + 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 ` + 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/process/security-bugs.rst ` + 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 ` + 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 ` + 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 ` + 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 ` + 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" +, 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 ` +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 `. +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 diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst index ebafa0e6055d..2239373b3999 100644 --- a/Documentation/translations/sp_SP/process/index.rst +++ b/Documentation/translations/sp_SP/process/index.rst @@ -27,3 +27,4 @@ handling-regressions management-style submit-checklist + howto -- cgit v1.2.3