Lines Matching refs:de
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
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
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"
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
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
35 :ref:`sp_development_coding` trata sobre el proceso de codificación. Se
37 algunos requisitos para los parches, y hay una introducción a algunas de
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,
44 enviarse al lugar correcto. Seguir los consejos de esta sección debería
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
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
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
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,
73 Con el crecimiento de Linux, ha llegado un aumento en el número de
75 vendedores de hardware quieren asegurarse de que Linux sea compatible con
77 usuarios de Linux. Los vendedores de sistemas embebidos, que utilizan
78 Linux como componente de un producto integrado, quieren que Linux sea lo
80 y otros vendedores de software que basan sus productos en Linux tienen un
82 kernel de Linux. Y los usuarios finales, también, a menudo desearán
85 Una de las características más convincentes de Linux es que es accesible
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
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
102 proceso de desarrollo del kernel de Linux difiera mucho de los métodos de
105 El proceso de desarrollo del kernel puede parecer extraño e intimidante
107 experiencia detrás de él. Un desarrollador que no entienda las formas de
109 tendrá una experiencia frustrante por delante. La comunidad de
110 desarrollo, si bien es servicial para aquellos que están tratando de
112 preocupan por el proceso de desarrollo.
116 será recompensado en poco tiempo. La comunidad de desarrollo siempre
125 mejorado por los comentarios de Johannes Berg, James Berry, Alex Chiang,
130 a Amanda McPherson, quien reconoció el valor de este esfuerzo e hizo que
133 Importancia de integrar el código en el mainline
140 distribuidores de Linux. A corto plazo, contribuir con código puede
147 aspectos relevantes del proceso de desarrollo del kernel. La mayoría de
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
157 resuelve un gran número de problemas de distribución y soporte.
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
167 requiere una cantidad significativa de trabajo sólo para que ese código
171 resultado de una regla simple que requiere que cualquier desarrollador
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.
176 - Más allá de eso, el código que está en el kernel a menudo será
178 provenir de capacitar a su comunidad de usuarios y clientes para mejorar
182 de fusionarse con el mainline. No importa cuán fuertes sean las
183 habilidades del desarrollador original, este proceso de revisión
185 A menudo la revisión encuentra errores graves y problemas de seguridad.
187 un entorno cerrado; dicho código se beneficia fuertemente de la
189 de menor calidad.
191 - La participación en el proceso de desarrollo es su manera de influir en
194 una voz más fuerte – y la capacidad de implementar cambios que hacen
198 de que un tercero contribuya a una implementación diferente de una
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
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.
213 Todo el razonamiento anterior se aplica a cualquier código de kernel
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;
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
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.
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
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.
236 - El soporte también es más difícil para los distribuidores de módulos
239 Podría requerir docenas de compilaciones de un solo módulo para
244 - Todo lo que se dijo anteriormente sobre la revisión de código se aplica
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
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
256 comercial limitada, después de la cual se debe lanzar una nueva versión.
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
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
273 No se requieren (ni se solicitan) cesiones de derechos de autor para el
276 tiene miles de propietarios.
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.
286 software libre. Por esa razón, no se aceptará código de colaboradores
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
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
300 con el código fuente de Linux, no hay sustituto para hablar con un abogado
302 técnicas de correo es un asunto arriesgado.