Lines Matching full:en

19 comunidad en muchas formas, y la capacidad de influir en la dirección del
25 (merge window). Se cubren las distintas fases en el desarrollo del parche,
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
42 su revisión. Para ser tomados en serio por la comunidad de desarrollo,
48 parches; el trabajo está lejos de terminar en ese momento. Trabajar con
50 ofrece varios consejos sobre cómo evitar problemas en esta importante
52 terminado cuando un parche se fusiona en mainline.
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
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
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
87 puede mejorar Linux e influir en la dirección de su desarrollo. Los
89 característica del proceso de software libre. Pero, en todo caso, el
100 producto de alta calidad) en un entorno donde miles de líneas de código
116 será recompensado en poco tiempo. La comunidad de desarrollo siempre
133 Importancia de integrar el código en el mainline
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
148 estos se discutirán con mayor detalle más adelante en este documento.
152   para todos los usuarios de Linux. Estará presente automáticamente en
161   está en constante cambio. La falta de una interfaz interna estable es
163   fundamentales en cualquier momento y da como resultado un código de
170   En su lugar, el código en el mainline no requiere este trabajo como
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
176 - Más allá de eso, el código que está en el kernel a menudo será
184   invariablemente encuentra formas en las que se puede mejorar el código.
186   Esto es especialmente cierto para el código que se ha desarrollado en
191 - La participación en el proceso de desarrollo es su manera de influir en
203   (2) abandonar su código y migrar sus usuarios a la versión en el árbol.
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
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:
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;
225   de este texto no es abogado, y nada en este documento puede considerarse
233   la distribución de módulos únicamente en binario hará que sea más
237   únicamente en binario, que deben proporcionar una versión del módulo
246   en absoluto, no puede haber sido revisado por la comunidad y, sin duda,
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
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
266 Pública General de GNU (GPLv2), que cubre la distribución del kernel. En
269 la distribución en versiones posteriores de la GPL) o por la licencia BSD
271 licencia compatible no será aceptada en el kernel.
274 código aportado al kernel. Todo el código fusionado en el kernel
280 Hay pocos escenarios prácticos en los que se pueda obtener el acuerdo de
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.
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
301 que entienda este campo. Confiar en las respuestas obtenidas en listas