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/6.Followthrough.rst
Translate Documentation/process/6.Followthrough.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-5-carlos.bilbao.osdev@gmail.com
authored by
Carlos Bilbao
and committed by
Jonathan Corbet
6422b065
08c42f22
+222
-2
+221
-2
Documentation/translations/sp_SP/process/6.Followthrough.rst
+221
-2
Documentation/translations/sp_SP/process/6.Followthrough.rst
···
1
1
.. include:: ../disclaimer-sp.rst
2
2
3
3
:Original: Documentation/process/6.Followthrough.rst
4
+
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com>
4
5
5
6
.. _sp_development_followthrough:
6
7
7
8
Seguimiento
8
9
===========
9
10
10
-
.. warning::
11
-
TODO aún no traducido
11
+
Llegados a este punto, ha seguido las directrices dadas hasta ahora, lo que
12
+
sumado a sus propias habilidades de ingeniería, ha resultado en una serie
13
+
de parches perfectos. Uno de los mayores errores que incluso los
14
+
desarrolladores de kernel experimentados pueden cometer es concluir que su
15
+
trabajo ya está hecho. En verdad, publicar parches indica una transición a
16
+
la siguiente etapa del proceso, con, posiblemente, bastante trabajo aún por
17
+
hacer.
18
+
19
+
Es raro un parche que sea tan bueno en su primera publicación que no haya
20
+
espacio para la mejora. El proceso de desarrollo del kernel reconoce este
21
+
hecho y, como resultado, está muy orientado hacia la mejora del código
22
+
publicado. Y usted, como autor de ese código, se espera que trabaje con la
23
+
comunidad del kernel para asegurarse de que su código esté a la altura de
24
+
los estándares de calidad del kernel. No participar en este proceso es muy
25
+
probable que impida la inclusión de sus parches en la línea principal.
26
+
27
+
Trabajando con revisores
28
+
------------------------
29
+
30
+
Un parche de cualquier importancia resultará en una serie de comentarios de
31
+
otros desarrolladores a medida que revisan el código. Trabajar con los
32
+
revisores puede ser, para muchos desarrolladores, la parte más intimidante
33
+
del proceso de desarrollo del kernel. Sin embargo, la vida puede ser mucho
34
+
más fácil si tiene en cuenta algunas cosas:
35
+
36
+
- Si ha explicado bien su parche, los revisores entenderán su valor y por
37
+
qué se tomó la molestia de escribirlo. Pero ese valor no les impedirá
38
+
hacer una pregunta fundamental: ¿cómo será mantener un kernel con este
39
+
código en él cinco o diez años después? Muchos de los cambios que se le
40
+
pueden pedir que haga, desde ajustes de estilo de codificación hasta
41
+
reescrituras sustanciales, provienen de la comprensión de que Linux
42
+
seguirá existiendo y en desarrollo dentro de una década.
43
+
44
+
- La revisión de código es un trabajo arduo y es una ocupación
45
+
relativamente ingrata; la gente recuerda quién escribió el código del
46
+
kernel, pero hay poca fama duradera para aquellos que lo revisaron. Así
47
+
que los revisores pueden ponerse de mal humor, especialmente cuando ven
48
+
los mismos errores repetirse una y otra vez. Si recibe una revisión que
49
+
parece enojada, insultante o abiertamente ofensiva, resista el impulso de
50
+
responder de la misma manera. La revisión de código se trata del código,
51
+
no de las personas, y los revisores de código no lo están atacando
52
+
personalmente.
53
+
54
+
- De manera similar, los revisores de código no están tratando de promover
55
+
las agendas de sus empleadores a expensas de la suya. Los desarrolladores
56
+
del kernel a menudo esperan estar trabajando en el kernel dentro de
57
+
varios años, pero entienden que su empleador podría cambiar.
58
+
Verdaderamente, casi sin excepción, están trabajando hacia la creación
59
+
del mejor kernel posible; no están tratando de causar incomodidad a los
60
+
competidores de sus empleadores.
61
+
62
+
- Esté preparado para solicitudes aparentemente ridículas de cambios en el
63
+
estilo de codificación y solicitudes para factorizar parte de su código
64
+
en partes compartidas del kernel. Una de las tareas que realizan los
65
+
maintainers es mantener las cosas con una apariencia uniforme. A veces, esto significa que el truco ingenioso en su driver para sortear un problema necesita convertirse en una característica generalizada del kernel lista para la próxima vez.
66
+
67
+
En resumen, cuando los revisores le envían comentarios, necesita prestar
68
+
atención a las observaciones técnicas que están haciendo. No permita que su
69
+
forma de expresarse o su propio orgullo le impidan hacerlo. Cuando reciba
70
+
comentarios de revisión sobre un parche, tómese el tiempo para entender lo
71
+
que el revisor está tratando de decir. Si es posible, arregle las cosas que
72
+
el revisor le está pidiendo que corrija. Y responda al revisor:
73
+
agradézcales y describa cómo responderá a sus preguntas.
74
+
75
+
Tenga en cuenta que no tiene que estar de acuerdo con cada cambio sugerido
76
+
por los revisores. Si cree que el revisor ha malinterpretado su código,
77
+
explique lo que realmente está sucediendo. Si tiene una objeción técnica a
78
+
un cambio sugerido, descríbalo y justifique su solución al problema. Si sus
79
+
explicaciones tienen sentido, el revisor las aceptará. Sin embargo, si su
80
+
explicación no resulta persuasiva, especialmente si otros comienzan a estar
81
+
de acuerdo con el revisor, tómese un tiempo para reflexionar nuevamente
82
+
sobre las cosas. Puede ser fácil quedar cegado por su propia solución a un
83
+
problema hasta el punto de no darse cuenta de que algo está
84
+
fundamentalmente mal o, quizás, ni siquiera está resolviendo el problema
85
+
correcto.
86
+
87
+
Andrew Morton ha sugerido que cada comentario de revisión que no resulte en
88
+
un cambio de código debería resultar en un comentario adicional en el
89
+
código; eso puede ayudar a los revisores futuros a evitar las preguntas que
90
+
surgieron la primera vez.
91
+
92
+
Un error fatal es ignorar los comentarios de revisión con la esperanza de
93
+
que desaparezcan. No desaparecerán. Si vuelve a publicar código sin haber
94
+
respondido a los comentarios que recibió la vez anterior, es probable que
95
+
descubra que sus parches no van a ninguna parte.
96
+
97
+
Hablando de volver a publicar código: tenga en cuenta que los revisores no
98
+
recordarán todos los detalles del código que publicó la vez anterior. Así
99
+
que siempre es una buena idea recordarles sobre problemas planteados
100
+
anteriormente y cómo los manejó; el registro de cambios del parche es un
101
+
buen lugar para este tipo de información. Los revisores no deberían tener
102
+
que buscar en los archivos de la lista para familiarizarse con lo que se
103
+
dijo la última vez; si les ayuda a tener un buen comienzo, estarán de mejor
104
+
humor cuando revisiten su código.
105
+
106
+
¿Qué sucede si ha intentado hacer todo bien y las cosas aún no van a
107
+
ninguna parte? La mayoría de los desacuerdos técnicos pueden resolverse
108
+
mediante discusión, pero hay momentos en los que alguien simplemente tiene
109
+
que tomar una decisión. Si realmente cree que esta decisión está en su
110
+
contra de manera incorrecta, siempre puede intentar apelar a una autoridad
111
+
superior. En el momento de escribir esto, esa autoridad superior tiende a
112
+
ser Andrew Morton. Andrew tiene un gran respeto en la comunidad de
113
+
desarrollo del kernel; a menudo puede desbloquear una situación que parece
114
+
estar irremediablemente bloqueada. Sin embargo, apelar a Andrew no debe
115
+
hacerse a la ligera, y no antes de que se hayan explorado todas las demás
116
+
alternativas. Y tenga en cuenta, por supuesto, que él puede no estar de
117
+
acuerdo con usted tampoco.
118
+
119
+
¿Qué pasa después?
120
+
--------------------
121
+
122
+
Si un parche se considera algo bueno para agregar al kernel, y una vez que
123
+
se hayan resuelto la mayoría de los problemas de revisión, el siguiente
124
+
paso suele ser la entrada en el árbol del mantenedor de un subsistema. Cómo
125
+
funciona eso varía de un subsistema a otro; cada mantenedor tiene su propia
126
+
forma de hacer las cosas. En particular, puede haber más de un árbol, uno,
127
+
quizás, dedicado a los parches planificados para la próxima ventana de
128
+
fusión y otro para trabajos a más largo plazo.
129
+
130
+
Para los parches que se aplican a áreas para las que no hay un árbol de
131
+
subsistema obvio (parches de gestión de memoria, por ejemplo), el árbol
132
+
predeterminado suele ser -mm. Los parches que afectan a múltiples
133
+
subsistemas también pueden terminar pasando por el árbol -mm.
134
+
135
+
La inclusión en un árbol de subsistema puede dar mayor visibilidad a un
136
+
parche. Ahora, otros desarrolladores que trabajan con ese árbol recibirán
137
+
el parche por defecto. Los árboles de subsistemas típicamente alimentan
138
+
linux-next también, haciendo que su contenido sea visible para la comunidad
139
+
de desarrollo en su conjunto. En este punto, hay una buena probabilidad de
140
+
que reciba más comentarios de un nuevo conjunto de revisores; estos
141
+
comentarios necesitan ser respondidos como en la ronda anterior.
142
+
143
+
Lo que también puede suceder en este punto, dependiendo de la naturaleza de
144
+
su parche, es que aparezcan conflictos con el trabajo que están realizando
145
+
otros. En el peor de los casos, conflictos pesados de parches pueden
146
+
resultar en que algunos trabajos se pongan en espera para que los parches
147
+
restantes puedan ser ajustados y fusionados. Otras veces, la resolución de
148
+
conflictos involucrará trabajar con otros desarrolladores y, posiblemente,
149
+
mover algunos parches entre árboles para asegurarse de que todo se aplique
150
+
sin problemas. Este trabajo puede ser un dolor, pero cuente sus
151
+
bendiciones: antes de la llegada del árbol linux-next, estos conflictos a
152
+
menudo solo surgían durante la ventana de fusión y tenían que ser abordados
153
+
de prisa. Ahora pueden resolverse con calma, antes de que se abra la
154
+
ventana de fusión (merge window).
155
+
156
+
Algún día, si todo va bien, iniciará sesión y verá que su parche ha sido
157
+
incluido en el kernel principal. ¡Felicidades! Una vez que la celebración
158
+
termine (y se hayas agregado al archivo MAINTAINERS), vale la pena
159
+
recordar un pequeño hecho importante: el trabajo aún no está hecho. La
160
+
inclusión trae sus propios desafíos.
161
+
162
+
Para empezar, la visibilidad de su parche ha aumentado una vez más. Puede
163
+
haber una nueva ronda de comentarios de desarrolladores que no estaban al
164
+
tanto del parche antes. Puede ser tentador ignorarlos, ya que ya no hay
165
+
cuestión de que su código sea fusionado. Sin embargo, resista esa
166
+
tentación; aún necesita ser receptivo a los desarrolladores que tienen
167
+
preguntas o sugerencias.
168
+
169
+
Más importante aún, la inclusión en la línea principal pone su código en
170
+
manos de un grupo mucho más grande de probadores. Incluso si ha contribuido
171
+
un driver para hardware que aún no está disponible, se sorprenderá de
172
+
cuántas personas construirán su código en sus kernels. Y, por supuesto,
173
+
donde hay probadores, habrá informes de errores.
174
+
175
+
El peor tipo de informes de errores son las regresiones. Si su parche causa
176
+
una regresión, encontrará un número incómodo de ojos sobre usted; las
177
+
regresiones pueden dar lugar a mucho malestar en la comunidad y pueden
178
+
hacer que algunos desarrolladores comiencen a preguntarse si su parche
179
+
realmente debería haber sido fusionado en primer lugar. Así que esté atento
180
+
a los comentarios sobre problemas y, si es posible, corrija los errores de
181
+
inmediato.
182
+
183
+
Después de haber abordado cualquier regresión, puede haber otros errores
184
+
ordinarios que resolver. El período de estabilización es su mejor
185
+
oportunidad para corregir estos errores y garantizar que el debut de su
186
+
código en una versión del kernel principal sea lo más sólido posible. Así
187
+
que, por favor, responda a los informes de errores y solucione los
188
+
problemas si es posible. Para eso es el período de estabilización; puede
189
+
comenzar a crear parches nuevos y geniales una vez que se hayan resuelto
190
+
los problemas de los antiguos.
191
+
192
+
Y no olvide que hay otros hitos que también pueden generar informes de
193
+
errores: la próxima versión estable del kernel principal, cuando
194
+
distribuidores prominentes adopten una versión del kernel que contenga su
195
+
parche, etc. Continuar respondiendo a estos informes es una cuestión de
196
+
orgullo básico en su trabajo. Sin embargo, si eso no es suficiente
197
+
motivación, también vale la pena considerar que la comunidad de desarrollo
198
+
recuerda a los desarrolladores que pierden interés en su código después de
199
+
que se fusiona. La próxima vez que publique un parche, lo evaluarán con la
200
+
suposición de que no estará disponible para mantenerlo después.
201
+
202
+
Otras cosas que pueden suceder
203
+
-------------------------------
204
+
205
+
Un día, puede que abra su cliente de correo y vea que alguien le ha enviado
206
+
un parche para su código. Esa es una de las ventajas de tener su código
207
+
disponible públicamente, después de todo. Si está de acuerdo con el parche, puede reenviarlo al maintainer del subsistema (asegúrese de incluir una
208
+
línea From: adecuada para que la atribución sea correcta, y añada su propia
209
+
firma), o enviar una respuesta Acked-by: y dejar que el autor original lo
210
+
envíe hacia arriba.
211
+
212
+
Si no está de acuerdo con el parche, envíe una respuesta educada explicando
213
+
por qué. Si es posible, dígale al autor qué cambios deben hacerse para que
214
+
considere el parche aceptable. Existe una cierta resistencia a incluir
215
+
parches que son rechazados por el autor y el maintainer del código, pero
216
+
esto tiene un límite. Si se interpreta que bloque buen trabajo, esos
217
+
parches eventualmente lo eludirán y se incorporarán al kernel de todos
218
+
modos. En el kernel de Linux, nadie tiene poder de veto absoluto sobre
219
+
ningún código. Excepto quizás Linus.
220
+
221
+
En muy raras ocasiones, puede encontrar algo completamente diferente: otro
222
+
desarrollador publica una solución distinta a su problema. En ese punto, es
223
+
probable que uno de los dos parches no se incluya, y "el mío fue el
224
+
primero" no se considera un argumento técnico convincente. Si el parche de
225
+
otra persona desplaza al suyo y se incorpora al kernel, realmente solo hay
226
+
una manera de responder: alegrarse de que su problema se haya resuelto y
227
+
continuar con su trabajo. Que su trabajo sea desplazado de esta manera
228
+
puede ser doloroso y desalentador, pero la comunidad recordará su reacción
229
+
mucho después de que hayan olvidado de quién era el parche que realmente se
230
+
incluyó.