Spanish

Warning

Si tiene alguna duda sobre la exactitud del contenido de esta traducción, la única referencia válida es la documentación oficial en inglés. Además, por defecto, los enlaces a documentos redirigen a la documentación en inglés, incluso si existe una versión traducida. Consulte el índice para más información.

Original:

Documentation/process/1.Intro.rst

Translator:

Avadhut Naik <avadhut.naik@amd.com>

1. Introducción

1.1. Resumen ejecutivo

El resto de esta sección cubre el alcance del proceso de desarrollo del kernel y los tipos de frustraciones que los desarrolladores y sus empleadores pueden encontrar allí. Hay muchas razones por las que el código del kernel debe fusionarse con el kernel oficial (“mainline”), incluyendo la disponibilidad automática para los usuarios, el apoyo de la comunidad en muchas formas, y la capacidad de influir en la dirección del desarrollo del kernel. El código contribuido al kernel de Linux debe estar disponible bajo una licencia compatible con GPL.

Cómo funciona el proceso de desarrollo introduce el proceso de desarrollo, el ciclo de lanzamiento del kernel y la mecánica de la “ventana de combinación” (merge window). Se cubren las distintas fases en el desarrollo del parche, la revisión y, el ciclo de fusión. Hay algunas discusiones sobre herramientas y listas de correo. Se anima a los desarrolladores que deseen comenzar con el desarrollo del kernel a encontrar y corregir errores como ejercicio inicial.

Planificación en etapa inicial cubre la planificación de proyectos en etapas tempranas, con énfasis en involucrar a la comunidad de desarrollo lo antes posible.

Conseguir el código correcto trata sobre el proceso de codificación. Se discuten varios escollos encontrados por otros desarrolladores. Se cubren algunos requisitos para los parches, y hay una introducción a algunas de las herramientas que pueden ayudar a garantizar que los parches del kernel sean correctos.

Publicación de parches trata sobre el proceso de enviar parches para su revisión. Para ser tomados en serio por la comunidad de desarrollo, los parches deben estar correctamente formateados y descritos, y deben enviarse al lugar correcto. Seguir los consejos de esta sección debería ayudar a garantizar la mejor recepción posible para su trabajo.

Seguimiento cubre lo que sucede después de publicar parches; el trabajo está lejos de terminar en ese momento. Trabajar con revisores es una parte crucial del proceso de desarrollo; esta sección ofrece varios consejos sobre cómo evitar problemas en esta importante etapa. Se advierte a los desarrolladores que no asuman que el trabajo está terminado cuando un parche se fusiona en mainline.

Temas avanzados introduce un par de temas “avanzados”: la administración de parches con git y la revisión de parches publicados por otros.

Para más información concluye el documento con punteros a las fuentes para obtener más información sobre el desarrollo del kernel.

1.2. De qué trata este documento

El kernel de Linux, con más de 8 millones de líneas de código y más de 1000 colaboradores en cada versión, en uno de los proyectos de software libre más grandes y activos que existen. Desde sus humildes comienzos en 1991, este kernel ha evolucionado hasta convertirse en el mejor componente del sistema operativo que se ejecuta en reproductores de música digital de bolsillo, PC de escritorio, las supercomputadoras más grandes que existen y todo tipo de sistemas intermedios. Es una solución robusta, eficiente, y escalable para casi cualquier situación.

Con el crecimiento de Linux, ha llegado un aumento en el número de desarrolladores (y empresas) que desean participar en su desarrollo. Los vendedores de hardware quieren asegurarse de que Linux sea compatible con sus productos, lo que hace que esos productos sean atractivos para los usuarios de Linux. Los vendedores de sistemas embebidos, que utilizan Linux como componente de un producto integrado, quieren que Linux sea lo más capaz y adecuado posible para tarea en cuestión. Los distribuidores y otros vendedores de software que basan sus productos en Linux tienen un claro interés en las capacidades, el rendimiento, y la fiabilidad del kernel de Linux. Y los usuarios finales, también, a menudo desearán cambiar Linux para que se adapte mejor a sus necesidades.

Una de las características más convincentes de Linux es que es accesible a estos desarrolladores; cualquier persona con las habilidades necesarias puede mejorar Linux e influir en la dirección de su desarrollo. Los productos propietarios no pueden ofrecer este tipo de apertura, que es una característica del proceso de software libre. Pero, en todo caso, el kernel es aún más libre que la mayoría de los otros proyectos de software libre. Un ciclo típico de desarrollo de kernel de tres meses puede involucrar a más de 1000 desarrolladores que trabajan para más de 100 empresas diferentes (o sin pertenecer a ninguna empresa).

Trabajar con la comunidad de desarrollo del kernel no es especialmente difícil. Pero, a pesar de eso, muchos colaboradores potenciales han experimentado dificultades al tratar de hacer el trabajo del kernel. La comunidad del kernel ha desarrollado sus propias formas distintivas de operar, lo que le permite funcionar de manera fluida (y producir un producto de alta calidad) en un entorno donde miles de líneas de código se cambian todos los días. Por lo tanto, no es sorprendente que el proceso de desarrollo del kernel de Linux difiera mucho de los métodos de desarrollo propietarios.

