.. include:: ../disclaimer-sp.rst

:Original: Documentation/process/3.Early-stage.rst
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com>

.. _sp_development_early_stage:

Planificación en etapa inicial
==============================

Cuando uno se sienta a planear un proyecto de desarrollo del kernel Linux,
puede ser tentador lanzarse directamente a escribir código. Sin embargo,
como ocurre con cualquier proyecto significativo, gran parte del trabajo
que conduce al éxito es mejor realizarlo antes de escribir la primera línea
de código. Dedicar tiempo a la planificación y comunicación temprana puede
ahorrar mucho más tiempo en adelante.

Especificar el problema
-----------------------

Como en cualquier proyecto de ingeniería, una mejora exitosa del kernel
comienza con una descripción clara del problema a resolver. En algunos
casos, este paso es sencillo: cuando se necesita un driver para un hardware
específico, por ejemplo. En otros, sin embargo, es tentador confundir el
problema real con la solución propuesta, lo que puede generar dificultades.

Consideremos un ejemplo: hace algunos años, los desarrolladores que
trabajaban con audio en Linux buscaban una forma de ejecutar aplicaciones
sin interrupciones u otros artefactos causados por la latencia excesiva en
el sistema. La solución a la que llegaron fue un módulo del kernel
destinado a integrarse en el marco del Módulo de Seguridad de Linux (LSM,
por sus siglas en inglés); este módulo podía configurarse para dar acceso a
aplicaciones específicas al planificador en tiempo real. Este módulo fue
implementado y enviado a la lista de correo del kernel de Linux, donde
inmediatamente encontró problemas.

Para los desarrolladores de audio, este módulo de seguridad era suficiente
para resolver su problema inmediato. Sin embargo, para la comunidad más
amplia del kernel, se veía como un uso indebido del marco LSM (que no está
diseñado para otorgar privilegios a procesos que de otro modo no los
tendrían) y como un riesgo para la estabilidad del sistema. Sus soluciones
preferidas implicaban el acceso a la programación en tiempo real a través
del mecanismo de rlimit a corto plazo, y trabajo continuo para reducir la
latencia a largo plazo.

La comunidad de audio, sin embargo, no podía ver más allá de la solución
particular que habían implementado; no estaban dispuestos a aceptar
alternativas. El desacuerdo resultante dejó a esos desarrolladores
desilusionados con todo el proceso de desarrollo del kernel; uno de ellos
volvió a una lista de audio y publicó esto (traducido):

	"Hay un buen número de desarrolladores muy competentes del kernel de Linux, pero tienden a ser opacados por una multitud de arrogantes necios. Intentar comunicar los requisitos de los usuarios a estas personas es una pérdida de tiempo. Son demasiado 'inteligentes' como para escuchar a simples mortales".

Siendo el texto original:

	There are a number of very good Linux kernel developers, but they
	tend to get outshouted by a large crowd of arrogant fools. Trying
	to communicate user requirements to these people is a waste of
	time. They are much too "intelligent" to listen to lesser mortals.

