Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
docs/sp_SP: Add translation of process/1.Intro.rst
Translate Documentation/process/1.Intro.rst into Spanish
In order to avoid broken links in the translated document, empty files
have been created for documents which have not yet been translated.
Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
Reviewed-by: Carlos Bilbao <carlos.bilbao@amd.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20240305221839.2764380-4-avadhut.naik@amd.com
authored by
Avadhut Naik
and committed by
Jonathan Corbet
169e54c2
4ab16eb6
+381
+302
Documentation/translations/sp_SP/process/1.Intro.rst
+302
Documentation/translations/sp_SP/process/1.Intro.rst
···
1
+
.. include:: ../disclaimer-sp.rst
2
+
3
+
:Original: Documentation/process/1.Intro.rst
4
+
:Translator: Avadhut Naik <avadhut.naik@amd.com>
5
+
6
+
.. _sp_development_process_intro:
7
+
8
+
Introducción
9
+
============
10
+
11
+
Resumen ejecutivo
12
+
-----------------
13
+
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
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
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
21
+
estar disponible bajo una licencia compatible con GPL.
22
+
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"
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
27
+
herramientas y listas de correo. Se anima a los desarrolladores que deseen
28
+
comenzar con el desarrollo del kernel a encontrar y corregir errores como
29
+
ejercicio inicial.
30
+
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
33
+
lo antes posible.
34
+
35
+
:ref:`sp_development_coding` trata sobre el proceso de codificación. Se
36
+
discuten varios escollos encontrados por otros desarrolladores. Se cubren
37
+
algunos requisitos para los parches, y hay una introducción a algunas de
38
+
las herramientas que pueden ayudar a garantizar que los parches del kernel
39
+
sean correctos.
40
+
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,
43
+
los parches deben estar correctamente formateados y descritos, y deben
44
+
enviarse al lugar correcto. Seguir los consejos de esta sección debería
45
+
ayudar a garantizar la mejor recepción posible para su trabajo.
46
+
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
50
+
ofrece varios consejos sobre cómo evitar problemas en esta importante
51
+
etapa. Se advierte a los desarrolladores que no asuman que el trabajo está
52
+
terminado cuando un parche se fusiona en mainline.
53
+
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
56
+
por otros.
57
+
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.
60
+
61
+
De qué trata este documento
62
+
---------------------------
63
+
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
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
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,
71
+
eficiente, y escalable para casi cualquier situación.
72
+
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
75
+
vendedores de hardware quieren asegurarse de que Linux sea compatible con
76
+
sus productos, lo que hace que esos productos sean atractivos para los
77
+
usuarios de Linux. Los vendedores de sistemas embebidos, que utilizan
78
+
Linux como componente de un producto integrado, quieren que Linux sea lo
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
82
+
kernel de Linux. Y los usuarios finales, también, a menudo desearán
83
+
cambiar Linux para que se adapte mejor a sus necesidades.
84
+
85
+
Una de las características más convincentes de Linux es que es accesible
86
+
a estos desarrolladores; cualquier persona con las habilidades necesarias
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
93
+
empresas diferentes (o sin pertenecer a ninguna empresa).
94
+
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
101
+
se cambian todos los días. Por lo tanto, no es sorprendente que el
102
+
proceso de desarrollo del kernel de Linux difiera mucho de los métodos de
103
+
desarrollo propietarios.
104
+
105
+
El proceso de desarrollo del kernel puede parecer extraño e intimidante
106
+
para los nuevos desarrolladores, pero hay buenas razones y una sólida
107
+
experiencia detrás de él. Un desarrollador que no entienda las formas de
108
+
la comunidad del kernel (o, peor aún, que intente burlarse o eludirlas)
109
+
tendrá una experiencia frustrante por delante. La comunidad de
110
+
desarrollo, si bien es servicial para aquellos que están tratando de
111
+
aprender, tiene poco tiempo para aquellos que no escuchan o que no se
112
+
preocupan por el proceso de desarrollo.
113
+
114
+
Se espera que quienes lean este documento puedan evitar esa experiencia
115
+
frustrante. Hay mucho material aquí, pero el esfuerzo que implica leerlo
116
+
será recompensado en poco tiempo. La comunidad de desarrollo siempre
117
+
necesita desarrolladores que ayudan a mejorar el kernel; el siguiente
118
+
texto debería ayudarle – o a quienes trabajan para usted, a unirse a
119
+
nuestra comunidad.
120
+
121
+
Créditos
122
+
--------
123
+
124
+
Este documento fue escrito por Jonathan Corbet, corbet@lwn.net. Ha sido
125
+
mejorado por los comentarios de Johannes Berg, James Berry, Alex Chiang,
126
+
Roland Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur
127
+
Marsh, Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata y
128
+
Jochen Voß.
129
+
Este trabajo fue respaldado por la Fundación Linux; gracias especialmente
130
+
a Amanda McPherson, quien reconoció el valor de este esfuerzo e hizo que
131
+
todo sucediera.
132
+
133
+
Importancia de integrar el código en el mainline
134
+
------------------------------------------------
135
+
136
+
Algunas empresas y desarrolladores ocasionalmente se preguntan por qué
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
139
+
kernel mantenido por Linus Torvalds y utilizado como base por los
140
+
distribuidores de Linux. A corto plazo, contribuir con código puede
141
+
parecer un gasto evitable; parece más fácil mantener el código separado
142
+
y dar soporte a los usuarios directamente. La verdad del asunto es que
143
+
mantener el código separado (“fuera del árbol”) es pan para hoy y hambre
144
+
para mañana.
145
+
146
+
Para ilustrar los costos del código fuera-del-árbol, aquí hay algunos
147
+
aspectos relevantes del proceso de desarrollo del kernel. La mayoría de
148
+
estos se discutirán con mayor detalle más adelante en este documento.
149
+
Considerar:
150
+
151
+
- El código que se ha fusionado con el kernel mainline está disponible
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
156
+
el desarrollador y para el usuario. La incorporación al mainline
157
+
resuelve un gran número de problemas de distribución y soporte.
158
+
159
+
- Mientras los desarrolladores del kernel se esfuerzan por mantener una
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
165
+
código fuera-del-árbol requiere un mantenimiento constante si va a
166
+
funcionar con los nuevos kernels. Mantener el código fuera-del-árbol
167
+
requiere una cantidad significativa de trabajo sólo para que ese código
168
+
siga funcionando.
169
+
170
+
En su lugar, el código en el mainline no requiere este trabajo como
171
+
resultado de una regla simple que requiere que cualquier desarrollador
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
174
+
el mainline tiene costos de mantenimiento significativamente más bajos.
175
+
176
+
- Más allá de eso, el código que está en el kernel a menudo será
177
+
mejorado por otros desarrolladores. Resultados sorprendentes pueden
178
+
provenir de capacitar a su comunidad de usuarios y clientes para mejorar
179
+
su producto.
180
+
181
+
- El código del kernel se somete a revisión, tanto antes como después
182
+
de fusionarse con el mainline. No importa cuán fuertes sean las
183
+
habilidades del desarrollador original, este proceso de revisión
184
+
invariablemente encuentra formas en las que se puede mejorar el código.
185
+
A menudo la revisión encuentra errores graves y problemas de seguridad.
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
188
+
revisión por desarrolladores externos. El código fuera-del-árbol es
189
+
de menor calidad.
190
+
191
+
- La participación en el proceso de desarrollo es su manera de influir en
192
+
la dirección del desarrollo del kernel. Los usuarios que se quejan
193
+
desde el sofa son escuchados, pero los desarrolladores activos tienen
194
+
una voz más fuerte – y la capacidad de implementar cambios que hacen
195
+
que el kernel funcione mejor para sus necesidades.
196
+
197
+
- Cuando el código se mantiene por separado, siempre existe la posibilidad
198
+
de que un tercero contribuya a una implementación diferente de una
199
+
característica similar. Si eso sucede, conseguir que su código
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
202
+
una característica no estándar fuera del árbol indefinidamente, o
203
+
(2) abandonar su código y migrar sus usuarios a la versión en el árbol.
204
+
205
+
- La contribución del código es la acción fundamental que hace que todo
206
+
el proceso funcione. Al contribuir con su código, puede agregar nuevas
207
+
funcionalidades al kernel y proporcionar capacidades y ejemplos que son
208
+
útiles para otros desarrolladores del kernel. Si ha desarrollado código
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
211
+
de las mejores maneras de ayudar a garantizar ese éxito.
212
+
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
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:
218
+
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
226
+
asesoramiento legal. Solo los tribunales pueden determinar el verdadero
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.
229
+
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
232
+
desarrolladores del kernel ni siquiera lo intentarán. Por lo tanto,
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.
235
+
236
+
- El soporte también es más difícil para los distribuidores de módulos
237
+
únicamente en binario, que deben proporcionar una versión del módulo
238
+
para cada distribución y cada versión del kernel que deseen apoyar.
239
+
Podría requerir docenas de compilaciones de un solo módulo para
240
+
proporcionar una cobertura razonablemente completa, y sus usuarios
241
+
tendrán que actualizar su módulo por separado cada vez que
242
+
actualicen su kernel.
243
+
244
+
- Todo lo que se dijo anteriormente sobre la revisión de código se aplica
245
+
doblemente al código cerrado. Dado que este código no está disponible
246
+
en absoluto, no puede haber sido revisado por la comunidad y, sin duda,
247
+
tendrá serios problemas.
248
+
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
251
+
creyendo que están enviando un producto autónomo que utiliza una
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
255
+
capacidades a su producto. Pero estos productos también tienen una vida
256
+
comercial limitada, después de la cual se debe lanzar una nueva versió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
259
+
producto rápidamente para el mercado.
260
+
261
+
Licencias
262
+
---------
263
+
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
268
+
cubiertas ya sea por la GPLv2 (con, opcionalmente, un lenguaje que permite
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
271
+
licencia compatible no será aceptada en el kernel.
272
+
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
276
+
tiene miles de propietarios.
277
+
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.
284
+
285
+
Es imperativo que todo el código aportado al kernel sea legítimamente
286
+
software libre. Por esa razón, no se aceptará código de colaboradores
287
+
anónimos (o seudónimos). Todos los colaboradores están obligados a
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
292
+
se deriva de esfuerzos de ingeniería inversa que carecen de las garantías
293
+
adecuadas) no puede ser contribuido.
294
+
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
298
+
que las personas que responden a esas preguntas no son abogados y no
299
+
pueden proporcionar consejo legal. Si tiene preguntas legales relacionadas
300
+
con el código fuente de Linux, no hay sustituto para hablar con un abogado
301
+
que entienda este campo. Confiar en las respuestas obtenidas en listas
302
+
técnicas de correo es un asunto arriesgado.
+11
Documentation/translations/sp_SP/process/2.Process.rst
+11
Documentation/translations/sp_SP/process/2.Process.rst
+11
Documentation/translations/sp_SP/process/3.Early-stage.rst
+11
Documentation/translations/sp_SP/process/3.Early-stage.rst
+11
Documentation/translations/sp_SP/process/4.Coding.rst
+11
Documentation/translations/sp_SP/process/4.Coding.rst
+11
Documentation/translations/sp_SP/process/5.Posting.rst
+11
Documentation/translations/sp_SP/process/5.Posting.rst
+11
Documentation/translations/sp_SP/process/6.Followthrough.rst
+11
Documentation/translations/sp_SP/process/6.Followthrough.rst
+11
Documentation/translations/sp_SP/process/7.AdvancedTopics.rst
+11
Documentation/translations/sp_SP/process/7.AdvancedTopics.rst
+11
Documentation/translations/sp_SP/process/8.Conclusion.rst
+11
Documentation/translations/sp_SP/process/8.Conclusion.rst