El proceso de desarrollo del kernel puede parecer extraño e intimidante para los nuevos desarrolladores, pero hay buenas razones y una sólida experiencia detrás de él. Un desarrollador que no entienda las formas de la comunidad del kernel (o, peor aún, que intente burlarse o eludirlas) tendrá una experiencia frustrante por delante. La comunidad de desarrollo, si bien es servicial para aquellos que están tratando de aprender, tiene poco tiempo para aquellos que no escuchan o que no se preocupan por el proceso de desarrollo.

Se espera que quienes lean este documento puedan evitar esa experiencia frustrante. Hay mucho material aquí, pero el esfuerzo que implica leerlo será recompensado en poco tiempo. La comunidad de desarrollo siempre necesita desarrolladores que ayudan a mejorar el kernel; el siguiente texto debería ayudarle – o a quienes trabajan para usted, a unirse a nuestra comunidad.

1.3. Créditos

Este documento fue escrito por Jonathan Corbet, corbet@lwn.net. Ha sido mejorado por los comentarios de Johannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata y Jochen Voß. Este trabajo fue respaldado por la Fundación Linux; gracias especialmente a Amanda McPherson, quien reconoció el valor de este esfuerzo e hizo que todo sucediera.

1.4. Importancia de integrar el código en el mainline