(https://lwn.net/Articles/131776/).

La realidad de la situación era diferente; los desarrolladores del kernel
estaban mucho más preocupados por la estabilidad del sistema, el
mantenimiento a largo plazo y encontrar la solución correcta al problema
que por un módulo específico. La moraleja de la historia es centrarse en el
problema, no en una solución específica, y discutirlo con la comunidad de
desarrollo antes de invertir en la creación de un cuerpo de código.

Por lo tanto, al contemplar un proyecto de desarrollo del kernel, se deben
obtener respuestas a un conjunto corto de preguntas:

- ¿Cuál es exactamente el problema que necesita ser resuelto?

- ¿Quiénes son los usuarios afectados por este problema? ¿Qué casos de uso
  debería abordar la solución?

- ¿En qué aspectos el kernel actual no logra abordar ese problema?

Solo entonces tiene sentido comenzar a considerar posibles soluciones.

Discusión temprana
------------------

Al planificar un proyecto de desarrollo del kernel, tiene mucho sentido
realizar discusiones con la comunidad antes de lanzarse a la
implementación. La comunicación temprana puede ahorrar tiempo y problemas
de varias maneras:

- Es posible que el problema ya esté siendo abordado por el kernel de
  maneras que no haya comprendido. El kernel de Linux es grande y tiene
  una serie de características y capacidades que no son inmediatamente
  obvias. No todas las capacidades del kernel están documentadas tan bien
  como uno quisiera, y es fácil pasar cosas por alto. El autor de este
  texto ha visto la publicación de un driver completo que duplicaba uno
  existente del que el nuevo autor no tenía conocimiento. El código que
  reinventa ruedas existentes no solo es desperdicio; tampoco será aceptado
  en el kernel principal.

- Puede haber elementos de la solución propuesta que no serán aceptables
  para su inclusión en el kernel principal. Es mejor descubrir problemas
  como este antes de escribir el código.

- Es completamente posible que otros desarrolladores ya hayan pensado en el
  problema; pueden tener ideas para una mejor solución y estar dispuestos a
  ayudar en la creación de esa solución.

Años de experiencia con la comunidad de desarrollo del kernel han enseñado
una lección clara: el código del kernel que se diseña y desarrolla a
puertas cerradas invariablemente tiene problemas que solo se revelan cuando
el código se libera a la comunidad. A veces, estos problemas son graves,
requiriendo meses o años de esfuerzo antes de que el código pueda cumplir
con los estándares de la comunidad del kernel. Algunos ejemplos incluyen:

- La pila de red Devicescape fue diseñada e implementada para sistemas de
  un solo procesador. No pudo fusionarse en la rama principal hasta que se
  hizo adecuada para sistemas multiprocesador. Adaptar el bloqueo y otros
  aspectos en el código es una tarea difícil; como resultado, la fusión de
  este código (ahora llamado mac80211) se retrasó más de un año.

- El sistema de archivos Reiser4 incluía una serie de capacidades que, en
  opinión de los desarrolladores principales del kernel, deberían haberse
  implementado en la capa de sistemas de archivos virtuales. También
  incluía funciones que no podían implementarse fácilmente sin exponer el
  sistema a bloqueos causados por los usuarios. La revelación tardía de
  estos problemas, y la negativa a abordar algunos de ellos, ha mantenido a
  Reiser4 fuera del kernel principal.

- El módulo de seguridad AppArmor hacía uso de estructuras de datos
  internas del sistema de archivos virtual de maneras que se consideraban
  inseguras y poco fiables. Esta preocupación (entre otras) mantuvo a
  AppArmor fuera de la rama principal durante años.

En cada uno de estos casos, se podría haber evitado mucho dolor y trabajo
adicional con algunas discusiones tempranas con los desarrolladores del
kernel.

¿Con quién hablar?
-------------------

Cuando los desarrolladores deciden hacer públicas sus ideas, la siguiente
pregunta será: ¿dónde empezar? La respuesta es encontrar la lista de correo
adecuada y el maintainer correcto. Para las listas de correo, la mejor
opción es buscar en el archivo MAINTAINERS un lugar relevante para
publicar. Si existe una lista de subsistema adecuada, es preferible
publicarla allí en lugar de en linux-kernel; es más probable que llegues a
desarrolladores con experiencia en el subsistema relevante y el ambiente
puede ser más propicio.

Encontrar a los maintainers puede ser un poco más difícil. Nuevamente, el
archivo MAINTAINERS es el lugar para empezar. Sin embargo, ese archivo
tiende a no estar siempre actualizado, y no todos los subsistemas están
representados allí. La persona listada en el archivo MAINTAINERS puede, de
hecho, no ser la persona que está actuando en ese rol actualmente. Por lo
tanto, cuando haya dudas sobre a quién contactar, un truco útil es usar git
(y "git log" en particular) para ver quién está activo actualmente en el
subsistema de interés. Mira quién está escribiendo parches y quién, si
alguien, está adjuntando líneas de Signed-off-by a esos parches. Esas son
las personas que estarán mejor posicionadas para ayudar con un nuevo
proyecto de desarrollo.

La tarea de encontrar al maintainer correcto es lo suficientemente
desafiante como para que los desarrolladores del kernel hayan añadido un
script para facilitar el proceso:

::

	.../scripts/get_maintainer.pl

Este script devolverá los maintainers actuales de un archivo o directorio
dado cuando se le pase la opción "-f". Si se le pasa un parche en la línea
de comandos, listará a los maintainers que probablemente deberían recibir
copias del parche. Esta es la manera preferida (a diferencia de la opción
"-f") de obtener la lista de personas a las que hay que enviar las copias
de sus parches. Hay varias opciones que regulan cuán agresivamente
get_maintainer.pl buscará maintainers; por favor, ten cuidado al usar las
opciones más agresivas, ya que podrías terminar incluyendo desarrolladores
que no tienen ningún interés real en el código que estás modificando.

Si todo lo demás falla, hablar con Andrew Morton puede ser una forma
efectiva de encontrar a un maintainer para un código específico.

¿Cuándo publicar?
------------------

Si es posible, publicar sus planes en las primeras etapas solo puede ser
útil. Describa el problema que se está resolviendo y cualquier plan que se
haya hecho sobre cómo se llevará a cabo la implementación. Cualquier
información que puedas proporcionar puede ayudar a la comunidad de
desarrollo a ofrecer comentarios útiles sobre el proyecto.

Una cosa desalentadora que puede suceder en esta etapa no es una reacción
hostil, sino, en cambio, poca o ninguna reacción en absoluto. La triste
realidad es que (1) los desarrolladores del kernel tienden a estar
ocupados, (2) no hay escasez de personas con grandes planes y poco código
(o incluso perspectivas de código) para respaldarlos, y (3) nadie está
obligado a revisar o comentar las ideas publicadas por otros. Además, los
diseños de alto nivel a menudo esconden problemas que solo se revelan
cuando alguien realmente intenta implementar esos diseños; por esa razón,
los desarrolladores del kernel prefieren ver el código.

Si una publicación de solicitud de comentarios genera pocos comentarios, no
asuma que significa que no hay interés en el proyecto. Desafortunadamente,
tampoco puedes asumir que no hay problemas con tu idea. Lo mejor que puede
hacer en esta situación es seguir adelante, manteniendo informada a
comunidad a medida que avanza.

Obtener respaldo oficial
------------------------

Si su trabajo se está realizando en un entorno corporativo — como ocurre
con la mayoría del trabajo en el kernel de Linux — es obvio que debe tener
permiso de los jefes debidamente autorizados antes de poder publicar los
planes o el código de su empresa en una lista de correo pública. La
publicación de código que no ha sido autorizado para su liberación bajo una
licencia compatible con la GPL puede ser especialmente problemática; cuanto
antes la gerencia y el personal legal de una empresa lleguen a un acuerdo
sobre la publicación de un proyecto de desarrollo del kernel, mejor será
para todos los involucrados.

Algunos lectores pueden estar pensando en este momento que su trabajo en el
kernel está destinado a respaldar un producto que aún no ha sido reconocido
oficialmente. Revelar los planes de su empleador en una lista de correo
pública puede no ser una opción viable. En casos como este, vale la pena
considerar si realmente es necesario mantener el secreto; a menudo no hay
una necesidad real de mantener los planes de desarrollo en secreto.

Dicho esto, también hay casos en los que una empresa legítimamente no puede
revelar sus planes al inicio del proceso de desarrollo. Las empresas con
desarrolladores experimentados en el kernel pueden optar por proceder de
manera abierta, bajo el supuesto de que podrán evitar problemas graves de
integración más adelante. Para las empresas sin ese tipo de experiencia
interna, la mejor opción suele ser contratar a un desarrollador externo
para que revise los planes bajo un acuerdo de confidencialidad (NDA). La
Linux Foundation opera un programa de NDA diseñado para ayudar en este tipo
de situaciones; se puede encontrar más información en:

    https://www.linuxfoundation.org/nda/

Este tipo de revisión suele ser suficiente para evitar problemas graves más
adelante sin necesidad de revelar públicamente el proyecto.