303 lines
16 KiB
ReStructuredText
303 lines
16 KiB
ReStructuredText
.. include:: ../disclaimer-sp.rst
|
|
|
|
:Original: Documentation/process/1.Intro.rst
|
|
:Translator: Avadhut Naik <avadhut.naik@amd.com>
|
|
|
|
.. _sp_development_process_intro:
|
|
|
|
Introducción
|
|
============
|
|
|
|
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.
|
|
|
|
:ref:`sp_development_process` 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.
|
|
|
|
:ref:`sp_development_early_stage` cubre la planificación de proyectos en
|
|
etapas tempranas, con énfasis en involucrar a la comunidad de desarrollo
|
|
lo antes posible.
|
|
|
|
:ref:`sp_development_coding` 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.
|
|
|
|
:ref:`sp_development_posting` 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.
|
|
|
|
:ref:`sp_development_followthrough` 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.
|
|
|
|
:ref:`sp_development_advancedtopics` introduce un par de temas “avanzados”:
|
|
la administración de parches con git y la revisión de parches publicados
|
|
por otros.
|
|
|
|
:ref:`sp_development_conclusion` concluye el documento con punteros a las
|
|
fuentes para obtener más información sobre el desarrollo del kernel.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|