Documentation/translations/sp_SP/process/2.Process.rst
Source file repositories/reference/linux-study-clean/Documentation/translations/sp_SP/process/2.Process.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/translations/sp_SP/process/2.Process.rst- Extension
.rst- Size
- 27744 bytes
- Lines
- 544
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. include:: ../disclaimer-sp.rst
:Original: Documentation/process/2.Process.rst
:Translator: Avadhut Naik <avadhut.naik@amd.com>
.. _sp_development_process:
Cómo funciona el proceso de desarrollo
======================================
El desarrollo del kernel de Linux a principios de la década de 1990 fue
un asunto relajado, con un número relativamente pequeño de usuarios y
desarrolladores involucrados. Con una base de usuarios en los millones y
alrededor de 2,000 desarrolladores involucrados durante un año, el kernel
ha tenido que adaptar varios procesos para mantener el desarrollo sin
problemas. Se requiere una comprensión solida de cómo funciona el proceso
para ser una parte efectiva del mismo.
El panorama general
-------------------
Los desarrolladores del kernel utilizan un proceso de lanzamiento basado
en el tiempo de manera flexible, con uno nuevo lanzamiento principal del
kernel ocurriendo cada dos o tres meses. El historial reciente de
lanzamientos se ve así:
====== ==================
5.0 Marzo 3, 2019
5.1 Mayo 5, 2019
5.2 Julio 7, 2019
5.3 Septiembre 15, 2019
5.4 Noviembre 24, 2019
5.5 Enero 6, 2020
====== ==================
Cada lanzamiento 5.x es un lanzamiento principal del kernel con nuevas
características, cambios internos en la API y más. Un lanzamiento típico
puede contener alrededor de 13,000 conjuntos de cambios incluyendo en
varias centenas de miles de líneas de código. 5.x es la vanguardia del
desarrollo del kernel de Linux; el kernel utiliza un modelo de desarrollo
continuo que está integrando continuamente cambios importantes.
Se sigue una disciplina relativamente sencilla con respecto a la fusión
de parches para cada lanzamiento. Al comienzo de cada ciclo de desarrollo,
se dice que la "merge window" (ventana de fusión) está abierta. En ese
momento, el código que se considera lo suficientemente estable (y que es
aceptado por la comunidad de desarrollo) se fusiona en el kernel mainline.
La mayor parte de los cambios para un nuevo ciclo de desarrollo (y todos
los cambios principales) se fusionarán durante este tiempo, a un ritmo
cercano a los 1,000 cambios (“parches” o “conjuntos de cambios”) por
día.
(Aparte, vale la pena señalar que los cambios integrados durante la
ventana de fusión no surgen de la nada; han sido recolectados, probados
y montados con anticipación. Como funciona ese proceso se describirá en
detalle más adelante).
La ventana de fusión dura aproximadamente dos semanas. Al final de este
tiempo, Linux Torvalds declarará que la ventana está cerrada y publicará
el primero de los kernels “rc”. Para el kernel destinado a ser 5.6, por
ejemplo, el lanzamiento al final de la ventana de fusión se llamará
5.6-rc1. El lanzamiento -rc1 señala que el tiempo para fusionar nuevas
características ha pasado y que el tiempo para estabilizar el siguiente
kernel ha comenzado.
Durante las próximas seis a diez semanas, solo los parches que solucionen
problemas deben enviarse al mainline. En ocasiones, se permitirá un cambio
más significativo, pero tales ocasiones son raras; los desarrolladores que
intentan fusionar nuevas características fuera de la ventana de fusión
suelen recibir una recepción poco amistosa. Como regla general, si se
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.