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/2.Process.rst
Translate Documentation/process/2.Process.rst into Spanish
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-5-avadhut.naik@amd.com
authored by
Avadhut Naik
and committed by
Jonathan Corbet
3dfa8cd9
169e54c2
+534
-2
+533
-2
Documentation/translations/sp_SP/process/2.Process.rst
+533
-2
Documentation/translations/sp_SP/process/2.Process.rst
···
1
1
.. include:: ../disclaimer-sp.rst
2
2
3
3
:Original: Documentation/process/2.Process.rst
4
+
:Translator: Avadhut Naik <avadhut.naik@amd.com>
4
5
5
6
.. _sp_development_process:
6
7
7
8
Cómo funciona el proceso de desarrollo
8
9
======================================
9
10
10
-
.. warning::
11
-
TODO aún no traducido
11
+
El desarrollo del kernel de Linux a principios de la década de 1990 fue
12
+
un asunto relajado, con un número relativamente pequeño de usuarios y
13
+
desarrolladores involucrados. Con una base de usuarios en los millones y
14
+
alrededor de 2,000 desarrolladores involucrados durante un año, el kernel
15
+
ha tenido que adaptar varios procesos para mantener el desarrollo sin
16
+
problemas. Se requiere una comprensión solida de cómo funciona el proceso
17
+
para ser una parte efectiva del mismo.
18
+
19
+
El panorama general
20
+
-------------------
21
+
22
+
Los desarrolladores del kernel utilizan un proceso de lanzamiento basado
23
+
en el tiempo de manera flexible, con uno nuevo lanzamiento principal del
24
+
kernel ocurriendo cada dos o tres meses. El historial reciente de
25
+
lanzamientos se ve así:
26
+
27
+
====== ==================
28
+
5.0 Marzo 3, 2019
29
+
5.1 Mayo 5, 2019
30
+
5.2 Julio 7, 2019
31
+
5.3 Septiembre 15, 2019
32
+
5.4 Noviembre 24, 2019
33
+
5.5 Enero 6, 2020
34
+
====== ==================
35
+
36
+
Cada lanzamiento 5.x es un lanzamiento principal del kernel con nuevas
37
+
características, cambios internos en la API y más. Un lanzamiento típico
38
+
puede contener alrededor de 13,000 conjuntos de cambios incluyendo en
39
+
varias centenas de miles de líneas de código. 5.x es la vanguardia del
40
+
desarrollo del kernel de Linux; el kernel utiliza un modelo de desarrollo
41
+
continuo que está integrando continuamente cambios importantes.
42
+
43
+
Se sigue una disciplina relativamente sencilla con respecto a la fusión
44
+
de parches para cada lanzamiento. Al comienzo de cada ciclo de desarrollo,
45
+
se dice que la "merge window" (ventana de fusión) está abierta. En ese
46
+
momento, el código que se considera lo suficientemente estable (y que es
47
+
aceptado por la comunidad de desarrollo) se fusiona en el kernel mainline.
48
+
La mayor parte de los cambios para un nuevo ciclo de desarrollo (y todos
49
+
los cambios principales) se fusionarán durante este tiempo, a un ritmo
50
+
cercano a los 1,000 cambios (“parches” o “conjuntos de cambios”) por
51
+
día.
52
+
53
+
(Aparte, vale la pena señalar que los cambios integrados durante la
54
+
ventana de fusión no surgen de la nada; han sido recolectados, probados
55
+
y montados con anticipación. Como funciona ese proceso se describirá en
56
+
detalle más adelante).
57
+
58
+
La ventana de fusión dura aproximadamente dos semanas. Al final de este
59
+
tiempo, Linux Torvalds declarará que la ventana está cerrada y publicará
60
+
el primero de los kernels “rc”. Para el kernel destinado a ser 5.6, por
61
+
ejemplo, el lanzamiento al final de la ventana de fusión se llamará
62
+
5.6-rc1. El lanzamiento -rc1 señala que el tiempo para fusionar nuevas
63
+
características ha pasado y que el tiempo para estabilizar el siguiente
64
+
kernel ha comenzado.
65
+
66
+
Durante las próximas seis a diez semanas, solo los parches que solucionen
67
+
problemas deben enviarse al mainline. En ocasiones, se permitirá un cambio
68
+
más significativo, pero tales ocasiones son raras; los desarrolladores que
69
+
intentan fusionar nuevas características fuera de la ventana de fusión
70
+
suelen recibir una recepción poco amistosa. Como regla general, si se
71
+
pierde la ventana de fusión de una característica determinada, lo mejor
72
+
que puede hacer es esperar al siguiente ciclo de desarrollo. (Se hace una
73
+
excepción ocasional para los drivers de hardware que no se admitía
74
+
anteriormente; si no afectan a ningún código en árbol, no pueden causar
75
+
regresiones y debería ser seguro agregarlos en cualquier momento).
76
+
77
+
A medida que las correcciones se abren paso en el mainline, la tasa de
78
+
parches se ralentizará con el tiempo. Linus lanza nuevos kernels -rc
79
+
aproximadamente una vez a la semana; una serie normal llegará a algún
80
+
punto entre -rc6 y -rc9 antes de que se considere que el kernel es
81
+
suficientemente estable y realice el lanzamiento final. En ese momento,
82
+
todo el proceso vuelve a empezar.
83
+
84
+
Como ejemplo, así fue el ciclo de desarrollo de 5.4 (todas las fechas son
85
+
de 2019):
86
+
87
+
============== =======================================
88
+
Septiembre 15 5.3 lanzamiento estable
89
+
Septiembre 30 5.4-rc1, la ventana de fusion se cierra
90
+
Octubre 6 5.4-rc2
91
+
Octubre 13 5.4-rc3
92
+
Octubre 20 5.4-rc4
93
+
Octubre 27 5.4-rc5
94
+
Noviembre 3 5.4-rc6
95
+
Noviembre 10 5.4-rc7
96
+
Noviembre 17 5.4-rc8
97
+
Noviembre 24 5.4 lanzamiento estable
98
+
============== =======================================
99
+
100
+
¿Cómo deciden los desarrolladores cuándo cerrar el ciclo de desarrollo
101
+
y crear el lanzamiento estable? La métrica más significativa utilizada
102
+
es la lista de regresiones de lanzamientos anteriores. Ningunos errores
103
+
son bienvenidos, pero aquellos que rompen sistemas que funcionaron en el
104
+
pasado se consideran especialmente graves. Por esta razón, los parches
105
+
que causan regresiones se ven con malos ojos y es bastante probable que
106
+
se reviertan durante el periodo de estabilización.
107
+
108
+
El objetivo de los desarrolladores es corregir todas las regresiones
109
+
conocidas antes de que se realice el lanzamiento estable. En el mundo
110
+
real, este tipo de perfección es difícil de lograr; hay demasiados
111
+
variables en un proyecto de este tamaño. Llega un punto en el que
112
+
retrasar el lanzamiento final solo empeora el problema; la pila de cambios
113
+
que esperan la siguiente ventana de fusión crecerá, creando aún más
114
+
regresiones la próxima vez. Por lo tanto, la mayoría de los kernels 5.x
115
+
se lanzan con un punado de regresiones conocidas, aunque, con suerte,
116
+
ninguna de ellas es seria.
117
+
118
+
Una vez que se realiza un lanzamiento estable, su mantenimiento continuo
119
+
se transfiere al “equipo estable”, actualmente encabezado por Greg
120
+
Kroah-Hartman. El equipo estable lanzará actualizaciones ocasionales al
121
+
lanzamiento estable utilizando el esquema de numeración 5.x.y. Para ser
122
+
considerado para un lanzamiento de actualización, un parche debe
123
+
(1) corregir un error significativo y (2) ya estar fusionado en el
124
+
mainline para el siguiente kernel de desarrollo. Por lo general, los
125
+
kernels recibirán actualizaciones estables durante un poco más de un
126
+
ciclo de desarrollo después de su lanzamiento inicial. Así, por ejemplo,
127
+
la historia del kernel 5.2 se veía así (todas las fechas en 2019):
128
+
129
+
============== ===============================
130
+
Julio 7 5.2 lanzamiento estable
131
+
Julio 14 5.2.1
132
+
Julio 21 5.2.2
133
+
Julio 26 5.2.3
134
+
Julio 28 5.2.4
135
+
Julio 31 5.2.5
136
+
... ...
137
+
Octubre 11 5.2.21
138
+
============== ===============================
139
+
140
+
5.2.21 fue la última actualización estable del lanzamiento 5.2.
141
+
142
+
Algunos kernels se designan como kernels “a largo plazo”; recibirán
143
+
soporte durante un periodo más largo. Consulte el siguiente enlace para
144
+
obtener la lista de versiones activas del kernel a largo plazos y sus
145
+
maintainers:
146
+
147
+
https://www.kernel.org/category/releases.html
148
+
149
+
La selección de un kernel para soporte a largo plazo es puramente una
150
+
cuestión de que un maintainer tenga la necesidad y el tiempo para
151
+
mantener ese lanzamiento. No hay planes conocidos para ofrecer soporte a
152
+
largo plazo para ningún lanzamiento especifico próximo.
153
+
154
+
Ciclo de vida de un parche
155
+
--------------------------
156
+
157
+
Los parches no van directamente desde el teclado del desarrollador al
158
+
kernel mainline. Hay, en cambio, un proceso algo complicado (aunque algo
159
+
informal) diseñado para garantizar que cada parche sea revisado en cuanto
160
+
a calidad y que cada parche implemente un cambio que es deseable tener en
161
+
el mainline. Este proceso puede ocurrir rápidamente para correcciones
162
+
menores, o, en el caso de cambios grandes y controvertidos, continuar
163
+
durante años. Gran parte de la frustración de los desarrolladores proviene
164
+
de la falta de compresión de este proceso o de sus intentos de eludirlo.
165
+
166
+
Con la esperanza de reducir esa frustración, este documento describirá
167
+
cómo un parche entra en el kernel. Lo que sigue a continuación es una
168
+
introducción que describe el proceso de una manera tanto idealizada. Un
169
+
tratamiento mucho más detallado vendrá en secciones posteriores.
170
+
171
+
Las etapas por las que pasa un parche son, generalmente:
172
+
173
+
- Diseño. Aquí es donde se establecen los requisitos reales para el
174
+
parche – y la forma en que se cumplirán esos requisitos. El trabajo
175
+
de diseño a menudo se realiza sin involucrar a la comunidad, pero es
176
+
mejor hacer este trabajo de manera abierta si es posible; puede ahorrar
177
+
mucho tiempo rediseñando las cosas más tarde.
178
+
179
+
- Revisión inicial. Los parches se publican en la lista de correo
180
+
relevante y los desarrolladores en esa lista responden con cualquier
181
+
comentario que puedan tener. Este proceso debería revelar cualquier
182
+
problema importante con un parche si todo va bien.
183
+
184
+
- Revisión más amplia. Cuando el parche se acerca a estar listo para su
185
+
inclusión en el mainline, debe ser aceptado por un maintainer del
186
+
subsistema relevante – aunque esta aceptación no es una garantía de
187
+
que el parche llegara hasta el mainline. El parche aparecerá en el
188
+
árbol de subsistemas del maintainer y en los árboles -next (descritos
189
+
a continuación). Cuando el proceso funciona, este paso conduce a una
190
+
revisión exhaustiva del parche y al descubrimiento de cualquier
191
+
problema resultante de la integración de este parche con el trabajo
192
+
realizado por otros.
193
+
194
+
- Tenga en cuenta que la mayoría de los maintainers también tienen
195
+
trabajos diurnos, por lo que fusionar su parche no puede ser su máxima
196
+
prioridad. Si su parche está recibiendo comentarios sobre los cambios
197
+
que se necesitan, debería realizar esos cambios o justificar por qué
198
+
no deberían realizarse. Si su parche no tiene quejas de revisión, pero
199
+
no está siendo fusionado por el maintainer apropiado del subsistema o
200
+
del driver, debe ser persistente en la actualización del parche
201
+
al kernel actual para que se aplique limpiamente y seguir enviándolo
202
+
para su revisión y fusión.
203
+
204
+
- Fusión en el mainline. Eventualmente, un parche exitoso se fusionará
205
+
en el repositorio mainline administrado por Linux Torvalds. Mas
206
+
comentarios y/o problemas pueden surgir en este momento; es importante
207
+
que el desarrollador responda a estos y solucione cualquier problema
208
+
que surja.
209
+
210
+
- Lanzamiento estable. El número de usuarios potencialmente afectados por
211
+
el parche es ahora grande, por lo que, una vez más, pueden surgir
212
+
nuevos problemas.
213
+
214
+
- Mantenimiento a largo plazo. Si bien un desarrollador puede olvidarse
215
+
del código después de fusionarlo, ese comportamiento tiende a dejar
216
+
una impresión negativa en la comunidad de desarrollo. Fusionar el
217
+
código elimina parte de la carga de mantenimiento; otros solucionarán
218
+
los problemas causados por los cambios en la API. Sin embargo, el
219
+
desarrollador original debe seguir asumiendo la responsabilidad del
220
+
código si quiere seguir siendo útil a largo plazo.
221
+
222
+
Uno de los peores errores cometidos por los desarrolladores del kernel
223
+
(o sus empleadores) es tratar de reducir el proceso a un solo paso de
224
+
“fusión en el mainline”. Este enfoque conduce invariablemente a la
225
+
frustración de todos los involucrados.
226
+
227
+
Cómo se integran los parches en el kernel
228
+
-----------------------------------------
229
+
230
+
Hay exactamente una persona que puede fusionar parches en el repositorio
231
+
mainline del kernel: Linus Torvalds. Pero, por ejemplo, de los más de
232
+
9,500 parches que se incluyeron en el kernel 2.6.38, solo 112 (alrededor
233
+
del 1.3%) fueron elegidos directamente por Linus mismo. El proyecto del
234
+
kernel ha crecido mucho desde hace tiempo a un tamaño en el que ningún
235
+
desarrollador individual podría inspeccionar y seleccionar todos los
236
+
parches sin ayuda. La forma que los desarrolladores del kernel han
237
+
abordado este crecimiento es a través del uso de un sistema jerárquico
238
+
alrededor de una cadena de confianza.
239
+
240
+
La base de código del kernel se descompone lógicamente en un conjunto de
241
+
subsistemas: redes, soporte de arquitectura especifica, gestión de
242
+
memoria, dispositivos de video, etc. La mayoría de los subsistemas tienen
243
+
un maintainer designado, un desarrollador que tiene la responsabilidad
244
+
general del código dentro de ese subsistema. Estos maintainers de
245
+
subsistemas son los guardianes (en cierto modo) de la parte del kernel que
246
+
gestionan; son los que (usualmente) aceptarán un parche para incluirlo en
247
+
el kernel mainline.
248
+
249
+
Cada uno de los maintainers del subsistema administra su propia versión
250
+
del árbol de fuentes del kernel, generalmente (pero, ciertamente no
251
+
siempre) usando la herramienta de administración de código fuente de git.
252
+
Herramientas como git (y herramientas relacionadas como quilt o mercurial)
253
+
permiten a los maintainers realizar un seguimiento de una lista de
254
+
parches, incluida la información de autoría y otros metadatos. En
255
+
cualquier momento, el maintainer puede identificar qué parches de su
256
+
repositorio no se encuentran en el mainline.
257
+
258
+
Cuando se abre la ventana de fusión, los maintainers de nivel superior
259
+
le pedirán a Linus que “extraiga” los parches que han seleccionado para
260
+
fusionar de sus repositorios. Si Linus está de acuerdo, el flujo de
261
+
parches fluirá hacia su repositorio, convirtiéndose en parte del kernel
262
+
mainline. La cantidad de atención que Linus presta a los parches
263
+
específicos recibidos en una operación de extracción varia. Está claro
264
+
que, a veces, examina bastante de cerca. Pero, como regla general, Linus
265
+
confía en que los maintainers del subsistema no envíen parches
266
+
defectuosos al upstream.
267
+
268
+
Los maintainers de subsistemas, a su vez, pueden extraer parches de otros
269
+
maintainers. Por ejemplo, el árbol de red se construye a partir de
270
+
parches que se acumulan primero en arboles dedicados a drivers de
271
+
dispositivos de red, redes inalámbricas, etc. Esta cadena de repositorios
272
+
puede ser arbitrariamente larga, aunque rara vez supera los dos o tres
273
+
enlaces. Dado que cada maintainer de la cadena confía en los que
274
+
administran árboles de nivel inferior, este proceso se conoce como la
275
+
“cadena de confianza”.
276
+
277
+
Claramente, en un sistema como este, lograr que los parches se integren
278
+
en el kernel depende de encontrar el maintainer adecuado. Enviar parches
279
+
directamente a Linus no es normalmente la forma correcta de hacerlo.
280
+
281
+
Árboles siguientes (next)
282
+
-------------------------
283
+
284
+
La cadena de árboles de subsistemas guía el flujo de parches en el
285
+
kernel, pero también plantea una pregunta interesante: ¿Qué pasa si
286
+
alguien quiere ver todos los parches que se están preparando para la
287
+
próxima ventana de fusión? Los desarrolladores estarán interesados en
288
+
saber que otros cambios están pendientes para ver si hay algún conflicto
289
+
del que preocuparse; un parche que cambia un prototipo de función del
290
+
núcleo del kernel, por ejemplo, entrará en conflicto con cualquier otro
291
+
parche que utilice la forma anterior de esa función. Los revisores y
292
+
probadores quieren tener acceso a los cambios en su forma integrada antes
293
+
de que todos esos cambios se integren en el kernel mainline. Uno podría
294
+
extraer cambios de todos los árboles de subsistemas interesantes, pero
295
+
eso sería un trabajo tedioso y propenso a errores.
296
+
297
+
La respuesta viene en forma de árboles -next, donde los árboles de
298
+
subsistemas se recopilan para pruebas y revisiones. El más antiguo de
299
+
estos árboles, mantenido por Andrew Morton, se llama “-mm” (por gestión
300
+
de la memoria, que es como comenzó). El árbol “-mm” integra parches
301
+
de una larga lista de árboles de subsistemas; también tiene algunos
302
+
parches destinados a ayudar con la depuración.
303
+
304
+
Más allá de eso, -mm contiene una colección significativa de parches
305
+
que han sido seleccionados directamente por Andrew. Estos parches pueden
306
+
haber sido publicados en una lista de correo o aplicarse a una parte del
307
+
kernel para la que no hay un árbol de subsistemas designado. Como
308
+
resultado, -mm funciona como una especie de árbol de subsistemas de
309
+
último recurso; si no hay otro camino obvio para un parche en el mainline,
310
+
es probable que termine en -mm. Los parches misceláneos que se acumulan
311
+
en -mm eventualmente se enviarán a un árbol de subsistema apropiado o se
312
+
enviarán directamente a Linus. En un ciclo de desarrollo típico,
313
+
aproximadamente el 5-10% de los parches que van al mainline llegan allí
314
+
a través de -mm.
315
+
316
+
El parche -mm actual está disponible en el directorio “mmotm” (-mm
317
+
del momento) en:
318
+
319
+
https://www.ozlabs.org/~akpm/mmotm/
320
+
321
+
Sin embargo, es probable que el uso del árbol MMOTM sea una experiencia
322
+
frustrante; existe una posibilidad definitiva de que ni siquiera se
323
+
compile.
324
+
325
+
El árbol principal para la fusión de parches del siguiente ciclo es
326
+
linux-next, mantenido por Stephen Rothwell. El árbol linux-next es, por
327
+
diseño, una instantánea de cómo se espera que se vea el mainline después
328
+
de que se cierre la siguiente ventana de fusión. Los árboles linux-next
329
+
se anuncian en las listas de correo linux-kernel y linux-next cuando se
330
+
ensamblan; Se pueden descargar desde:
331
+
332
+
https://www.kernel.org/pub/linux/kernel/next/
333
+
334
+
Linux-next se ha convertido en una parte integral del proceso de
335
+
desarrollo del kernel; todos los parches fusionados durante una ventana
336
+
de fusión determinada deberían haber encontrado su camino en linux-next
337
+
en algún momento antes de que se abra la ventana de fusión.
338
+
339
+
Árboles de staging
340
+
------------------
341
+
342
+
El árbol de fuentes del kernel contiene el directorio drivers/staging/,
343
+
donde residen muchos subdirectorios para drivers o sistemas de archivos
344
+
que están en proceso de ser agregados al árbol del kernel. Permanecen
345
+
en drivers/staging mientras aún necesitan más trabajo; una vez
346
+
completados, se pueden mover al kernel propiamente dicho. Esta es una
347
+
forma de realizar un seguimiento de los drivers drivers que no están a la
348
+
altura de la codificación o los estándares de calidad del kernel de
349
+
Linux, pero que las personas pueden querer usarlos y realizar un
350
+
seguimiento del desarrollo.
351
+
352
+
Greg Kroah-Hartman mantiene actualmente el árbol de staging. Los drivers
353
+
que aun necesitan trabajo se le envían, y cada driver tiene su propio
354
+
subdirectorio en drivers/staging/. Junto con los archivos de origen del
355
+
driver, también debe haber un archivo TODO en el directorio. El archivo
356
+
TODO enumera el trabajo pendiente que el driver necesita para ser aceptado
357
+
en el kernel propiamente dicho, así como una lista de personas a las que
358
+
Cc’d para cualquier parche para el driver. Las reglas actuales exigen
359
+
que los drivers que contribuyen a staging deben, como mínimo, compilarse
360
+
correctamente.
361
+
362
+
El staging puede ser una forma relativamente fácil de conseguir nuevos
363
+
drivers en el mainline donde, con suerte, llamarán la atención de otros
364
+
desarrolladores y mejorarán rápidamente. Sin embargo, la entrada en el
365
+
staging no es el final de la historia; el código que no está viendo
366
+
progreso regular eventualmente será eliminado. Los distribuidores también
367
+
tienden a ser relativamente reacios a habilitar los drivers de staging.
368
+
Por lo tanto, el staging es, en el mejor de los casos, una parada en el
369
+
camino para hacia convertirse en un apropiado driver del mainline.
370
+
371
+
Herramientas
372
+
------------
373
+
374
+
Como se puede ver en el texto anterior, el proceso de desarrollo del
375
+
kernel depende en gran medida de la capacidad de dirigir colecciones de
376
+
parches en varias direcciones. Todo ello no funcionaría tan bien como lo
377
+
hace sin herramientas apropiadamente potentes. Los tutoriales sobre cómo
378
+
usar estas herramientas están mucho más allá del alcance de este
379
+
documento, pero hay espacio para algunos consejos.
380
+
381
+
Con mucho, el sistema de gestión de código fuente dominante utilizado
382
+
por la comunidad del kernel es git. Git es uno de los varios sistemas de
383
+
control de versiones distribuidos que se están desarrollando en la
384
+
comunidad de software libre. Está bien ajustado para el desarrollo de
385
+
kernel, ya que funciona bastante bien cuando se trata de grandes
386
+
repositorios y grandes cantidades de parches. También tiene la reputación
387
+
de ser difícil de aprender y usar, aunque ha mejorado con el tiempo.
388
+
Algún tipo de familiaridad con git es casi un requisito para los
389
+
desarrolladores del kernel; incluso si no lo usan para su propio
390
+
trabajo, necesitarán git para mantenerse al día con lo que otros
391
+
desarrolladores (y el mainline) están haciendo.
392
+
393
+
Git ahora está empaquetado por casi todas las distribuciones de Linux.
394
+
Hay una página de inicio en:
395
+
396
+
https://git-scm.com/
397
+
398
+
Esa página tiene punteros a documentación y tutoriales.
399
+
400
+
Entre los desarrolladores de kernel que no usan git, la opción más
401
+
popular es casi con certeza Mercurial:
402
+
403
+
https://www.selenic.com/mercurial/
404
+
405
+
Mercurial comparte muchas características con git, pero proporciona una
406
+
interfaz que muchos encuentran más fácil de usar.
407
+
408
+
Otra herramienta que vale la pena conocer es Quilt:
409
+
410
+
https://savannah.nongnu.org/projects/quilt/
411
+
412
+
Quilt es un sistema de gestión de parches, en lugar de un sistema de
413
+
gestión de código fuente. No rastrea el historial a lo largo del tiempo;
414
+
en cambio, está orientado al seguimiento de un conjunto especifico de
415
+
cambios en relación con una base de código en evolución. Algunos de los
416
+
principales maintainers de subsistemas utilizan Quilt para gestionar los
417
+
parches destinados a ir upstream. Para la gestión de ciertos tipos de
418
+
árboles (por ejemplo, -mm) Quilt es la mejor herramienta para el trabajo.
419
+
420
+
Listas de correo
421
+
----------------
422
+
423
+
Una gran parte del trabajo de desarrollo del kernel de Linux se realiza a
424
+
través de listas de correo. Es difícil ser un miembro plenamente funcional
425
+
de la comunidad sin unirse al menos a una lista en algún parte. Pero las
426
+
listas de correo de Linux también representan un peligro potencial para
427
+
los desarrolladores, que corren el riesgo de quedar enterrados bajo una
428
+
carga de correo electrónico, incumplir las convenciones utilizadas en las
429
+
listas de Linux, o ambas cosas.
430
+
431
+
La mayoría de las listas de correo del kernel se ejecutan en
432
+
vger.kernel.org; la lista principal se puede encontrar en:
433
+
434
+
http://vger.kernel.org/vger-lists.html
435
+
436
+
Sim embargo, hay listas alojadas en otros lugares; varios de ellos se
437
+
encuentran en redhat.com/mailman/listinfo.
438
+
439
+
La lista de correo principal para el desarrollo del kernel es, por
440
+
supuesto, linux-kernel. Esta lista es un lugar intimidante; el volumen
441
+
puede alcanzar 500 mensajes por día, la cantidad de ruido es alta, la
442
+
conversación puede ser muy técnica y los participantes no siempre se
443
+
preocupan por mostrar un alto grado de cortesía. Pero no hay otro lugar
444
+
donde la comunidad de desarrollo del kernel se reúna como un todo; los
445
+
desarrolladores que eviten esta lista se perderán información importante.
446
+
447
+
Hay algunos consejos que pueden ayudar a sobrevivir en el kernel de Linux:
448
+
449
+
- Haga que la lista se entregue en una carpeta separada, en lugar de su
450
+
buzón principal. Uno debe ser capaz de ignorar el flujo durante
451
+
periodos prolongados.
452
+
453
+
- No trate de seguir cada conversación, nadie lo hace. Es importante
454
+
filtrar tanto por el tema de interés (aunque tenga en cuenta que las
455
+
conversaciones prolongadas pueden alejarse del asunto original sin
456
+
cambiar la línea de asunto del correo electrónico) por las personas
457
+
que participan.
458
+
459
+
- No alimente a los trolls. Si alguien está tratando de provocar una
460
+
respuesta de enojo, ignórelos.
461
+
462
+
- Al responder al correo electrónico del kernel de Linux (o al de otras
463
+
listas) conserve el encabezado Cc: para todos los involucrados. En
464
+
ausencia de una razón solida (como una solicitud explícita), nunca debe
465
+
eliminar destinarios. Asegúrese siempre de que la persona a la que está
466
+
respondiendo esté en la lista Cc:. Esta convención también hace que no
467
+
sea necesario solicitar explícitamente que se le copie en las respuestas
468
+
a sus publicaciones.
469
+
470
+
- Busque en los archivos de la lista (y en la red en su conjunto) antes
471
+
de hacer preguntas. Algunos desarrolladores pueden impacientarse con
472
+
las personas que claramente no han hecho sus deberes.
473
+
474
+
- Utilice respuestas intercaladas (“en línea”), lo que hace que su
475
+
respuesta sea más fácil de leer. (Es decir, evite top-posting – la
476
+
práctica de poner su respuesta encima del texto citado al que está
477
+
respondiendo.) Para obtener más información, consulte
478
+
:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_interleaved_replies>`.
479
+
480
+
- Pregunte en la lista de correo correcta. linux-kernel puede ser el
481
+
punto de encuentro general, pero no es el mejor lugar para encontrar
482
+
desarrolladores de todos los subsistemas.
483
+
484
+
El último punto, encontrar la lista de correo correcta, es una fuente
485
+
común de errores para desarrolladores principiantes. Alguien que haga
486
+
una pregunta relacionada con las redes en linux-kernel seguramente
487
+
recibirá una surgencia educada para preguntar en la lista de netdev en su
488
+
lugar, ya que esa es la lista frecuentada por la mayoría de los
489
+
desarrolladores de redes. Existen otras listas para los subsistemas SCSI,
490
+
video4linux, IDE, sistema de archivos, etc. El mejor lugar para buscar
491
+
listas de correo es en el archivo MAINTAINERS incluido con el código
492
+
fuente del kernel.
493
+
494
+
Comenzar con el desarrollo del kernel
495
+
-------------------------------------
496
+
497
+
Las preguntas sobre como comenzar con el proceso de desarrollo del kernel
498
+
son comunes, tanto de individuos como de empresas. Igualmente comunes son
499
+
los pasos en falso que hacen que el comienzo de la relación sea más
500
+
difícil de lo que tiene que ser.
501
+
502
+
Las empresas a menudo buscan contratar desarrolladores conocidos para
503
+
iniciar un grupo de desarrollo. De hecho, esta puede ser una técnica
504
+
efectiva. Pero también tiende a ser caro y no hace mucho para crecer el
505
+
grupo de desarrolladores de kernel experimentados. Es posible poner al
506
+
día a los desarrolladores internos en el desarrollo de kernel de Linux,
507
+
dada la inversión de algún tiempo. Tomarse este tiempo puede dotar a un
508
+
empleador de un grupo de desarrolladores que comprendan tanto el kernel
509
+
como la empresa, y que también puedan ayudar a educar a otros. A medio
510
+
plazo, este es a menudo el enfoque más rentable.
511
+
512
+
Los desarrolladores individuales, a menudo, comprensiblemente, no tienen
513
+
un lugar para empezar. Comenzar con un proyecto grande puede ser
514
+
intimidante; a menudo uno quiere probar las aguas con algo más pequeño
515
+
primero. Este es el punto en el que algunos desarrolladores se lanzan a
516
+
la creación de parches para corregir errores ortográficos o problemas
517
+
menores de estilo de codificación. Desafortunadamente, dicho parches
518
+
crean un nivel de ruido que distrae a la comunidad de desarrollo en su
519
+
conjunto, por lo que, cada vez más, se los mira con desprecio. Los nuevos
520
+
desarrolladores que deseen presentarse a la comunidad no recibirán la
521
+
recepción que desean por estos medios.
522
+
523
+
Andrew Morton da este consejo (traducido) para los aspirantes a
524
+
desarrolladores de kernel.
525
+
526
+
::
527
+
528
+
El proyecto #1 para los principiantes en el kernel seguramente debería
529
+
ser “asegúrese de que el kernel funcione perfectamente en todo momento
530
+
en todas las máquinas que pueda conseguir”. Por lo general, la forma
531
+
de hacer esto es trabajar con otros para arreglar las cosas (¡esto
532
+
puede requerir persistencia!), pero eso está bien, es parte del
533
+
desarrollo del kernel.
534
+
535
+
(https://lwn.net/Articles/283982/)
536
+
537
+
En ausencia de problemas obvios que solucionar, se aconseja a los
538
+
desarrolladores que consulten las listas actuales de regresiones y errores
539
+
abiertos en general. Nunca faltan problemas que necesitan solución; al
540
+
abordar estos problemas, los desarrolladores ganarán experiencia con el
541
+
proceso mientras, al mismo tiempo, se ganarán el respeto del resto de la
542
+
comunidad de desarrollo.