sp_SP/process/1.Intro.rst

.. 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.