Lines Matching full:se

25 (merge window). Se cubren las distintas fases en el desarrollo del parche,
27 herramientas y listas de correo. Se anima a los desarrolladores que deseen
35 :ref:`sp_development_coding` trata sobre el proceso de codificación. Se
36 discuten varios escollos encontrados por otros desarrolladores. Se cubren
51 etapa. Se advierte a los desarrolladores que no asuman que el trabajo está
52 terminado cuando un parche se fusiona en mainline.
68 del sistema operativo que se ejecuta en reproductores de música digital
83 cambiar Linux para que se adapte mejor a sus necesidades.
101 se cambian todos los días. Por lo tanto, no es sorprendente que el
111 aprender, tiene poco tiempo para aquellos que no escuchan o que no se
114 Se espera que quienes lean este documento puedan evitar esa experiencia
136 Algunas empresas y desarrolladores ocasionalmente se preguntan por qué
148 estos se discutirán con mayor detalle más adelante en este documento.
151 - El código que se ha fusionado con el kernel mainline está disponible
159 - Mientras los desarrolladores del kernel se esfuerzan por mantener una
173   se rompa como resultado de ese cambio. Así que, el código fusionado en
181 - El código del kernel se somete a revisión, tanto antes como después
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
187   un entorno cerrado; dicho código se beneficia fuertemente de la
192   la dirección del desarrollo del kernel. Los usuarios que se quejan
197 - Cuando el código se mantiene por separado, siempre existe la posibilidad
201   Entonces se enfrentará a las desagradables alternativas de (1) mantener
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
224   Pública General de GNU (sobre la que se dirá más adelante). El autor
244 - Todo lo que se dijo anteriormente sobre la revisión de código se aplica
250 tentados a ignorar gran parte de lo que se ha dicho en esta sección
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
273 No se requieren (ni se solicitan) cesiones de derechos de autor para el
280 Hay pocos escenarios prácticos en los que se pueda obtener el acuerdo de
286 software libre. Por esa razón, no se aceptará código de colaboradores
292 se deriva de esfuerzos de ingeniería inversa que carecen de las garantías
297 preguntas no recibirán escasez de respuestas, pero se debe tener en cuenta