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/3.Early-stage.rst
Translate Documentation/process/3.Early-stage.rst into Spanish.
Co-developed-by: Avadhut Naik <avadhut.naik@amd.com>
Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
Signed-off-by: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20241129155851.1023884-2-carlos.bilbao.osdev@gmail.com
authored by
Carlos Bilbao
and committed by
Jonathan Corbet
42b5e1e2
e551bd41
+233
-2
+232
-2
Documentation/translations/sp_SP/process/3.Early-stage.rst
+232
-2
Documentation/translations/sp_SP/process/3.Early-stage.rst
···
1
1
.. include:: ../disclaimer-sp.rst
2
2
3
3
:Original: Documentation/process/3.Early-stage.rst
4
+
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com>
4
5
5
6
.. _sp_development_early_stage:
6
7
7
8
Planificación en etapa inicial
8
9
==============================
9
10
10
-
.. warning::
11
-
TODO aún no traducido
11
+
Cuando uno se sienta a planear un proyecto de desarrollo del kernel Linux,
12
+
puede ser tentador lanzarse directamente a escribir código. Sin embargo,
13
+
como ocurre con cualquier proyecto significativo, gran parte del trabajo
14
+
que conduce al éxito es mejor realizarlo antes de escribir la primera línea
15
+
de código. Dedicar tiempo a la planificación y comunicación temprana puede
16
+
ahorrar mucho más tiempo en adelante.
17
+
18
+
Especificar el problema
19
+
-----------------------
20
+
21
+
Como en cualquier proyecto de ingeniería, una mejora exitosa del kernel
22
+
comienza con una descripción clara del problema a resolver. En algunos
23
+
casos, este paso es sencillo: cuando se necesita un driver para un hardware
24
+
específico, por ejemplo. En otros, sin embargo, es tentador confundir el
25
+
problema real con la solución propuesta, lo que puede generar dificultades.
26
+
27
+
Consideremos un ejemplo: hace algunos años, los desarrolladores que
28
+
trabajaban con audio en Linux buscaban una forma de ejecutar aplicaciones
29
+
sin interrupciones u otros artefactos causados por la latencia excesiva en
30
+
el sistema. La solución a la que llegaron fue un módulo del kernel
31
+
destinado a integrarse en el marco del Módulo de Seguridad de Linux (LSM,
32
+
por sus siglas en inglés); este módulo podía configurarse para dar acceso a
33
+
aplicaciones específicas al planificador en tiempo real. Este módulo fue
34
+
implementado y enviado a la lista de correo del kernel de Linux, donde
35
+
inmediatamente encontró problemas.
36
+
37
+
Para los desarrolladores de audio, este módulo de seguridad era suficiente
38
+
para resolver su problema inmediato. Sin embargo, para la comunidad más
39
+
amplia del kernel, se veía como un uso indebido del marco LSM (que no está
40
+
diseñado para otorgar privilegios a procesos que de otro modo no los
41
+
tendrían) y como un riesgo para la estabilidad del sistema. Sus soluciones
42
+
preferidas implicaban el acceso a la programación en tiempo real a través
43
+
del mecanismo de rlimit a corto plazo, y trabajo continuo para reducir la
44
+
latencia a largo plazo.
45
+
46
+
La comunidad de audio, sin embargo, no podía ver más allá de la solución
47
+
particular que habían implementado; no estaban dispuestos a aceptar
48
+
alternativas. El desacuerdo resultante dejó a esos desarrolladores
49
+
desilusionados con todo el proceso de desarrollo del kernel; uno de ellos
50
+
volvió a una lista de audio y publicó esto (traducido):
51
+
52
+
"Hay un buen número de desarrolladores muy competentes del kernel de Linux, pero tienden a ser opacados por una multitud de arrogantes necios. Intentar comunicar los requisitos de los usuarios a estas personas es una pérdida de tiempo. Son demasiado 'inteligentes' como para escuchar a simples mortales".
53
+
54
+
Siendo el texto original:
55
+
56
+
There are a number of very good Linux kernel developers, but they
57
+
tend to get outshouted by a large crowd of arrogant fools. Trying
58
+
to communicate user requirements to these people is a waste of
59
+
time. They are much too "intelligent" to listen to lesser mortals.
60
+
61
+
(https://lwn.net/Articles/131776/).
62
+
63
+
La realidad de la situación era diferente; los desarrolladores del kernel
64
+
estaban mucho más preocupados por la estabilidad del sistema, el
65
+
mantenimiento a largo plazo y encontrar la solución correcta al problema
66
+
que por un módulo específico. La moraleja de la historia es centrarse en el
67
+
problema, no en una solución específica, y discutirlo con la comunidad de
68
+
desarrollo antes de invertir en la creación de un cuerpo de código.
69
+
70
+
Por lo tanto, al contemplar un proyecto de desarrollo del kernel, se deben
71
+
obtener respuestas a un conjunto corto de preguntas:
72
+
73
+
- ¿Cuál es exactamente el problema que necesita ser resuelto?
74
+
75
+
- ¿Quiénes son los usuarios afectados por este problema? ¿Qué casos de uso
76
+
debería abordar la solución?
77
+
78
+
- ¿En qué aspectos el kernel actual no logra abordar ese problema?
79
+
80
+
Solo entonces tiene sentido comenzar a considerar posibles soluciones.
81
+
82
+
Discusión temprana
83
+
------------------
84
+
85
+
Al planificar un proyecto de desarrollo del kernel, tiene mucho sentido
86
+
realizar discusiones con la comunidad antes de lanzarse a la
87
+
implementación. La comunicación temprana puede ahorrar tiempo y problemas
88
+
de varias maneras:
89
+
90
+
- Es posible que el problema ya esté siendo abordado por el kernel de
91
+
maneras que no haya comprendido. El kernel de Linux es grande y tiene
92
+
una serie de características y capacidades que no son inmediatamente
93
+
obvias. No todas las capacidades del kernel están documentadas tan bien
94
+
como uno quisiera, y es fácil pasar cosas por alto. El autor de este
95
+
texto ha visto la publicación de un driver completo que duplicaba uno
96
+
existente del que el nuevo autor no tenía conocimiento. El código que
97
+
reinventa ruedas existentes no solo es desperdicio; tampoco será aceptado
98
+
en el kernel principal.
99
+
100
+
- Puede haber elementos de la solución propuesta que no serán aceptables
101
+
para su inclusión en el kernel principal. Es mejor descubrir problemas
102
+
como este antes de escribir el código.
103
+
104
+
- Es completamente posible que otros desarrolladores ya hayan pensado en el
105
+
problema; pueden tener ideas para una mejor solución y estar dispuestos a
106
+
ayudar en la creación de esa solución.
107
+
108
+
Años de experiencia con la comunidad de desarrollo del kernel han enseñado
109
+
una lección clara: el código del kernel que se diseña y desarrolla a
110
+
puertas cerradas invariablemente tiene problemas que solo se revelan cuando
111
+
el código se libera a la comunidad. A veces, estos problemas son graves,
112
+
requiriendo meses o años de esfuerzo antes de que el código pueda cumplir
113
+
con los estándares de la comunidad del kernel. Algunos ejemplos incluyen:
114
+
115
+
- La pila de red Devicescape fue diseñada e implementada para sistemas de
116
+
un solo procesador. No pudo fusionarse en la rama principal hasta que se
117
+
hizo adecuada para sistemas multiprocesador. Adaptar el bloqueo y otros
118
+
aspectos en el código es una tarea difícil; como resultado, la fusión de
119
+
este código (ahora llamado mac80211) se retrasó más de un año.
120
+
121
+
- El sistema de archivos Reiser4 incluía una serie de capacidades que, en
122
+
opinión de los desarrolladores principales del kernel, deberían haberse
123
+
implementado en la capa de sistemas de archivos virtuales. También
124
+
incluía funciones que no podían implementarse fácilmente sin exponer el
125
+
sistema a bloqueos causados por los usuarios. La revelación tardía de
126
+
estos problemas, y la negativa a abordar algunos de ellos, ha mantenido a
127
+
Reiser4 fuera del kernel principal.
128
+
129
+
- El módulo de seguridad AppArmor hacía uso de estructuras de datos
130
+
internas del sistema de archivos virtual de maneras que se consideraban
131
+
inseguras y poco fiables. Esta preocupación (entre otras) mantuvo a
132
+
AppArmor fuera de la rama principal durante años.
133
+
134
+
En cada uno de estos casos, se podría haber evitado mucho dolor y trabajo
135
+
adicional con algunas discusiones tempranas con los desarrolladores del
136
+
kernel.
137
+
138
+
¿Con quién hablar?
139
+
-------------------
140
+
141
+
Cuando los desarrolladores deciden hacer públicas sus ideas, la siguiente
142
+
pregunta será: ¿dónde empezar? La respuesta es encontrar la lista de correo
143
+
adecuada y el maintainer correcto. Para las listas de correo, la mejor
144
+
opción es buscar en el archivo MAINTAINERS un lugar relevante para
145
+
publicar. Si existe una lista de subsistema adecuada, es preferible
146
+
publicarla allí en lugar de en linux-kernel; es más probable que llegues a
147
+
desarrolladores con experiencia en el subsistema relevante y el ambiente
148
+
puede ser más propicio.
149
+
150
+
Encontrar a los maintainers puede ser un poco más difícil. Nuevamente, el
151
+
archivo MAINTAINERS es el lugar para empezar. Sin embargo, ese archivo
152
+
tiende a no estar siempre actualizado, y no todos los subsistemas están
153
+
representados allí. La persona listada en el archivo MAINTAINERS puede, de
154
+
hecho, no ser la persona que está actuando en ese rol actualmente. Por lo
155
+
tanto, cuando haya dudas sobre a quién contactar, un truco útil es usar git
156
+
(y "git log" en particular) para ver quién está activo actualmente en el
157
+
subsistema de interés. Mira quién está escribiendo parches y quién, si
158
+
alguien, está adjuntando líneas de Signed-off-by a esos parches. Esas son
159
+
las personas que estarán mejor posicionadas para ayudar con un nuevo
160
+
proyecto de desarrollo.
161
+
162
+
La tarea de encontrar al maintainer correcto es lo suficientemente
163
+
desafiante como para que los desarrolladores del kernel hayan añadido un
164
+
script para facilitar el proceso:
165
+
166
+
::
167
+
168
+
.../scripts/get_maintainer.pl
169
+
170
+
Este script devolverá los maintainers actuales de un archivo o directorio
171
+
dado cuando se le pase la opción "-f". Si se le pasa un parche en la línea
172
+
de comandos, listará a los maintainers que probablemente deberían recibir
173
+
copias del parche. Esta es la manera preferida (a diferencia de la opción
174
+
"-f") de obtener la lista de personas a las que hay que enviar las copias
175
+
de sus parches. Hay varias opciones que regulan cuán agresivamente
176
+
get_maintainer.pl buscará maintainers; por favor, ten cuidado al usar las
177
+
opciones más agresivas, ya que podrías terminar incluyendo desarrolladores
178
+
que no tienen ningún interés real en el código que estás modificando.
179
+
180
+
Si todo lo demás falla, hablar con Andrew Morton puede ser una forma
181
+
efectiva de encontrar a un maintainer para un código específico.
182
+
183
+
¿Cuándo publicar?
184
+
------------------
185
+
186
+
Si es posible, publicar sus planes en las primeras etapas solo puede ser
187
+
útil. Describa el problema que se está resolviendo y cualquier plan que se
188
+
haya hecho sobre cómo se llevará a cabo la implementación. Cualquier
189
+
información que puedas proporcionar puede ayudar a la comunidad de
190
+
desarrollo a ofrecer comentarios útiles sobre el proyecto.
191
+
192
+
Una cosa desalentadora que puede suceder en esta etapa no es una reacción
193
+
hostil, sino, en cambio, poca o ninguna reacción en absoluto. La triste
194
+
realidad es que (1) los desarrolladores del kernel tienden a estar
195
+
ocupados, (2) no hay escasez de personas con grandes planes y poco código
196
+
(o incluso perspectivas de código) para respaldarlos, y (3) nadie está
197
+
obligado a revisar o comentar las ideas publicadas por otros. Además, los
198
+
diseños de alto nivel a menudo esconden problemas que solo se revelan
199
+
cuando alguien realmente intenta implementar esos diseños; por esa razón,
200
+
los desarrolladores del kernel prefieren ver el código.
201
+
202
+
Si una publicación de solicitud de comentarios genera pocos comentarios, no
203
+
asuma que significa que no hay interés en el proyecto. Desafortunadamente,
204
+
tampoco puedes asumir que no hay problemas con tu idea. Lo mejor que puede
205
+
hacer en esta situación es seguir adelante, manteniendo informada a
206
+
comunidad a medida que avanza.
207
+
208
+
Obtener respaldo oficial
209
+
------------------------
210
+
211
+
Si su trabajo se está realizando en un entorno corporativo — como ocurre
212
+
con la mayoría del trabajo en el kernel de Linux — es obvio que debe tener
213
+
permiso de los jefes debidamente autorizados antes de poder publicar los
214
+
planes o el código de su empresa en una lista de correo pública. La
215
+
publicación de código que no ha sido autorizado para su liberación bajo una
216
+
licencia compatible con la GPL puede ser especialmente problemática; cuanto
217
+
antes la gerencia y el personal legal de una empresa lleguen a un acuerdo
218
+
sobre la publicación de un proyecto de desarrollo del kernel, mejor será
219
+
para todos los involucrados.
220
+
221
+
Algunos lectores pueden estar pensando en este momento que su trabajo en el
222
+
kernel está destinado a respaldar un producto que aún no ha sido reconocido
223
+
oficialmente. Revelar los planes de su empleador en una lista de correo
224
+
pública puede no ser una opción viable. En casos como este, vale la pena
225
+
considerar si realmente es necesario mantener el secreto; a menudo no hay
226
+
una necesidad real de mantener los planes de desarrollo en secreto.
227
+
228
+
Dicho esto, también hay casos en los que una empresa legítimamente no puede
229
+
revelar sus planes al inicio del proceso de desarrollo. Las empresas con
230
+
desarrolladores experimentados en el kernel pueden optar por proceder de
231
+
manera abierta, bajo el supuesto de que podrán evitar problemas graves de
232
+
integración más adelante. Para las empresas sin ese tipo de experiencia
233
+
interna, la mejor opción suele ser contratar a un desarrollador externo
234
+
para que revise los planes bajo un acuerdo de confidencialidad (NDA). La
235
+
Linux Foundation opera un programa de NDA diseñado para ayudar en este tipo
236
+
de situaciones; se puede encontrar más información en:
237
+
238
+
https://www.linuxfoundation.org/nda/
239
+
240
+
Este tipo de revisión suele ser suficiente para evitar problemas graves más
241
+
adelante sin necesidad de revelar públicamente el proyecto.