Lines Matching refs:el
14 El resto de esta sección cubre el alcance del proceso de desarrollo del
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
23 :ref:`sp_development_process` introduce el proceso de desarrollo, el ciclo
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
28 comenzar con el desarrollo del kernel a encontrar y corregir errores como
35 :ref:`sp_development_coding` trata sobre el proceso de codificación. Se
41 :ref:`sp_development_posting` trata sobre el proceso de enviar parches para
48 parches; el trabajo está lejos de terminar en ese momento. Trabajar con
51 etapa. Se advierte a los desarrolladores que no asuman que el trabajo está
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.
67 1991, este kernel ha evolucionado hasta convertirse en el mejor componente
73 Con el crecimiento de Linux, ha llegado un aumento en el número de
81 claro interés en las capacidades, el rendimiento, y la fiabilidad del
89 característica del proceso de software libre. Pero, en todo caso, el
97 experimentado dificultades al tratar de hacer el trabajo del kernel. La
101 se cambian todos los días. Por lo tanto, no es sorprendente que el
112 preocupan por el proceso de desarrollo.
115 frustrante. Hay mucho material aquí, pero el esfuerzo que implica leerlo
117 necesita desarrolladores que ayudan a mejorar el kernel; el siguiente
130 a Amanda McPherson, quien reconoció el valor de este esfuerzo e hizo que
133 Importancia de integrar el código en el mainline
138 kernel y obtener su código en el kernel mainline (el “mainline” es el
141 parecer un gasto evitable; parece más fácil mantener el código separado
143 mantener el código separado (“fuera del árbol”) es pan para hoy y hambre
151 - El código que se ha fusionado con el kernel mainline está disponible
156 el desarrollador y para el usuario. La incorporación al mainline
160 interfaz estable para el espacio de usuario, la API interna de kernel
166 funcionar con los nuevos kernels. Mantener el código fuera-del-árbol
170 En su lugar, el código en el mainline no requiere este trabajo como
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á
182 de fusionarse con el mainline. No importa cuán fuertes sean las
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
193 desde el sofa son escuchados, pero los desarrolladores activos tienen
195 que el kernel funcione mejor para sus necesidades.
197 - Cuando el código se mantiene por separado, siempre existe la posibilidad
200 fusionado será mucho más difícil – hasta el punto de la imposibilidad.
203 (2) abandonar su código y migrar sus usuarios a la versión en el árbol.
206 el proceso funcione. Al contribuir con su código, puede agregar nuevas
210 en el éxito continuo de esta plataforma; contribuir con código es una
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
220 propietarios del kernel son, en el mejor de los casos, confusas;
226 asesoramiento legal. Solo los tribunales pueden determinar el verdadero
231 problemas del kernel, hasta el punto de que la mayoría de los
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
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.
265 todo el código debe ser compatible con la versión 2 de la Licencia
271 licencia compatible no será aceptada en el kernel.
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
280 Hay pocos escenarios prácticos en los que se pueda obtener el acuerdo de
285 Es imperativo que todo el código aportado al kernel sea legítimamente
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
300 con el código fuente de Linux, no hay sustituto para hablar con un abogado