303 lines · plain
1.. include:: ../disclaimer-sp.rst2 3:Original: Documentation/process/1.Intro.rst4:Translator: Avadhut Naik <avadhut.naik@amd.com>5 6.. _sp_development_process_intro:7 8Introducción9============10 11Resumen ejecutivo12-----------------13 14El resto de esta sección cubre el alcance del proceso de desarrollo del15kernel y los tipos de frustraciones que los desarrolladores y sus16empleadores pueden encontrar allí. Hay muchas razones por las que el17código del kernel debe fusionarse con el kernel oficial (“mainline”),18incluyendo la disponibilidad automática para los usuarios, el apoyo de la19comunidad en muchas formas, y la capacidad de influir en la dirección del20desarrollo del kernel. El código contribuido al kernel de Linux debe21estar disponible bajo una licencia compatible con GPL.22 23:ref:`sp_development_process` introduce el proceso de desarrollo, el ciclo24de lanzamiento del kernel y la mecánica de la "ventana de combinación"25(merge window). Se cubren las distintas fases en el desarrollo del parche,26la revisión y, el ciclo de fusión. Hay algunas discusiones sobre27herramientas y listas de correo. Se anima a los desarrolladores que deseen28comenzar con el desarrollo del kernel a encontrar y corregir errores como29ejercicio inicial.30 31:ref:`sp_development_early_stage` cubre la planificación de proyectos en32etapas tempranas, con énfasis en involucrar a la comunidad de desarrollo33lo antes posible.34 35:ref:`sp_development_coding` trata sobre el proceso de codificación. Se36discuten varios escollos encontrados por otros desarrolladores. Se cubren37algunos requisitos para los parches, y hay una introducción a algunas de38las herramientas que pueden ayudar a garantizar que los parches del kernel39sean correctos.40 41:ref:`sp_development_posting` trata sobre el proceso de enviar parches para42su revisión. Para ser tomados en serio por la comunidad de desarrollo,43los parches deben estar correctamente formateados y descritos, y deben44enviarse al lugar correcto. Seguir los consejos de esta sección debería45ayudar a garantizar la mejor recepción posible para su trabajo.46 47:ref:`sp_development_followthrough` cubre lo que sucede después de publicar48parches; el trabajo está lejos de terminar en ese momento. Trabajar con49revisores es una parte crucial del proceso de desarrollo; esta sección50ofrece varios consejos sobre cómo evitar problemas en esta importante51etapa. Se advierte a los desarrolladores que no asuman que el trabajo está52terminado cuando un parche se fusiona en mainline.53 54:ref:`sp_development_advancedtopics` introduce un par de temas “avanzados”:55la administración de parches con git y la revisión de parches publicados56por otros.57 58:ref:`sp_development_conclusion` concluye el documento con punteros a las59fuentes para obtener más información sobre el desarrollo del kernel.60 61De qué trata este documento62---------------------------63 64El kernel de Linux, con más de 8 millones de líneas de código y más de651000 colaboradores en cada versión, en uno de los proyectos de software66libre más grandes y activos que existen. Desde sus humildes comienzos en671991, este kernel ha evolucionado hasta convertirse en el mejor componente68del sistema operativo que se ejecuta en reproductores de música digital69de bolsillo, PC de escritorio, las supercomputadoras más grandes que70existen y todo tipo de sistemas intermedios. Es una solución robusta,71eficiente, y escalable para casi cualquier situación.72 73Con el crecimiento de Linux, ha llegado un aumento en el número de74desarrolladores (y empresas) que desean participar en su desarrollo. Los75vendedores de hardware quieren asegurarse de que Linux sea compatible con76sus productos, lo que hace que esos productos sean atractivos para los77usuarios de Linux. Los vendedores de sistemas embebidos, que utilizan78Linux como componente de un producto integrado, quieren que Linux sea lo79más capaz y adecuado posible para tarea en cuestión. Los distribuidores80y otros vendedores de software que basan sus productos en Linux tienen un81claro interés en las capacidades, el rendimiento, y la fiabilidad del82kernel de Linux. Y los usuarios finales, también, a menudo desearán83cambiar Linux para que se adapte mejor a sus necesidades.84 85Una de las características más convincentes de Linux es que es accesible86a estos desarrolladores; cualquier persona con las habilidades necesarias87puede mejorar Linux e influir en la dirección de su desarrollo. Los88productos propietarios no pueden ofrecer este tipo de apertura, que es una89característica del proceso de software libre. Pero, en todo caso, el90kernel es aún más libre que la mayoría de los otros proyectos de software91libre. Un ciclo típico de desarrollo de kernel de tres meses puede92involucrar a más de 1000 desarrolladores que trabajan para más de 10093empresas diferentes (o sin pertenecer a ninguna empresa).94 95Trabajar con la comunidad de desarrollo del kernel no es especialmente96difícil. Pero, a pesar de eso, muchos colaboradores potenciales han97experimentado dificultades al tratar de hacer el trabajo del kernel. La98comunidad del kernel ha desarrollado sus propias formas distintivas de99operar, lo que le permite funcionar de manera fluida (y producir un100producto de alta calidad) en un entorno donde miles de líneas de código101se cambian todos los días. Por lo tanto, no es sorprendente que el102proceso de desarrollo del kernel de Linux difiera mucho de los métodos de103desarrollo propietarios.104 105El proceso de desarrollo del kernel puede parecer extraño e intimidante106para los nuevos desarrolladores, pero hay buenas razones y una sólida107experiencia detrás de él. Un desarrollador que no entienda las formas de108la comunidad del kernel (o, peor aún, que intente burlarse o eludirlas)109tendrá una experiencia frustrante por delante. La comunidad de110desarrollo, si bien es servicial para aquellos que están tratando de111aprender, tiene poco tiempo para aquellos que no escuchan o que no se112preocupan por el proceso de desarrollo.113 114Se espera que quienes lean este documento puedan evitar esa experiencia115frustrante. Hay mucho material aquí, pero el esfuerzo que implica leerlo116será recompensado en poco tiempo. La comunidad de desarrollo siempre117necesita desarrolladores que ayudan a mejorar el kernel; el siguiente118texto debería ayudarle – o a quienes trabajan para usted, a unirse a119nuestra comunidad.120 121Créditos122--------123 124Este documento fue escrito por Jonathan Corbet, corbet@lwn.net. Ha sido125mejorado por los comentarios de Johannes Berg, James Berry, Alex Chiang,126Roland Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur127Marsh, Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata y128Jochen Voß.129Este trabajo fue respaldado por la Fundación Linux; gracias especialmente130a Amanda McPherson, quien reconoció el valor de este esfuerzo e hizo que131todo sucediera.132 133Importancia de integrar el código en el mainline134------------------------------------------------135 136Algunas empresas y desarrolladores ocasionalmente se preguntan por qué137deberían molestarse en aprender cómo trabajar con la comunidad del138kernel y obtener su código en el kernel mainline (el “mainline” es el139kernel mantenido por Linus Torvalds y utilizado como base por los140distribuidores de Linux. A corto plazo, contribuir con código puede141parecer un gasto evitable; parece más fácil mantener el código separado142y dar soporte a los usuarios directamente. La verdad del asunto es que143mantener el código separado (“fuera del árbol”) es pan para hoy y hambre144para mañana.145 146Para ilustrar los costos del código fuera-del-árbol, aquí hay algunos147aspectos relevantes del proceso de desarrollo del kernel. La mayoría de148estos se discutirán con mayor detalle más adelante en este documento.149Considerar:150 151- El código que se ha fusionado con el kernel mainline está disponible152 para todos los usuarios de Linux. Estará presente automáticamente en153 todas las distribuciones que lo habiliten. No hay necesidad de discos154 de controladores, descargas, o las molestias de admitir múltiples155 versiones de múltiples distribuciones; todo simplemente funciona, para156 el desarrollador y para el usuario. La incorporación al mainline157 resuelve un gran número de problemas de distribución y soporte.158 159- Mientras los desarrolladores del kernel se esfuerzan por mantener una160 interfaz estable para el espacio de usuario, la API interna de kernel161 está en constante cambio. La falta de una interfaz interna estable es162 una decisión deliberada de diseño; permite realizar mejoras163 fundamentales en cualquier momento y da como resultado un código de164 mayor calidad. Pero uno resultado de esa política es que cualquier165 código fuera-del-árbol requiere un mantenimiento constante si va a166 funcionar con los nuevos kernels. Mantener el código fuera-del-árbol167 requiere una cantidad significativa de trabajo sólo para que ese código168 siga funcionando.169 170 En su lugar, el código en el mainline no requiere este trabajo como171 resultado de una regla simple que requiere que cualquier desarrollador172 que realice un cambio en la API también corrija cualquier código que173 se rompa como resultado de ese cambio. Así que, el código fusionado en174 el mainline tiene costos de mantenimiento significativamente más bajos.175 176- Más allá de eso, el código que está en el kernel a menudo será177 mejorado por otros desarrolladores. Resultados sorprendentes pueden178 provenir de capacitar a su comunidad de usuarios y clientes para mejorar179 su producto.180 181- El código del kernel se somete a revisión, tanto antes como después182 de fusionarse con el mainline. No importa cuán fuertes sean las183 habilidades del desarrollador original, este proceso de revisión184 invariablemente encuentra formas en las que se puede mejorar el código.185 A menudo la revisión encuentra errores graves y problemas de seguridad.186 Esto es especialmente cierto para el código que se ha desarrollado en187 un entorno cerrado; dicho código se beneficia fuertemente de la188 revisión por desarrolladores externos. El código fuera-del-árbol es189 de menor calidad.190 191- La participación en el proceso de desarrollo es su manera de influir en192 la dirección del desarrollo del kernel. Los usuarios que se quejan193 desde el sofa son escuchados, pero los desarrolladores activos tienen194 una voz más fuerte – y la capacidad de implementar cambios que hacen195 que el kernel funcione mejor para sus necesidades.196 197- Cuando el código se mantiene por separado, siempre existe la posibilidad198 de que un tercero contribuya a una implementación diferente de una199 característica similar. Si eso sucede, conseguir que su código200 fusionado será mucho más difícil – hasta el punto de la imposibilidad.201 Entonces se enfrentará a las desagradables alternativas de (1) mantener202 una característica no estándar fuera del árbol indefinidamente, o203 (2) abandonar su código y migrar sus usuarios a la versión en el árbol.204 205- La contribución del código es la acción fundamental que hace que todo206 el proceso funcione. Al contribuir con su código, puede agregar nuevas207 funcionalidades al kernel y proporcionar capacidades y ejemplos que son208 útiles para otros desarrolladores del kernel. Si ha desarrollado código209 para Linux (o está pensando en hacerlo), claramente tiene un interés210 en el éxito continuo de esta plataforma; contribuir con código es una211 de las mejores maneras de ayudar a garantizar ese éxito.212 213Todo el razonamiento anterior se aplica a cualquier código de kernel214fuera-del-árbol, incluido el código que se distribuye en forma propietaria215y únicamente en binario. Sin embargo, hay factores adicionales que deben216tenerse en cuenta antes de considerar cualquier tipo de distribución de217código de kernel únicamente en binario. Estos incluyen:218 219- Las cuestiones legales en torno a la distribución de módulos220 propietarios del kernel son, en el mejor de los casos, confusas;221 bastantes titulares de derechos de autor del kernel creen que la222 mayoría de los módulos binarios son productos derivados del kernel y223 que, como resultado, su distribución es una violación de la licencia224 Pública General de GNU (sobre la que se dirá más adelante). El autor225 de este texto no es abogado, y nada en este documento puede considerarse226 asesoramiento legal. Solo los tribunales pueden determinar el verdadero227 estatus legal de los módulos de código cerrado. Pero la incertidumbre228 que acecha a esos módulos está ahí a pesar de todo.229 230- Los módulos binarios aumentan enormemente la dificultad de depurar231 problemas del kernel, hasta el punto de que la mayoría de los232 desarrolladores del kernel ni siquiera lo intentarán. Por lo tanto,233 la distribución de módulos únicamente en binario hará que sea más234 difícil para sus usuarios obtener soporte de la comunidad.235 236- El soporte también es más difícil para los distribuidores de módulos237 únicamente en binario, que deben proporcionar una versión del módulo238 para cada distribución y cada versión del kernel que deseen apoyar.239 Podría requerir docenas de compilaciones de un solo módulo para240 proporcionar una cobertura razonablemente completa, y sus usuarios241 tendrán que actualizar su módulo por separado cada vez que242 actualicen su kernel.243 244- Todo lo que se dijo anteriormente sobre la revisión de código se aplica245 doblemente al código cerrado. Dado que este código no está disponible246 en absoluto, no puede haber sido revisado por la comunidad y, sin duda,247 tendrá serios problemas.248 249Los fabricantes de sistemas embebidos, en particular, pueden verse250tentados a ignorar gran parte de lo que se ha dicho en esta sección251creyendo que están enviando un producto autónomo que utiliza una252versión de kernel congelada y no requiere más desarrollo después de su253lanzamiento. Este argumento desaprovecha el valor de la revisión254generalizad del código y el valor de permitir que sus usuarios agreguen255capacidades a su producto. Pero estos productos también tienen una vida256comercial limitada, después de la cual se debe lanzar una nueva versión.257En ese punto, los vendedores cuyo código esté en el mainline y bien258mantenido estarán en una posición mucho mejor para preparar el nuevo259producto rápidamente para el mercado.260 261Licencias262---------263 264El código se contribuye al kernel de Linux bajo varias licencias, pero265todo el código debe ser compatible con la versión 2 de la Licencia266Pública General de GNU (GPLv2), que cubre la distribución del kernel. En267la práctica, esto significa que todas las contribuciones de código están268cubiertas ya sea por la GPLv2 (con, opcionalmente, un lenguaje que permite269la distribución en versiones posteriores de la GPL) o por la licencia BSD270de tres cláusulas. Cualquier contribución que no esté cubierta por una271licencia compatible no será aceptada en el kernel.272 273No se requieren (ni se solicitan) cesiones de derechos de autor para el274código aportado al kernel. Todo el código fusionado en el kernel275mainline conserva su propiedad original; como resultado, el kernel ahora276tiene miles de propietarios.277 278Una implicación de esta estructura de propiedad es que cualquier intento279de cambiar la licencia del kernel está condenado a un fracaso casi seguro.280Hay pocos escenarios prácticos en los que se pueda obtener el acuerdo de281todos los titulares de derechos de autor (o eliminar su código del282kernel). Así que, en particular, no hay perspectivas de una migración a283la versión 3 de la GPL en un futuro previsible.284 285Es imperativo que todo el código aportado al kernel sea legítimamente286software libre. Por esa razón, no se aceptará código de colaboradores287anónimos (o seudónimos). Todos los colaboradores están obligados a288“firmar” su código, indicando que el código puede ser distribuido con289el kernel bajo la GPL. El código que no ha sido licenciado como software290libre por su propietario, o que corre el riesgo de crear problemas291relacionadas con los derechos de autor para el kernel (como el código que292se deriva de esfuerzos de ingeniería inversa que carecen de las garantías293adecuadas) no puede ser contribuido.294 295Las preguntas sobre cuestiones relacionadas con los derechos de autor son296comunes en las listas de correo de desarrollo de Linux. Normalmente, estas297preguntas no recibirán escasez de respuestas, pero se debe tener en cuenta298que las personas que responden a esas preguntas no son abogados y no299pueden proporcionar consejo legal. Si tiene preguntas legales relacionadas300con el código fuente de Linux, no hay sustituto para hablar con un abogado301que entienda este campo. Confiar en las respuestas obtenidas en listas302técnicas de correo es un asunto arriesgado.303