1.. include:: ../disclaimer-sp.rst 2 3:Original: Documentation/process/3.Early-stage.rst 4:Translator: Carlos Bilbao <[email protected]> and Avadhut Naik <[email protected]> 5 6.. _sp_development_early_stage: 7 8Planificación en etapa inicial 9============================== 10 11Cuando uno se sienta a planear un proyecto de desarrollo del kernel Linux, 12puede ser tentador lanzarse directamente a escribir código. Sin embargo, 13como ocurre con cualquier proyecto significativo, gran parte del trabajo 14que conduce al éxito es mejor realizarlo antes de escribir la primera línea 15de código. Dedicar tiempo a la planificación y comunicación temprana puede 16ahorrar mucho más tiempo en adelante. 17 18Especificar el problema 19----------------------- 20 21Como en cualquier proyecto de ingeniería, una mejora exitosa del kernel 22comienza con una descripción clara del problema a resolver. En algunos 23casos, este paso es sencillo: cuando se necesita un driver para un hardware 24específico, por ejemplo. En otros, sin embargo, es tentador confundir el 25problema real con la solución propuesta, lo que puede generar dificultades. 26 27Consideremos un ejemplo: hace algunos años, los desarrolladores que 28trabajaban con audio en Linux buscaban una forma de ejecutar aplicaciones 29sin interrupciones u otros artefactos causados por la latencia excesiva en 30el sistema. La solución a la que llegaron fue un módulo del kernel 31destinado a integrarse en el marco del Módulo de Seguridad de Linux (LSM, 32por sus siglas en inglés); este módulo podía configurarse para dar acceso a 33aplicaciones específicas al planificador en tiempo real. Este módulo fue 34implementado y enviado a la lista de correo del kernel de Linux, donde 35inmediatamente encontró problemas. 36 37Para los desarrolladores de audio, este módulo de seguridad era suficiente 38para resolver su problema inmediato. Sin embargo, para la comunidad más 39amplia del kernel, se veía como un uso indebido del marco LSM (que no está 40diseñado para otorgar privilegios a procesos que de otro modo no los 41tendrían) y como un riesgo para la estabilidad del sistema. Sus soluciones 42preferidas implicaban el acceso a la programación en tiempo real a través 43del mecanismo de rlimit a corto plazo, y trabajo continuo para reducir la 44latencia a largo plazo. 45 46La comunidad de audio, sin embargo, no podía ver más allá de la solución 47particular que habían implementado; no estaban dispuestos a aceptar 48alternativas. El desacuerdo resultante dejó a esos desarrolladores 49desilusionados con todo el proceso de desarrollo del kernel; uno de ellos 50volvió a una lista de audio y publicó esto (traducido): 51 52 "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". 53 54Siendo el texto original: 55 56 There are a number of very good Linux kernel developers, but they 57 tend to get outshouted by a large crowd of arrogant fools. Trying 58 to communicate user requirements to these people is a waste of 59 time. They are much too "intelligent" to listen to lesser mortals. 60 61(https://lwn.net/Articles/131776/). 62 63La realidad de la situación era diferente; los desarrolladores del kernel 64estaban mucho más preocupados por la estabilidad del sistema, el 65mantenimiento a largo plazo y encontrar la solución correcta al problema 66que por un módulo específico. La moraleja de la historia es centrarse en el 67problema, no en una solución específica, y discutirlo con la comunidad de 68desarrollo antes de invertir en la creación de un cuerpo de código. 69 70Por lo tanto, al contemplar un proyecto de desarrollo del kernel, se deben 71obtener respuestas a un conjunto corto de preguntas: 72 73- ¿Cuál es exactamente el problema que necesita ser resuelto? 74 75- ¿Quiénes son los usuarios afectados por este problema? ¿Qué casos de uso 76 debería abordar la solución? 77 78- ¿En qué aspectos el kernel actual no logra abordar ese problema? 79 80Solo entonces tiene sentido comenzar a considerar posibles soluciones. 81 82Discusión temprana 83------------------ 84 85Al planificar un proyecto de desarrollo del kernel, tiene mucho sentido 86realizar discusiones con la comunidad antes de lanzarse a la 87implementación. La comunicación temprana puede ahorrar tiempo y problemas 88de varias maneras: 89 90- Es posible que el problema ya esté siendo abordado por el kernel de 91 maneras que no haya comprendido. El kernel de Linux es grande y tiene 92 una serie de características y capacidades que no son inmediatamente 93 obvias. No todas las capacidades del kernel están documentadas tan bien 94 como uno quisiera, y es fácil pasar cosas por alto. El autor de este 95 texto ha visto la publicación de un driver completo que duplicaba uno 96 existente del que el nuevo autor no tenía conocimiento. El código que 97 reinventa ruedas existentes no solo es desperdicio; tampoco será aceptado 98 en el kernel principal. 99 100- Puede haber elementos de la solución propuesta que no serán aceptables 101 para su inclusión en el kernel principal. Es mejor descubrir problemas 102 como este antes de escribir el código. 103 104- Es completamente posible que otros desarrolladores ya hayan pensado en el 105 problema; pueden tener ideas para una mejor solución y estar dispuestos a 106 ayudar en la creación de esa solución. 107 108Años de experiencia con la comunidad de desarrollo del kernel han enseñado 109una lección clara: el código del kernel que se diseña y desarrolla a 110puertas cerradas invariablemente tiene problemas que solo se revelan cuando 111el código se libera a la comunidad. A veces, estos problemas son graves, 112requiriendo meses o años de esfuerzo antes de que el código pueda cumplir 113con los estándares de la comunidad del kernel. Algunos ejemplos incluyen: 114 115- La pila de red Devicescape fue diseñada e implementada para sistemas de 116 un solo procesador. No pudo fusionarse en la rama principal hasta que se 117 hizo adecuada para sistemas multiprocesador. Adaptar el bloqueo y otros 118 aspectos en el código es una tarea difícil; como resultado, la fusión de 119 este código (ahora llamado mac80211) se retrasó más de un año. 120 121- El sistema de archivos Reiser4 incluía una serie de capacidades que, en 122 opinión de los desarrolladores principales del kernel, deberían haberse 123 implementado en la capa de sistemas de archivos virtuales. También 124 incluía funciones que no podían implementarse fácilmente sin exponer el 125 sistema a bloqueos causados por los usuarios. La revelación tardía de 126 estos problemas, y la negativa a abordar algunos de ellos, ha mantenido a 127 Reiser4 fuera del kernel principal. 128 129- El módulo de seguridad AppArmor hacía uso de estructuras de datos 130 internas del sistema de archivos virtual de maneras que se consideraban 131 inseguras y poco fiables. Esta preocupación (entre otras) mantuvo a 132 AppArmor fuera de la rama principal durante años. 133 134En cada uno de estos casos, se podría haber evitado mucho dolor y trabajo 135adicional con algunas discusiones tempranas con los desarrolladores del 136kernel. 137 138¿Con quién hablar? 139------------------- 140 141Cuando los desarrolladores deciden hacer públicas sus ideas, la siguiente 142pregunta será: ¿dónde empezar? La respuesta es encontrar la lista de correo 143adecuada y el maintainer correcto. Para las listas de correo, la mejor 144opción es buscar en el archivo MAINTAINERS un lugar relevante para 145publicar. Si existe una lista de subsistema adecuada, es preferible 146publicarla allí en lugar de en linux-kernel; es más probable que llegues a 147desarrolladores con experiencia en el subsistema relevante y el ambiente 148puede ser más propicio. 149 150Encontrar a los maintainers puede ser un poco más difícil. Nuevamente, el 151archivo MAINTAINERS es el lugar para empezar. Sin embargo, ese archivo 152tiende a no estar siempre actualizado, y no todos los subsistemas están 153representados allí. La persona listada en el archivo MAINTAINERS puede, de 154hecho, no ser la persona que está actuando en ese rol actualmente. Por lo 155tanto, cuando haya dudas sobre a quién contactar, un truco útil es usar git 156(y "git log" en particular) para ver quién está activo actualmente en el 157subsistema de interés. Mira quién está escribiendo parches y quién, si 158alguien, está adjuntando líneas de Signed-off-by a esos parches. Esas son 159las personas que estarán mejor posicionadas para ayudar con un nuevo 160proyecto de desarrollo. 161 162La tarea de encontrar al maintainer correcto es lo suficientemente 163desafiante como para que los desarrolladores del kernel hayan añadido un 164script para facilitar el proceso: 165 166:: 167 168 .../scripts/get_maintainer.pl 169 170Este script devolverá los maintainers actuales de un archivo o directorio 171dado cuando se le pase la opción "-f". Si se le pasa un parche en la línea 172de comandos, listará a los maintainers que probablemente deberían recibir 173copias del parche. Esta es la manera preferida (a diferencia de la opción 174"-f") de obtener la lista de personas a las que hay que enviar las copias 175de sus parches. Hay varias opciones que regulan cuán agresivamente 176get_maintainer.pl buscará maintainers; por favor, ten cuidado al usar las 177opciones más agresivas, ya que podrías terminar incluyendo desarrolladores 178que no tienen ningún interés real en el código que estás modificando. 179 180Si todo lo demás falla, hablar con Andrew Morton puede ser una forma 181efectiva de encontrar a un maintainer para un código específico. 182 183¿Cuándo publicar? 184------------------ 185 186Si es posible, publicar sus planes en las primeras etapas solo puede ser 187útil. Describa el problema que se está resolviendo y cualquier plan que se 188haya hecho sobre cómo se llevará a cabo la implementación. Cualquier 189información que puedas proporcionar puede ayudar a la comunidad de 190desarrollo a ofrecer comentarios útiles sobre el proyecto. 191 192Una cosa desalentadora que puede suceder en esta etapa no es una reacción 193hostil, sino, en cambio, poca o ninguna reacción en absoluto. La triste 194realidad es que (1) los desarrolladores del kernel tienden a estar 195ocupados, (2) no hay escasez de personas con grandes planes y poco código 196(o incluso perspectivas de código) para respaldarlos, y (3) nadie está 197obligado a revisar o comentar las ideas publicadas por otros. Además, los 198diseños de alto nivel a menudo esconden problemas que solo se revelan 199cuando alguien realmente intenta implementar esos diseños; por esa razón, 200los desarrolladores del kernel prefieren ver el código. 201 202Si una publicación de solicitud de comentarios genera pocos comentarios, no 203asuma que significa que no hay interés en el proyecto. Desafortunadamente, 204tampoco puedes asumir que no hay problemas con tu idea. Lo mejor que puede 205hacer en esta situación es seguir adelante, manteniendo informada a 206comunidad a medida que avanza. 207 208Obtener respaldo oficial 209------------------------ 210 211Si su trabajo se está realizando en un entorno corporativo — como ocurre 212con la mayoría del trabajo en el kernel de Linux — es obvio que debe tener 213permiso de los jefes debidamente autorizados antes de poder publicar los 214planes o el código de su empresa en una lista de correo pública. La 215publicación de código que no ha sido autorizado para su liberación bajo una 216licencia compatible con la GPL puede ser especialmente problemática; cuanto 217antes la gerencia y el personal legal de una empresa lleguen a un acuerdo 218sobre la publicación de un proyecto de desarrollo del kernel, mejor será 219para todos los involucrados. 220 221Algunos lectores pueden estar pensando en este momento que su trabajo en el 222kernel está destinado a respaldar un producto que aún no ha sido reconocido 223oficialmente. Revelar los planes de su empleador en una lista de correo 224pública puede no ser una opción viable. En casos como este, vale la pena 225considerar si realmente es necesario mantener el secreto; a menudo no hay 226una necesidad real de mantener los planes de desarrollo en secreto. 227 228Dicho esto, también hay casos en los que una empresa legítimamente no puede 229revelar sus planes al inicio del proceso de desarrollo. Las empresas con 230desarrolladores experimentados en el kernel pueden optar por proceder de 231manera abierta, bajo el supuesto de que podrán evitar problemas graves de 232integración más adelante. Para las empresas sin ese tipo de experiencia 233interna, la mejor opción suele ser contratar a un desarrollador externo 234para que revise los planes bajo un acuerdo de confidencialidad (NDA). La 235Linux Foundation opera un programa de NDA diseñado para ayudar en este tipo 236de situaciones; se puede encontrar más información en: 237 238 https://www.linuxfoundation.org/nda/ 239 240Este tipo de revisión suele ser suficiente para evitar problemas graves más 241adelante sin necesidad de revelar públicamente el proyecto. 242