Algunas empresas y desarrolladores ocasionalmente se preguntan por qué deberían molestarse en aprender cómo trabajar con la comunidad del kernel y obtener su código en el kernel mainline (el “mainline” es el kernel mantenido por Linus Torvalds y utilizado como base por los distribuidores de Linux. A corto plazo, contribuir con código puede parecer un gasto evitable; parece más fácil mantener el código separado y dar soporte a los usuarios directamente. La verdad del asunto es que mantener el código separado (“fuera del árbol”) es pan para hoy y hambre para mañana.

Para ilustrar los costos del código fuera-del-árbol, aquí hay algunos aspectos relevantes del proceso de desarrollo del kernel. La mayoría de estos se discutirán con mayor detalle más adelante en este documento. Considerar:

  • El código que se ha fusionado con el kernel mainline está disponible para todos los usuarios de Linux. Estará presente automáticamente en todas las distribuciones que lo habiliten. No hay necesidad de discos de controladores, descargas, o las molestias de admitir múltiples versiones de múltiples distribuciones; todo simplemente funciona, para el desarrollador y para el usuario. La incorporación al mainline resuelve un gran número de problemas de distribución y soporte.

  • Mientras los desarrolladores del kernel se esfuerzan por mantener una interfaz estable para el espacio de usuario, la API interna de kernel está en constante cambio. La falta de una interfaz interna estable es una decisión deliberada de diseño; permite realizar mejoras fundamentales en cualquier momento y da como resultado un código de mayor calidad. Pero uno resultado de esa política es que cualquier código fuera-del-árbol requiere un mantenimiento constante si va a funcionar con los nuevos kernels. Mantener el código fuera-del-árbol requiere una cantidad significativa de trabajo sólo para que ese código siga funcionando.

    En su lugar, el código en el mainline no requiere este trabajo como resultado de una regla simple que requiere que cualquier desarrollador que realice un cambio en la API también corrija cualquier código que se rompa como resultado de ese cambio. Así que, el código fusionado en el mainline tiene costos de mantenimiento significativamente más bajos.

  • Más allá de eso, el código que está en el kernel a menudo será mejorado por otros desarrolladores. Resultados sorprendentes pueden provenir de capacitar a su comunidad de usuarios y clientes para mejorar su producto.

  • El código del kernel se somete a revisión, tanto antes como después de fusionarse con el mainline. No importa cuán fuertes sean las habilidades del desarrollador original, este proceso de revisión invariablemente encuentra formas en las que se puede mejorar el código. A menudo la revisión encuentra errores graves y problemas de seguridad. Esto es especialmente cierto para el código que se ha desarrollado en un entorno cerrado; dicho código se beneficia fuertemente de la revisión por desarrolladores externos. El código fuera-del-árbol es de menor calidad.

  • La participación en el proceso de desarrollo es su manera de influir en la dirección del desarrollo del kernel. Los usuarios que se quejan desde el sofa son escuchados, pero los desarrolladores activos tienen una voz más fuerte – y la capacidad de implementar cambios que hacen que el kernel funcione mejor para sus necesidades.

  • Cuando el código se mantiene por separado, siempre existe la posibilidad de que un tercero contribuya a una implementación diferente de una característica similar. Si eso sucede, conseguir que su código fusionado será mucho más difícil – hasta el punto de la imposibilidad. Entonces se enfrentará a las desagradables alternativas de (1) mantener una característica no estándar fuera del árbol indefinidamente, o (2) abandonar su código y migrar sus usuarios a la versión en el árbol.

  • La contribución del código es la acción fundamental que hace que todo el proceso funcione. Al contribuir con su código, puede agregar nuevas funcionalidades al kernel y proporcionar capacidades y ejemplos que son útiles para otros desarrolladores del kernel. Si ha desarrollado código para Linux (o está pensando en hacerlo), claramente tiene un interés en el éxito continuo de esta plataforma; contribuir con código es una de las mejores maneras de ayudar a garantizar ese éxito.

Todo el razonamiento anterior se aplica a cualquier código de kernel fuera-del-árbol, incluido el código que se distribuye en forma propietaria y únicamente en binario. Sin embargo, hay factores adicionales que deben tenerse en cuenta antes de considerar cualquier tipo de distribución de código de kernel únicamente en binario. Estos incluyen:

  • Las cuestiones legales en torno a la distribución de módulos propietarios del kernel son, en el mejor de los casos, confusas; bastantes titulares de derechos de autor del kernel creen que la mayoría de los módulos binarios son productos derivados del kernel y que, como resultado, su distribución es una violación de la licencia Pública General de GNU (sobre la que se dirá más adelante). El autor de este texto no es abogado, y nada en este documento puede considerarse asesoramiento legal. Solo los tribunales pueden determinar el verdadero estatus legal de los módulos de código cerrado. Pero la incertidumbre que acecha a esos módulos está ahí a pesar de todo.

  • Los módulos binarios aumentan enormemente la dificultad de depurar problemas del kernel, hasta el punto de que la mayoría de los desarrolladores del kernel ni siquiera lo intentarán. Por lo tanto, la distribución de módulos únicamente en binario hará que sea más difícil para sus usuarios obtener soporte de la comunidad.

  • El soporte también es más difícil para los distribuidores de módulos únicamente en binario, que deben proporcionar una versión del módulo para cada distribución y cada versión del kernel que deseen apoyar. Podría requerir docenas de compilaciones de un solo módulo para proporcionar una cobertura razonablemente completa, y sus usuarios tendrán que actualizar su módulo por separado cada vez que actualicen su kernel.

  • Todo lo que se dijo anteriormente sobre la revisión de código se aplica doblemente al código cerrado. Dado que este código no está disponible en absoluto, no puede haber sido revisado por la comunidad y, sin duda, tendrá serios problemas.

Los fabricantes de sistemas embebidos, en particular, pueden verse tentados a ignorar gran parte de lo que se ha dicho en esta sección creyendo que están enviando un producto autónomo que utiliza una versión de kernel congelada y no requiere más desarrollo después de su lanzamiento. Este argumento desaprovecha el valor de la revisión generalizad del código y el valor de permitir que sus usuarios agreguen capacidades a su producto. Pero estos productos también tienen una vida comercial limitada, después de la cual se debe lanzar una nueva versión. En ese punto, los vendedores cuyo código esté en el mainline y bien mantenido estarán en una posición mucho mejor para preparar el nuevo producto rápidamente para el mercado.

1.5. Licencias

El código se contribuye al kernel de Linux bajo varias licencias, pero todo el código debe ser compatible con la versión 2 de la Licencia Pública General de GNU (GPLv2), que cubre la distribución del kernel. En la práctica, esto significa que todas las contribuciones de código están cubiertas ya sea por la GPLv2 (con, opcionalmente, un lenguaje que permite la distribución en versiones posteriores de la GPL) o por la licencia BSD de tres cláusulas. Cualquier contribución que no esté cubierta por una licencia compatible no será aceptada en el kernel.

No se requieren (ni se solicitan) cesiones de derechos de autor para el código aportado al kernel. Todo el código fusionado en el kernel mainline conserva su propiedad original; como resultado, el kernel ahora tiene miles de propietarios.

Una implicación de esta estructura de propiedad es que cualquier intento de cambiar la licencia del kernel está condenado a un fracaso casi seguro. Hay pocos escenarios prácticos en los que se pueda obtener el acuerdo de todos los titulares de derechos de autor (o eliminar su código del kernel). Así que, en particular, no hay perspectivas de una migración a la versión 3 de la GPL en un futuro previsible.

Es imperativo que todo el código aportado al kernel sea legítimamente software libre. Por esa razón, no se aceptará código de colaboradores anónimos (o seudónimos). Todos los colaboradores están obligados a “firmar” su código, indicando que el código puede ser distribuido con el kernel bajo la GPL. El código que no ha sido licenciado como software libre por su propietario, o que corre el riesgo de crear problemas relacionadas con los derechos de autor para el kernel (como el código que se deriva de esfuerzos de ingeniería inversa que carecen de las garantías adecuadas) no puede ser contribuido.

Las preguntas sobre cuestiones relacionadas con los derechos de autor son comunes en las listas de correo de desarrollo de Linux. Normalmente, estas preguntas no recibirán escasez de respuestas, pero se debe tener en cuenta que las personas que responden a esas preguntas no son abogados y no pueden proporcionar consejo legal. Si tiene preguntas legales relacionadas con el código fuente de Linux, no hay sustituto para hablar con un abogado que entienda este campo. Confiar en las respuestas obtenidas en listas técnicas de correo es un asunto arriesgado.