1 .. include:: ../disclaimer-sp.rst 2 3 :Original: Documentation/process/1.Intro.rst 4 :Translator: Avadhut Naik <avadhut.naik@amd.com> 5 6 .. _sp_development_process_intro: 7 8 Introducción 9 ============ 10 11 Resumen ejecutivo 12 ----------------- 13 14 El resto de esta sección cubre el alcance del proceso de desarrollo del 15 kernel y los tipos de frustraciones que los desarrolladores y sus 16 empleadores pueden encontrar allí. Hay muchas razones por las que el 17 código del kernel debe fusionarse con el kernel oficial (“mainline”), 18 incluyendo la disponibilidad automática para los usuarios, el apoyo de la 19 comunidad en muchas formas, y la capacidad de influir en la dirección del 20 desarrollo del kernel. El código contribuido al kernel de Linux debe 21 estar disponible bajo una licencia compatible con GPL. 22 23 :ref:`sp_development_process` introduce el proceso de desarrollo, el ciclo 24 de lanzamiento del kernel y la mecánica de la "ventana de combinación" 25 (merge window). Se cubren las distintas fases en el desarrollo del parche, 26 la revisión y, el ciclo de fusión. Hay algunas discusiones sobre 27 herramientas y listas de correo. Se anima a los desarrolladores que deseen 28 comenzar con el desarrollo del kernel a encontrar y corregir errores como 29 ejercicio inicial. 30 31 :ref:`sp_development_early_stage` cubre la planificación de proyectos en 32 etapas tempranas, con énfasis en involucrar a la comunidad de desarrollo 33 lo antes posible. 34 35 :ref:`sp_development_coding` trata sobre el proceso de codificación. Se 36 discuten varios escollos encontrados por otros desarrolladores. Se cubren 37 algunos requisitos para los parches, y hay una introducción a algunas de 38 las herramientas que pueden ayudar a garantizar que los parches del kernel 39 sean correctos. 40 41 :ref:`sp_development_posting` trata sobre el proceso de enviar parches para 42 su revisión. Para ser tomados en serio por la comunidad de desarrollo, 43 los parches deben estar correctamente formateados y descritos, y deben 44 enviarse al lugar correcto. Seguir los consejos de esta sección debería 45 ayudar a garantizar la mejor recepción posible para su trabajo. 46 47 :ref:`sp_development_followthrough` cubre lo que sucede después de publicar 48 parches; el trabajo está lejos de terminar en ese momento. Trabajar con 49 revisores es una parte crucial del proceso de desarrollo; esta sección 50 ofrece varios consejos sobre cómo evitar problemas en esta importante 51 etapa. Se advierte a los desarrolladores que no asuman que el trabajo está 52 terminado cuando un parche se fusiona en mainline. 53 54 :ref:`sp_development_advancedtopics` introduce un par de temas “avanzados”: 55 la administración de parches con git y la revisión de parches publicados 56 por otros. 57 58 :ref:`sp_development_conclusion` concluye el documento con punteros a las 59 fuentes para obtener más información sobre el desarrollo del kernel. 60 61 De qué trata este documento 62 --------------------------- 63 64 El kernel de Linux, con más de 8 millones de líneas de código y más de 65 1000 colaboradores en cada versión, en uno de los proyectos de software 66 libre más grandes y activos que existen. Desde sus humildes comienzos en 67 1991, este kernel ha evolucionado hasta convertirse en el mejor componente 68 del sistema operativo que se ejecuta en reproductores de música digital 69 de bolsillo, PC de escritorio, las supercomputadoras más grandes que 70 existen y todo tipo de sistemas intermedios. Es una solución robusta, 71 eficiente, y escalable para casi cualquier situación. 72 73 Con el crecimiento de Linux, ha llegado un aumento en el número de 74 desarrolladores (y empresas) que desean participar en su desarrollo. Los 75 vendedores de hardware quieren asegurarse de que Linux sea compatible con 76 sus productos, lo que hace que esos productos sean atractivos para los 77 usuarios de Linux. Los vendedores de sistemas embebidos, que utilizan 78 Linux como componente de un producto integrado, quieren que Linux sea lo 79 más capaz y adecuado posible para tarea en cuestión. Los distribuidores 80 y otros vendedores de software que basan sus productos en Linux tienen un 81 claro interés en las capacidades, el rendimiento, y la fiabilidad del 82 kernel de Linux. Y los usuarios finales, también, a menudo desearán 83 cambiar Linux para que se adapte mejor a sus necesidades. 84 85 Una de las características más convincentes de Linux es que es accesible 86 a estos desarrolladores; cualquier persona con las habilidades necesarias 87 puede mejorar Linux e influir en la dirección de su desarrollo. Los 88 productos propietarios no pueden ofrecer este tipo de apertura, que es una 89 característica del proceso de software libre. Pero, en todo caso, el 90 kernel es aún más libre que la mayoría de los otros proyectos de software 91 libre. Un ciclo típico de desarrollo de kernel de tres meses puede 92 involucrar a más de 1000 desarrolladores que trabajan para más de 100 93 empresas diferentes (o sin pertenecer a ninguna empresa). 94 95 Trabajar con la comunidad de desarrollo del kernel no es especialmente 96 difícil. Pero, a pesar de eso, muchos colaboradores potenciales han 97 experimentado dificultades al tratar de hacer el trabajo del kernel. La 98 comunidad del kernel ha desarrollado sus propias formas distintivas de 99 operar, lo que le permite funcionar de manera fluida (y producir un 100 producto de alta calidad) en un entorno donde miles de líneas de código 101 se cambian todos los días. Por lo tanto, no es sorprendente que el 102 proceso de desarrollo del kernel de Linux difiera mucho de los métodos de 103 desarrollo propietarios. 104 105 El proceso de desarrollo del kernel puede parecer extraño e intimidante 106 para los nuevos desarrolladores, pero hay buenas razones y una sólida 107 experiencia detrás de él. Un desarrollador que no entienda las formas de 108 la comunidad del kernel (o, peor aún, que intente burlarse o eludirlas) 109 tendrá una experiencia frustrante por delante. La comunidad de 110 desarrollo, si bien es servicial para aquellos que están tratando de 111 aprender, tiene poco tiempo para aquellos que no escuchan o que no se 112 preocupan por el proceso de desarrollo. 113 114 Se espera que quienes lean este documento puedan evitar esa experiencia 115 frustrante. Hay mucho material aquí, pero el esfuerzo que implica leerlo 116 será recompensado en poco tiempo. La comunidad de desarrollo siempre 117 necesita desarrolladores que ayudan a mejorar el kernel; el siguiente 118 texto debería ayudarle – o a quienes trabajan para usted, a unirse a 119 nuestra comunidad. 120 121 Créditos 122 -------- 123 124 Este documento fue escrito por Jonathan Corbet, corbet@lwn.net. Ha sido 125 mejorado por los comentarios de Johannes Berg, James Berry, Alex Chiang, 126 Roland Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur 127 Marsh, Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata y 128 Jochen Voß. 129 Este trabajo fue respaldado por la Fundación Linux; gracias especialmente 130 a Amanda McPherson, quien reconoció el valor de este esfuerzo e hizo que 131 todo sucediera. 132 133 Importancia de integrar el código en el mainline 134 ------------------------------------------------ 135 136 Algunas empresas y desarrolladores ocasionalmente se preguntan por qué 137 deberían molestarse en aprender cómo trabajar con la comunidad del 138 kernel y obtener su código en el kernel mainline (el “mainline” es el 139 kernel mantenido por Linus Torvalds y utilizado como base por los 140 distribuidores de Linux. A corto plazo, contribuir con código puede 141 parecer un gasto evitable; parece más fácil mantener el código separado 142 y dar soporte a los usuarios directamente. La verdad del asunto es que 143 mantener el código separado (“fuera del árbol”) es pan para hoy y hambre 144 para mañana. 145 146 Para ilustrar los costos del código fuera-del-árbol, aquí hay algunos 147 aspectos relevantes del proceso de desarrollo del kernel. La mayoría de 148 estos se discutirán con mayor detalle más adelante en este documento. 149 Considerar: 150 151 - El código que se ha fusionado con el kernel mainline está disponible 152 para todos los usuarios de Linux. Estará presente automáticamente en 153 todas las distribuciones que lo habiliten. No hay necesidad de discos 154 de controladores, descargas, o las molestias de admitir múltiples 155 versiones de múltiples distribuciones; todo simplemente funciona, para 156 el desarrollador y para el usuario. La incorporación al mainline 157 resuelve un gran número de problemas de distribución y soporte. 158 159 - Mientras los desarrolladores del kernel se esfuerzan por mantener una 160 interfaz estable para el espacio de usuario, la API interna de kernel 161 está en constante cambio. La falta de una interfaz interna estable es 162 una decisión deliberada de diseño; permite realizar mejoras 163 fundamentales en cualquier momento y da como resultado un código de 164 mayor calidad. Pero uno resultado de esa política es que cualquier 165 código fuera-del-árbol requiere un mantenimiento constante si va a 166 funcionar con los nuevos kernels. Mantener el código fuera-del-árbol 167 requiere una cantidad significativa de trabajo sólo para que ese código 168 siga funcionando. 169 170 En su lugar, el código en el mainline no requiere este trabajo como 171 resultado de una regla simple que requiere que cualquier desarrollador 172 que realice un cambio en la API también corrija cualquier código que 173 se rompa como resultado de ese cambio. Así que, el código fusionado en 174 el mainline tiene costos de mantenimiento significativamente más bajos. 175 176 - Más allá de eso, el código que está en el kernel a menudo será 177 mejorado por otros desarrolladores. Resultados sorprendentes pueden 178 provenir de capacitar a su comunidad de usuarios y clientes para mejorar 179 su producto. 180 181 - El código del kernel se somete a revisión, tanto antes como después 182 de fusionarse con el mainline. No importa cuán fuertes sean las 183 habilidades del desarrollador original, este proceso de revisión 184 invariablemente encuentra formas en las que se puede mejorar el código. 185 A menudo la revisión encuentra errores graves y problemas de seguridad. 186 Esto es especialmente cierto para el código que se ha desarrollado en 187 un entorno cerrado; dicho código se beneficia fuertemente de la 188 revisión por desarrolladores externos. El código fuera-del-árbol es 189 de menor calidad. 190 191 - La participación en el proceso de desarrollo es su manera de influir en 192 la dirección del desarrollo del kernel. Los usuarios que se quejan 193 desde el sofa son escuchados, pero los desarrolladores activos tienen 194 una voz más fuerte – y la capacidad de implementar cambios que hacen 195 que el kernel funcione mejor para sus necesidades. 196 197 - Cuando el código se mantiene por separado, siempre existe la posibilidad 198 de que un tercero contribuya a una implementación diferente de una 199 característica similar. Si eso sucede, conseguir que su código 200 fusionado será mucho más difícil – hasta el punto de la imposibilidad. 201 Entonces se enfrentará a las desagradables alternativas de (1) mantener 202 una característica no estándar fuera del árbol indefinidamente, o 203 (2) abandonar su código y migrar sus usuarios a la versión en el árbol. 204 205 - La contribución del código es la acción fundamental que hace que todo 206 el proceso funcione. Al contribuir con su código, puede agregar nuevas 207 funcionalidades al kernel y proporcionar capacidades y ejemplos que son 208 útiles para otros desarrolladores del kernel. Si ha desarrollado código 209 para Linux (o está pensando en hacerlo), claramente tiene un interés 210 en el éxito continuo de esta plataforma; contribuir con código es una 211 de las mejores maneras de ayudar a garantizar ese éxito. 212 213 Todo el razonamiento anterior se aplica a cualquier código de kernel 214 fuera-del-árbol, incluido el código que se distribuye en forma propietaria 215 y únicamente en binario. Sin embargo, hay factores adicionales que deben 216 tenerse en cuenta antes de considerar cualquier tipo de distribución de 217 código de kernel únicamente en binario. Estos incluyen: 218 219 - Las cuestiones legales en torno a la distribución de módulos 220 propietarios del kernel son, en el mejor de los casos, confusas; 221 bastantes titulares de derechos de autor del kernel creen que la 222 mayoría de los módulos binarios son productos derivados del kernel y 223 que, como resultado, su distribución es una violación de la licencia 224 Pública General de GNU (sobre la que se dirá más adelante). El autor 225 de este texto no es abogado, y nada en este documento puede considerarse 226 asesoramiento legal. Solo los tribunales pueden determinar el verdadero 227 estatus legal de los módulos de código cerrado. Pero la incertidumbre 228 que acecha a esos módulos está ahí a pesar de todo. 229 230 - Los módulos binarios aumentan enormemente la dificultad de depurar 231 problemas del kernel, hasta el punto de que la mayoría de los 232 desarrolladores del kernel ni siquiera lo intentarán. Por lo tanto, 233 la distribución de módulos únicamente en binario hará que sea más 234 difícil para sus usuarios obtener soporte de la comunidad. 235 236 - El soporte también es más difícil para los distribuidores de módulos 237 únicamente en binario, que deben proporcionar una versión del módulo 238 para cada distribución y cada versión del kernel que deseen apoyar. 239 Podría requerir docenas de compilaciones de un solo módulo para 240 proporcionar una cobertura razonablemente completa, y sus usuarios 241 tendrán que actualizar su módulo por separado cada vez que 242 actualicen su kernel. 243 244 - Todo lo que se dijo anteriormente sobre la revisión de código se aplica 245 doblemente al código cerrado. Dado que este código no está disponible 246 en absoluto, no puede haber sido revisado por la comunidad y, sin duda, 247 tendrá serios problemas. 248 249 Los fabricantes de sistemas embebidos, en particular, pueden verse 250 tentados a ignorar gran parte de lo que se ha dicho en esta sección 251 creyendo que están enviando un producto autónomo que utiliza una 252 versión de kernel congelada y no requiere más desarrollo después de su 253 lanzamiento. Este argumento desaprovecha el valor de la revisión 254 generalizad del código y el valor de permitir que sus usuarios agreguen 255 capacidades a su producto. Pero estos productos también tienen una vida 256 comercial limitada, después de la cual se debe lanzar una nueva versión. 257 En ese punto, los vendedores cuyo código esté en el mainline y bien 258 mantenido estarán en una posición mucho mejor para preparar el nuevo 259 producto rápidamente para el mercado. 260 261 Licencias 262 --------- 263 264 El código se contribuye al kernel de Linux bajo varias licencias, pero 265 todo el código debe ser compatible con la versión 2 de la Licencia 266 Pública General de GNU (GPLv2), que cubre la distribución del kernel. En 267 la práctica, esto significa que todas las contribuciones de código están 268 cubiertas ya sea por la GPLv2 (con, opcionalmente, un lenguaje que permite 269 la distribución en versiones posteriores de la GPL) o por la licencia BSD 270 de tres cláusulas. Cualquier contribución que no esté cubierta por una 271 licencia compatible no será aceptada en el kernel. 272 273 No se requieren (ni se solicitan) cesiones de derechos de autor para el 274 código aportado al kernel. Todo el código fusionado en el kernel 275 mainline conserva su propiedad original; como resultado, el kernel ahora 276 tiene miles de propietarios. 277 278 Una implicación de esta estructura de propiedad es que cualquier intento 279 de cambiar la licencia del kernel está condenado a un fracaso casi seguro. 280 Hay pocos escenarios prácticos en los que se pueda obtener el acuerdo de 281 todos los titulares de derechos de autor (o eliminar su código del 282 kernel). Así que, en particular, no hay perspectivas de una migración a 283 la versión 3 de la GPL en un futuro previsible. 284 285 Es imperativo que todo el código aportado al kernel sea legítimamente 286 software libre. Por esa razón, no se aceptará código de colaboradores 287 anónimos (o seudónimos). Todos los colaboradores están obligados a 288 “firmar” su código, indicando que el código puede ser distribuido con 289 el kernel bajo la GPL. El código que no ha sido licenciado como software 290 libre por su propietario, o que corre el riesgo de crear problemas 291 relacionadas con los derechos de autor para el kernel (como el código que 292 se deriva de esfuerzos de ingeniería inversa que carecen de las garantías 293 adecuadas) no puede ser contribuido. 294 295 Las preguntas sobre cuestiones relacionadas con los derechos de autor son 296 comunes en las listas de correo de desarrollo de Linux. Normalmente, estas 297 preguntas no recibirán escasez de respuestas, pero se debe tener en cuenta 298 que las personas que responden a esas preguntas no son abogados y no 299 pueden proporcionar consejo legal. Si tiene preguntas legales relacionadas 300 con el código fuente de Linux, no hay sustituto para hablar con un abogado 301 que entienda este campo. Confiar en las respuestas obtenidas en listas 302 técnicas de correo es un asunto arriesgado.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.