1.. include:: ../disclaimer-sp.rst 2 3:Original: :ref:`Documentation/process/howto.rst <process_howto>` 4:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> 5 6.. _sp_process_howto: 7 8Cómo participar en el desarrollo del kernel de Linux 9==================================================== 10 11Este documento es el principal punto de partida. Contiene instrucciones 12sobre cómo convertirse en desarrollador del kernel de Linux y explica cómo 13trabajar con el y en su desarrollo. El documento no tratará ningún aspecto 14técnico relacionado con la programación del kernel, pero le ayudará 15guiándole por el camino correcto. 16 17Si algo en este documento quedara obsoleto, envíe parches al maintainer de 18este archivo, que se encuentra en la parte superior del documento. 19 20Introducción 21------------ 22¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del 23kernel de Linux? Tal vez su jefe le haya dicho, "Escriba un driver de 24Linux para este dispositivo." El objetivo de este documento en enseñarle 25todo cuanto necesita para conseguir esto, describiendo el proceso por el 26que debe pasar, y con indicaciones de como trabajar con la comunidad. 27También trata de explicar las razones por las cuales la comunidad trabaja 28de la forma en que lo hace. 29 30El kernel esta principalmente escrito en C, con algunas partes que son 31dependientes de la arquitectura en ensamblador. Un buen conocimiento de C 32es necesario para desarrollar en el kernel. Lenguaje ensamblador (en 33cualquier arquitectura) no es necesario excepto que planee realizar 34desarrollo de bajo nivel para dicha arquitectura. Aunque no es un perfecto 35sustituto para una educación sólida en C y/o años de experiencia, los 36siguientes libros sirven, como mínimo, como referencia: 37 38- "The C Programming Language" de Kernighan e Ritchie [Prentice Hall] 39- "Practical C Programming" de Steve Oualline [O'Reilly] 40- "C: A Reference Manual" de Harbison and Steele [Prentice Hall] 41 42El kernel está escrito usando GNU C y la cadena de herramientas GNU. Si 43bien se adhiere al estándar ISO C89, utiliza una serie de extensiones que 44no aparecen en dicho estándar. El kernel usa un C independiente de entorno, 45sin depender de la biblioteca C estándar, por lo que algunas partes del 46estándar C no son compatibles. Divisiones de long long arbitrarios o 47de coma flotante no son permitidas. En ocasiones, puede ser difícil de 48entender las suposiciones que el kernel hace respecto a la cadena de 49herramientas y las extensiones que usa, y desafortunadamente no hay 50referencia definitiva para estas. Consulte las páginas de información de 51gcc (`info gcc`) para obtener información al respecto. 52 53Recuerde que está tratando de aprender a trabajar con una comunidad de 54desarrollo existente. Es un grupo diverso de personas, con altos estándares 55de código, estilo y procedimiento. Estas normas han sido creadas a lo 56largo del tiempo en función de lo que se ha encontrado que funciona mejor 57para un equipo tan grande y geográficamente disperso. Trate de aprender 58tanto como le sea posible acerca de estos estándares antes de tiempo, ya 59que están bien documentados; no espere que la gente se adapte a usted o a 60la forma de hacer las cosas en su empresa. 61 62Cuestiones legales 63------------------ 64El código fuente del kernel de Linux se publica bajo licencia GPL. Por 65favor, revise el archivo COPYING, presente en la carpeta principal del 66código fuente, para detalles de la licencia. Si tiene alguna otra pregunta 67sobre licencias, contacte a un abogado, no pregunte en listas de discusión 68del kernel de Linux. La gente en estas listas no son abogadas, y no debe 69confiar en sus opiniones en materia legal. 70 71Para preguntas y respuestas más frecuentes sobre la licencia GPL, consulte: 72 73 https://www.gnu.org/licenses/gpl-faq.html 74 75Documentación 76-------------- 77El código fuente del kernel de Linux tiene una gran variedad de documentos 78que son increíblemente valiosos para aprender a interactuar con la 79comunidad del kernel. Cuando se agregan nuevas funciones al kernel, se 80recomienda que se incluyan nuevos archivos de documentación que expliquen 81cómo usar la función. Cuando un cambio en el kernel hace que la interfaz 82que el kernel expone espacio de usuario cambie, se recomienda que envíe la 83información o un parche en las páginas del manual que expliquen el cambio 84a mtk.manpages@gmail.com, y CC la lista linux-api@vger.kernel.org. 85 86Esta es la lista de archivos que están en el código fuente del kernel y son 87de obligada lectura: 88 89 :ref:`Documentation/admin-guide/README.rst <readme>` 90 Este archivo ofrece una breve descripción del kernel de Linux y 91 describe lo que es necesario hacer para configurar y compilar el 92 kernel. Quienes sean nuevos en el kernel deben comenzar aquí. 93 94 :ref:`Documentation/process/changes.rst <changes>` 95 Este archivo proporciona una lista de los niveles mínimos de varios 96 paquetes que son necesarios para construir y ejecutar el kernel 97 exitosamente. 98 99 :ref:`Documentation/process/coding-style.rst <codingstyle>` 100 Esto describe el estilo de código del kernel de Linux y algunas de los 101 razones detrás de esto. Se espera que todo el código nuevo siga las 102 directrices de este documento. La mayoría de los maintainers solo 103 aceptarán parches si se siguen estas reglas, y muchas personas solo 104 revisan el código si tiene el estilo adecuado. 105 106 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` 107 Este archivo describe en gran detalle cómo crear con éxito y enviar un 108 parche, que incluye (pero no se limita a): 109 110 - Contenidos del correo electrónico (email) 111 - Formato del email 112 - A quien se debe enviar 113 114 Seguir estas reglas no garantiza el éxito (ya que todos los parches son 115 sujetos a escrutinio de contenido y estilo), pero en caso de no seguir 116 dichas reglas, el fracaso es prácticamente garantizado. 117 Otras excelentes descripciones de cómo crear parches correctamente son: 118 119 "The Perfect Patch" 120 https://www.ozlabs.org/~akpm/stuff/tpp.txt 121 122 "Linux kernel patch submission format" 123 https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html 124 125 :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>` 126 Este archivo describe la lógica detrás de la decisión consciente de 127 no tener una API estable dentro del kernel, incluidas cosas como: 128 129 - Capas intermedias del subsistema (por compatibilidad?) 130 - Portabilidad de drivers entre sistemas operativos 131 - Mitigar el cambio rápido dentro del árbol de fuentes del kernel (o 132 prevenir cambios rápidos) 133 134 Este documento es crucial para comprender la filosofía del desarrollo 135 de Linux y es muy importante para las personas que se mudan a Linux 136 tras desarrollar otros sistemas operativos. 137 138 :ref:`Documentation/process/security-bugs.rst <securitybugs>` 139 Si cree que ha encontrado un problema de seguridad en el kernel de 140 Linux, siga los pasos de este documento para ayudar a notificar a los 141 desarrolladores del kernel y ayudar a resolver el problema. 142 143 :ref:`Documentation/process/management-style.rst <managementstyle>` 144 Este documento describe cómo operan los maintainers del kernel de Linux 145 y los valores compartidos detrás de sus metodologías. Esta es una 146 lectura importante para cualquier persona nueva en el desarrollo del 147 kernel (o cualquier persona que simplemente sienta curiosidad por 148 el campo IT), ya que clarifica muchos conceptos erróneos y confusiones 149 comunes sobre el comportamiento único de los maintainers del kernel. 150 151 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>` 152 Este archivo describe las reglas sobre cómo se suceden las versiones 153 del kernel estable, y qué hacer si desea obtener un cambio en una de 154 estas publicaciones. 155 156 :ref:`Documentation/process/kernel-docs.rst <kernel_docs>` 157 Una lista de documentación externa relativa al desarrollo del kernel. 158 Por favor consulte esta lista si no encuentra lo que están buscando 159 dentro de la documentación del kernel. 160 161 :ref:`Documentation/process/applying-patches.rst <applying_patches>` 162 Una buena introducción que describe exactamente qué es un parche y cómo 163 aplicarlo a las diferentes ramas de desarrollo del kernel. 164 165El kernel también tiene una gran cantidad de documentos que pueden ser 166generados automáticamente desde el propio código fuente o desde 167ReStructuredText markups (ReST), como este. Esto incluye un descripción 168completa de la API en el kernel y reglas sobre cómo manejar cerrojos 169(locking) correctamente. 170 171Todos estos documentos se pueden generar como PDF o HTML ejecutando:: 172 173 make pdfdocs 174 make htmldocs 175 176respectivamente desde el directorio fuente principal del kernel. 177 178Los documentos que utilizan el markup ReST se generarán en 179Documentation/output. También se pueden generar en formatos LaTeX y ePub 180con:: 181 182 make latexdocs 183 make epubdocs 184 185Convertirse en un/a desarrollador/a de kernel 186--------------------------------------------- 187 188Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar 189el proyecto Linux KernelNewbies: 190 191 https://kernelnewbies.org 192 193Consiste en una útil lista de correo donde puede preguntar casi cualquier 194tipo de pregunta básica de desarrollo del kernel (asegúrese de buscar en 195los archivos primero, antes de preguntar algo que ya ha sido respondido en 196el pasado.) También tiene un canal IRC que puede usar para hacer preguntas 197en tiempo real, y una gran cantidad de documentación útil para ir 198aprendiendo sobre el desarrollo del kernel de Linux. 199 200El sitio web tiene información básica sobre la organización del código, 201subsistemas, y proyectos actuales (tanto dentro como fuera del árbol). 202También describe alguna información logística básica, como cómo compilar 203un kernel y aplicar un parche. 204 205Si no sabe por dónde quiere empezar, pero quieres buscar alguna tarea que 206comenzar a hacer para unirse a la comunidad de desarrollo del kernel, 207acuda al proyecto Linux Kernel Janitor: 208 209 https://kernelnewbies.org/KernelJanitors 210 211Es un gran lugar para comenzar. Describe una lista de problemas 212relativamente simples que deben limpiarse y corregirse dentro del código 213fuente del kernel de Linux árbol de fuentes. Trabajando con los 214desarrolladores a cargo de este proyecto, aprenderá los conceptos básicos 215para incluir su parche en el árbol del kernel de Linux, y posiblemente 216descubrir en la dirección en que trabajar a continuación, si no tiene ya 217una idea. 218 219Antes de realizar cualquier modificación real al código del kernel de 220Linux, es imperativo entender cómo funciona el código en cuestión. Para 221este propósito, nada es mejor que leerlo directamente (lo más complicado 222está bien comentado), tal vez incluso con la ayuda de herramientas 223especializadas. Una de esas herramientas que se recomienda especialmente 224es el proyecto Linux Cross-Reference, que es capaz de presentar el código 225fuente en un formato de página web indexada y autorreferencial. Una 226excelente puesta al día del repositorio del código del kernel se puede 227encontrar en: 228 229 https://elixir.bootlin.com/ 230 231El proceso de desarrollo 232------------------------ 233 234El proceso de desarrollo del kernel de Linux consiste actualmente de 235diferentes "branches" (ramas) con muchos distintos subsistemas específicos 236a cada una de ellas. Las diferentes ramas son: 237 238 - El código principal de Linus (mainline tree) 239 - Varios árboles estables con múltiples major numbers 240 - Subsistemas específicos 241 - linux-next, para integración y testing 242 243Mainline tree (Árbol principal) 244~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 245 246El mainline tree es mantenido por Linus Torvalds, y puede encontrarse en 247https://kernel.org o en su repo. El proceso de desarrollo es el siguiente: 248 249 - Tan pronto como se lanza un nuevo kernel, se abre una ventana de dos 250 semanas, durante este período de tiempo, los maintainers pueden enviar 251 grandes modificaciones a Linus, por lo general los parches que ya se 252 han incluido en el linux-next durante unas semanas. La forma preferida 253 de enviar grandes cambios es usando git (la herramienta de 254 administración de código fuente del kernel, más información al respecto 255 en https://git-scm.com/), pero los parches simples también son validos. 256 - Después de dos semanas, se lanza un kernel -rc1 y la atención se centra 257 en hacer el kernel nuevo lo más estable ("solido") posible. La mayoría 258 de los parches en este punto deben arreglar una regresión. Los errores 259 que siempre han existido no son regresiones, por lo tanto, solo envíe 260 este tipo de correcciones si son importantes. Tenga en cuenta que se 261 podría aceptar un controlador (o sistema de archivos) completamente 262 nuevo después de -rc1 porque no hay riesgo de causar regresiones con 263 tal cambio, siempre y cuando el cambio sea autónomo y no afecte áreas 264 fuera del código que se está agregando. git se puede usar para enviar 265 parches a Linus después de que se lance -rc1, pero los parches también 266 deben ser enviado a una lista de correo pública para su revisión. 267 - Se lanza un nuevo -rc cada vez que Linus considera que el árbol git 268 actual esta en un estado razonablemente sano y adecuado para la prueba. 269 La meta es lanzar un nuevo kernel -rc cada semana. 270 - El proceso continúa hasta que el kernel se considera "listo", y esto 271 puede durar alrededor de 6 semanas. 272 273Vale la pena mencionar lo que Andrew Morton escribió en las listas de 274correo del kernel de Linux, sobre lanzamientos del kernel (traducido): 275 276 *"Nadie sabe cuándo se publicara un nuevo kernel, pues esto sucede 277 según el estado de los bugs, no de una cronología preconcebida."* 278 279Varios árboles estables con múltiples major numbers 280~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 281 282Los kernels con versiones de 3 partes son kernels estables. Estos contienen 283correcciones relativamente pequeñas y críticas para problemas de seguridad 284o importantes regresiones descubiertas para una publicación de código. 285Cada lanzamiento en una gran serie estable incrementa la tercera parte de 286la versión número, manteniendo las dos primeras partes iguales. 287 288Esta es la rama recomendada para los usuarios que quieren la versión 289estable más reciente del kernel, y no están interesados en ayudar a probar 290versiones en desarrollo/experimentales. 291 292Los árboles estables son mantenidos por el equipo "estable" 293<stable@vger.kernel.org>, y se liberan (publican) según lo dicten las 294necesidades. El período de liberación normal es de aproximadamente dos 295semanas, pero puede ser más largo si no hay problemas apremiantes. Un 296problema relacionado con la seguridad, en cambio, puede causar un 297lanzamiento casi instantáneamente. 298 299El archivo :ref:`Documentación/proceso/stable-kernel-rules.rst <stable_kernel_rules>` 300en el árbol del kernel documenta qué tipos de cambios son aceptables para 301el árbol estable y cómo funciona el proceso de lanzamiento. 302 303Subsistemas específicos 304~~~~~~~~~~~~~~~~~~~~~~~~ 305Los maintainers de los diversos subsistemas del kernel --- y también muchos 306desarrolladores de subsistemas del kernel --- exponen su estado actual de 307desarrollo en repositorios fuente. De esta manera, otros pueden ver lo que 308está sucediendo en las diferentes áreas del kernel. En áreas donde el 309desarrollo es rápido, se le puede pedir a un desarrollador que base sus 310envíos en tal árbol del subsistema del kernel, para evitar conflictos entre 311este y otros trabajos ya en curso. 312 313La mayoría de estos repositorios son árboles git, pero también hay otros 314SCM en uso, o colas de parches que se publican como series quilt. Las 315direcciones de estos repositorios de subsistemas se enumeran en el archivo 316MAINTAINERS. Muchos de estos se pueden ver en https://git.kernel.org/. 317 318Antes de que un parche propuesto se incluya con dicho árbol de subsistemas, 319es sujeto a revisión, que ocurre principalmente en las listas de correo 320(ver la sección respectiva a continuación). Para varios subsistemas del 321kernel, esta revisión se rastrea con la herramienta patchwork. Patchwork 322ofrece una interfaz web que muestra publicaciones de parches, cualquier 323comentario sobre un parche o revisiones a él, y los maintainers pueden 324marcar los parches como en revisión, aceptado, o rechazado. La mayoría de 325estos sitios de trabajo de parches se enumeran en 326 327https://patchwork.kernel.org/. 328 329linux-next, para integración y testing 330~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 331 332Antes de que las actualizaciones de los árboles de subsistemas se combinen 333con el árbol principal, necesitan probar su integración. Para ello, existe 334un repositorio especial de pruebas en el que se encuentran casi todos los 335árboles de subsistema, actualizado casi a diario: 336 337 https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git 338 339De esta manera, linux-next ofrece una perspectiva resumida de lo que se 340espera que entre en el kernel principal en el próximo período de "merge" 341(fusión de código). Los testers aventureros son bienvenidos a probar 342linux-next en ejecución. 343 344Reportar bugs 345------------- 346 347El archivo 'Documentación/admin-guide/reporting-issues.rst' en el 348directorio principal del kernel describe cómo informar un posible bug del 349kernel y detalles sobre qué tipo de información necesitan los 350desarrolladores del kernel para ayudar a rastrear la fuente del problema. 351 352Gestión de informes de bugs 353------------------------------ 354 355Una de las mejores formas de poner en práctica sus habilidades de hacking 356es arreglando errores reportados por otras personas. No solo ayudará a 357hacer el kernel más estable, también aprenderá a solucionar problemas del 358mundo real y mejora sus habilidades, y otros desarrolladores se darán 359cuenta de tu presencia. La corrección de errores es una de las mejores 360formas de ganar méritos entre desarrolladores, porque no a muchas personas 361les gusta perder el tiempo arreglando los errores de otras personas. 362 363Para trabajar en informes de errores ya reportados, busque un subsistema 364que le interese. Verifique el archivo MAINTAINERS donde se informan los 365errores de ese subsistema; con frecuencia será una lista de correo, rara 366vez un rastreador de errores (bugtracker). Busque en los archivos de dicho 367lugar para informes recientes y ayude donde lo crea conveniente. También es 368posible que desee revisar https://bugzilla.kernel.org para informes de 369errores; solo un puñado de subsistemas del kernel lo emplean activamente 370para informar o rastrear; sin embargo, todos los errores para todo el kernel 371se archivan allí. 372 373Listas de correo 374----------------- 375 376Como se explica en algunos de los documentos anteriores, la mayoría de 377desarrolladores del kernel participan en la lista de correo del kernel de 378Linux. Detalles sobre cómo para suscribirse y darse de baja de la lista se 379pueden encontrar en: 380 381 http://vger.kernel.org/vger-lists.html#linux-kernel 382 383Existen archivos de la lista de correo en la web en muchos lugares 384distintos. Utilice un motor de búsqueda para encontrar estos archivos. Por 385ejemplo: 386 387 http://dir.gmane.org/gmane.linux.kernel 388 389Es muy recomendable que busque en los archivos sobre el tema que desea 390tratar, antes de publicarlo en la lista. Un montón de cosas ya discutidas 391en detalle solo se registran en los archivos de la lista de correo. 392 393La mayoría de los subsistemas individuales del kernel también tienen sus 394propias lista de correo donde hacen sus esfuerzos de desarrollo. Revise el 395archivo MAINTAINERS para obtener referencias de lo que estas listas para 396los diferentes grupos. 397 398Muchas de las listas están alojadas en kernel.org. La información sobre 399estas puede ser encontrada en: 400 401 http://vger.kernel.org/vger-lists.html 402 403Recuerde mantener buenos hábitos de comportamiento al usar las listas. 404Aunque un poco cursi, la siguiente URL tiene algunas pautas simples para 405interactuar con la lista (o cualquier lista): 406 407 http://www.albion.com/netiquette/ 408 409Si varias personas responden a su correo, el CC (lista de destinatarios) 410puede hacerse bastante grande. No elimine a nadie de la lista CC: sin una 411buena razón, o no responda solo a la dirección de la lista. Acostúmbrese 412a recibir correos dos veces, una del remitente y otra de la lista, y no 413intente ajustar esto agregando encabezados de correo astutos, a la gente no 414le gustará. 415 416Recuerde mantener intacto el contexto y la atribución de sus respuestas, 417mantenga las líneas "El hacker John Kernel escribió ...:" en la parte 418superior de su respuesta, y agregue sus declaraciones entre las secciones 419individuales citadas en lugar de escribiendo en la parte superior del 420correo electrónico. 421 422Si incluye parches en su correo, asegúrese de que sean texto legible sin 423formato como se indica en :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`. 424Los desarrolladores del kernel no quieren lidiar con archivos adjuntos o 425parches comprimidos; y pueden querer comentar líneas individuales de su 426parche, que funciona sólo de esa manera. Asegúrese de emplear un programa 427de correo que no altere los espacios ni los tabuladores. Una buena primera 428prueba es enviarse el correo a usted mismo, e intentar aplicar su 429propio parche. Si eso no funciona, arregle su programa de correo o 430reemplace hasta que funcione. 431 432Sobretodo, recuerde de ser respetuoso con otros subscriptores. 433 434Colaborando con la comunidad 435---------------------------- 436 437El objetivo de la comunidad del kernel es proporcionar el mejor kernel 438posible. Cuando envíe un parche para su aceptación, se revisará en sus 439méritos técnicos solamente. Entonces, ¿qué deberías ser? 440 441 - críticas 442 - comentarios 443 - peticiones de cambios 444 - peticiones de justificaciones 445 - silencio 446 447Recuerde, esto es parte de introducir su parche en el kernel. Tiene que ser 448capaz de recibir críticas y comentarios sobre sus parches, evaluar 449a nivel técnico y re-elaborar sus parches o proporcionar razonamiento claro 450y conciso de por qué no se deben hacer tales cambios. Si no hay respuestas 451a su publicación, espere unos días e intente de nuevo, a veces las cosas se 452pierden dado el gran volumen. 453 454¿Qué no debería hacer? 455 456 - esperar que su parche se acepte sin preguntas 457 - actuar de forma defensiva 458 - ignorar comentarios 459 - enviar el parche de nuevo, sin haber aplicados los cambios pertinentes 460 461En una comunidad que busca la mejor solución técnica posible, siempre habrá 462diferentes opiniones sobre lo beneficioso que es un parche. Tiene que ser 463cooperativo y estar dispuesto a adaptar su idea para que encaje dentro 464del kernel, o al menos esté dispuesto a demostrar que su idea vale la pena. 465Recuerde, estar equivocado es aceptable siempre y cuando estés dispuesto a 466trabajar hacia una solución que sea correcta. 467 468Es normal que las respuestas a su primer parche sean simplemente una lista 469de una docena de cosas que debe corregir. Esto **no** implica que su 470parche no será aceptado, y **no** es personal. Simplemente corrija todos 471los problemas planteados en su parche, y envié otra vez. 472 473Diferencias entre la comunidad kernel y las estructuras corporativas 474-------------------------------------------------------------------- 475 476La comunidad del kernel funciona de manera diferente a la mayoría de los 477entornos de desarrollo tradicionales en empresas. Aquí hay una lista de 478cosas que puede intentar hacer para evitar problemas: 479 480 Cosas buenas que decir respecto a los cambios propuestos: 481 482 - "Esto arregla múltiples problemas." 483 - "Esto elimina 2000 lineas de código." 484 - "Aquí hay un parche que explica lo que intento describir." 485 - "Lo he testeado en 5 arquitecturas distintas..." 486 - "Aquí hay una serie de parches menores que..." 487 - "Esto mejora el rendimiento en maquinas típicas..." 488 489 Cosas negativas que debe evitar decir: 490 491 - "Lo hicimos así en AIX/ptx/Solaris, de modo que debe ser bueno..." 492 - "Llevo haciendo esto 20 años, de modo que..." 493 - "Esto lo necesita mi empresa para ganar dinero" 494 - "Esto es para la linea de nuestros productos Enterprise" 495 - "Aquí esta el documento de 1000 paginas describiendo mi idea" 496 - "Llevo 6 meses trabajando en esto..." 497 - "Aquí esta un parche de 5000 lineas que..." 498 - "He rescrito todo el desastre actual, y aquí esta..." 499 - "Tengo un deadline, y este parche debe aplicarse ahora." 500 501Otra forma en que la comunidad del kernel es diferente a la mayoría de los 502entornos de trabajo tradicionales en ingeniería de software, es la 503naturaleza sin rostro de interacción. Una de las ventajas de utilizar el 504correo electrónico y el IRC como formas principales de comunicación es la 505no discriminación por motivos de género o raza. El entorno de trabajo del 506kernel de Linux acepta a mujeres y minorías porque todo lo que eres es una 507dirección de correo electrónico. El aspecto internacional también ayuda a 508nivelar el campo de juego porque no puede adivinar el género basado en 509el nombre de una persona. Un hombre puede llamarse Andrea y una mujer puede 510llamarse Pat. La mayoría de las mujeres que han trabajado en el kernel de 511Linux y han expresado una opinión han tenido experiencias positivas. 512 513La barrera del idioma puede causar problemas a algunas personas que no se 514sientes cómodas con el inglés. Un buen dominio del idioma puede ser 515necesario para transmitir ideas correctamente en las listas de correo, por 516lo que le recomendamos que revise sus correos electrónicos para asegurarse 517de que tengan sentido en inglés antes de enviarlos. 518 519Divida sus cambios 520--------------------- 521 522La comunidad del kernel de Linux no acepta con gusto grandes fragmentos de 523código, sobretodo a la vez. Los cambios deben introducirse correctamente, 524discutidos y divididos en pequeñas porciones individuales. Esto es casi 525exactamente lo contrario de lo que las empresas están acostumbradas a hacer. 526Su propuesta también debe introducirse muy temprano en el proceso de 527desarrollo, de modo que pueda recibir comentarios sobre lo que está 528haciendo. También deje que la comunidad sienta que está trabajando con 529ellos, y no simplemente usándolos como un vertedero para su función. Sin 530embargo, no envíe 50 correos electrónicos a una vez a una lista de correo, 531su serie de parches debe casi siempre ser más pequeña que eso. 532 533Las razones para dividir las cosas son las siguientes: 534 5351) Los cambios pequeños aumentan la probabilidad de que sus parches sean 536 aplicados, ya que no requieren mucho tiempo o esfuerzo para verificar su 537 exactitud. Un parche de 5 líneas puede ser aplicado por un maintainer 538 con apenas una segunda mirada. Sin embargo, un parche de 500 líneas 539 puede tardar horas en ser revisado en términos de corrección (el tiempo 540 que toma es exponencialmente proporcional al tamaño del parche, o algo 541 así). 542 543 Los parches pequeños también facilitan la depuración cuando algo falla. 544 Es mucho más fácil retirar los parches uno por uno que diseccionar un 545 parche muy grande después de haber sido aplicado (y roto alguna cosa). 546 5472) Es importante no solo enviar pequeños parches, sino también reescribir 548 y simplificar (o simplemente reordenar) los parches antes de enviarlos. 549 550Esta es una analogía del desarrollador del kernel Al Viro (traducida): 551 552 *"Piense en un maestro que califica la tarea de un estudiante de 553 matemáticas. El maestro no quiere ver los intentos y errores del 554 estudiante antes de que se les ocurriera la solución. Quiere ver la 555 respuesta más limpia y elegante. Un buen estudiante lo sabe, y nunca 556 presentaría su trabajo intermedio antes de tener la solución final.* 557 558 *Lo mismo ocurre con el desarrollo del kernel. Los maintainers y 559 revisores no quieren ver el proceso de pensamiento detrás de la solución 560 al problema que se está resolviendo. Quieren ver un solución simple y 561 elegante."* 562 563Puede resultar un reto mantener el equilibrio entre presentar una solución 564elegante y trabajar junto a la comunidad, discutiendo su trabajo inacabado. 565Por lo tanto, es bueno comenzar temprano en el proceso para obtener 566"feedback" y mejorar su trabajo, pero también mantenga sus cambios en 567pequeños trozos que pueden ser aceptados, incluso cuando toda su labor no 568está listo para inclusión en un momento dado. 569 570También tenga en cuenta que no es aceptable enviar parches para su 571inclusión que están sin terminar y serán "arreglados más tarde". 572 573Justifique sus cambios 574---------------------- 575 576Además de dividir sus parches, es muy importante que deje a la comunidad de 577Linux sabe por qué deberían agregar este cambio. Nuevas características 578debe justificarse como necesarias y útiles. 579 580Documente sus cambios 581--------------------- 582 583Cuando envíe sus parches, preste especial atención a lo que dice en el 584texto de su correo electrónico. Esta información se convertirá en el 585ChangeLog del parche, y se conservará para que todos la vean, todo el 586tiempo. Debe describir el parche por completo y contener: 587 588 - por qué los cambios son necesarios 589 - el diseño general de su propuesta 590 - detalles de implementación 591 - resultados de sus experimentos 592 593Para obtener más detalles sobre cómo debería quedar todo esto, consulte la 594sección ChangeLog del documento: 595 596 "The Perfect Patch" 597 https://www.ozlabs.org/~akpm/stuff/tpp.txt 598 599Todas estas cuestiones son a veces son muy difíciles de conseguir. Puede 600llevar años perfeccionar estas prácticas (si es que lo hace). Es un proceso 601continuo de mejora que requiere mucha paciencia y determinación. Pero no se 602rinda, es posible. Muchos lo han hecho antes, y cada uno tuvo que comenzar 603exactamente donde está usted ahora. 604 605---------- 606 607Gracias a Paolo Ciarrocchi que permitió que la sección "Development Process" 608se basara en el texto que había escrito (https://lwn.net/Articles/94386/), 609y a Randy Dunlap y Gerrit Huizenga por algunas de la lista de cosas que 610debes y no debes decir. También gracias a Pat Mochel, Hanna Linder, Randy 611Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, 612Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, 613Keri Harris, Frans Pop, David A. Wheeler, Junio Hamano, Michael Kerrisk y 614Alex Shepard por su revisión, comentarios y contribuciones. Sin su ayuda, 615este documento no hubiera sido posible. 616 617Maintainer: Greg Kroah-Hartman <greg@kroah.com> 618