diff options
Diffstat (limited to 'Documentation/translations/sp_SP/howto.rst')
| -rw-r--r-- | Documentation/translations/sp_SP/howto.rst | 617 |
1 files changed, 0 insertions, 617 deletions
diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst deleted file mode 100644 index f9818d687b54..000000000000 --- a/Documentation/translations/sp_SP/howto.rst +++ /dev/null @@ -1,617 +0,0 @@ -.. 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/admin-guide/security-bugs.rst <securitybugs>` - Si cree que ha encontrado un problema de seguridad en el kernel de - Linux, siga los pasos de este documento para ayudar a notificar a los - desarrolladores del kernel y ayudar a resolver el problema. - - :ref:`Documentation/process/management-style.rst <managementstyle>` - Este documento describe cómo operan los maintainers del kernel de Linux - y los valores compartidos detrás de sus metodologías. Esta es una - lectura importante para cualquier persona nueva en el desarrollo del - kernel (o cualquier persona que simplemente sienta curiosidad por - el campo IT), ya que clarifica muchos conceptos erróneos y confusiones - comunes sobre el comportamiento único de los maintainers del kernel. - - :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>` - Este archivo describe las reglas sobre cómo se suceden las versiones - del kernel estable, y qué hacer si desea obtener un cambio en una de - estas publicaciones. - - :ref:`Documentation/process/kernel-docs.rst <kernel_docs>` - Una lista de documentación externa relativa al desarrollo del kernel. - Por favor consulte esta lista si no encuentra lo que están buscando - dentro de la documentación del kernel. - - :ref:`Documentation/process/applying-patches.rst <applying_patches>` - Una buena introducción que describe exactamente qué es un parche y cómo - aplicarlo a las diferentes ramas de desarrollo del kernel. - -El kernel también tiene una gran cantidad de documentos que pueden ser -generados automáticamente desde el propio código fuente o desde -ReStructuredText markups (ReST), como este. Esto incluye un descripción -completa de la API en el kernel y reglas sobre cómo manejar cerrojos -(locking) correctamente. - -Todos estos documentos se pueden generar como PDF o HTML ejecutando:: - - make pdfdocs - make htmldocs - -respectivamente desde el directorio fuente principal del kernel. - -Los documentos que utilizan el markup ReST se generarán en -Documentation/output. También se pueden generar en formatos LaTeX y ePub -con:: - - make latexdocs - make epubdocs - -Convertirse en un/a desarrollador/a de kernel ---------------------------------------------- - -Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar -el proyecto Linux KernelNewbies: - - https://kernelnewbies.org - -Consiste en una útil lista de correo donde puede preguntar casi cualquier -tipo de pregunta básica de desarrollo del kernel (asegúrese de buscar en -los archivos primero, antes de preguntar algo que ya ha sido respondido en -el pasado.) También tiene un canal IRC que puede usar para hacer preguntas -en tiempo real, y una gran cantidad de documentación útil para ir -aprendiendo sobre el desarrollo del kernel de Linux. - -El sitio web tiene información básica sobre la organización del código, -subsistemas, y proyectos actuales (tanto dentro como fuera del árbol). -También describe alguna información logística básica, como cómo compilar -un kernel y aplicar un parche. - -Si no sabe por dónde quiere empezar, pero quieres buscar alguna tarea que -comenzar a hacer para unirse a la comunidad de desarrollo del kernel, -acuda al proyecto Linux Kernel Janitor: - - https://kernelnewbies.org/KernelJanitors - -Es un gran lugar para comenzar. Describe una lista de problemas -relativamente simples que deben limpiarse y corregirse dentro del código -fuente del kernel de Linux árbol de fuentes. Trabajando con los -desarrolladores a cargo de este proyecto, aprenderá los conceptos básicos -para incluir su parche en el árbol del kernel de Linux, y posiblemente -descubrir en la dirección en que trabajar a continuación, si no tiene ya -una idea. - -Antes de realizar cualquier modificación real al código del kernel de -Linux, es imperativo entender cómo funciona el código en cuestión. Para -este propósito, nada es mejor que leerlo directamente (lo más complicado -está bien comentado), tal vez incluso con la ayuda de herramientas -especializadas. Una de esas herramientas que se recomienda especialmente -es el proyecto Linux Cross-Reference, que es capaz de presentar el código -fuente en un formato de página web indexada y autorreferencial. Una -excelente puesta al día del repositorio del código del kernel se puede -encontrar en: - - https://elixir.bootlin.com/ - -El proceso de desarrollo ------------------------- - -El proceso de desarrollo del kernel de Linux consiste actualmente de -diferentes "branches" (ramas) con muchos distintos subsistemas específicos -a cada una de ellas. Las diferentes ramas son: - - - El código principal de Linus (mainline tree) - - Varios árboles estables con múltiples major numbers - - Subsistemas específicos - - linux-next, para integración y testing - -Mainline tree (Árbol principal) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -El mainline tree es mantenido por Linus Torvalds, y puede encontrarse en -https://kernel.org o en su repo. El proceso de desarrollo es el siguiente: - - - Tan pronto como se lanza un nuevo kernel, se abre una ventana de dos - semanas, durante este período de tiempo, los maintainers pueden enviar - grandes modificaciones a Linus, por lo general los parches que ya se - han incluido en el linux-next durante unas semanas. La forma preferida - de enviar grandes cambios es usando git (la herramienta de - administración de código fuente del kernel, más información al respecto - en https://git-scm.com/), pero los parches simples también son validos. - - Después de dos semanas, se lanza un kernel -rc1 y la atención se centra - en hacer el kernel nuevo lo más estable ("solido") posible. La mayoría - de los parches en este punto deben arreglar una regresión. Los errores - que siempre han existido no son regresiones, por lo tanto, solo envíe - este tipo de correcciones si son importantes. Tenga en cuenta que se - podría aceptar un controlador (o sistema de archivos) completamente - nuevo después de -rc1 porque no hay riesgo de causar regresiones con - tal cambio, siempre y cuando el cambio sea autónomo y no afecte áreas - fuera del código que se está agregando. git se puede usar para enviar - parches a Linus después de que se lance -rc1, pero los parches también - deben ser enviado a una lista de correo pública para su revisión. - - Se lanza un nuevo -rc cada vez que Linus considera que el árbol git - actual esta en un estado razonablemente sano y adecuado para la prueba. - La meta es lanzar un nuevo kernel -rc cada semana. - - El proceso continúa hasta que el kernel se considera "listo", y esto - puede durar alrededor de 6 semanas. - -Vale la pena mencionar lo que Andrew Morton escribió en las listas de -correo del kernel de Linux, sobre lanzamientos del kernel (traducido): - - *"Nadie sabe cuándo se publicara un nuevo kernel, pues esto sucede - según el estado de los bugs, no de una cronología preconcebida."* - -Varios árboles estables con múltiples major numbers -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Los kernels con versiones de 3 partes son kernels estables. Estos contienen -correcciones relativamente pequeñas y críticas para problemas de seguridad -o importantes regresiones descubiertas para una publicación de código. -Cada lanzamiento en una gran serie estable incrementa la tercera parte de -la versión número, manteniendo las dos primeras partes iguales. - -Esta es la rama recomendada para los usuarios que quieren la versión -estable más reciente del kernel, y no están interesados en ayudar a probar -versiones en desarrollo/experimentales. - -Los árboles estables son mantenidos por el equipo "estable" -<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> |