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