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/handling-regressions
Translate Documentation/process/handling-regressions.rst into Spanish.
Co-developed-by: Sergio Gonzalez <sergio.collado@gmail.com>
Signed-off-by: Sergio Gonzalez <sergio.collado@gmail.com>
Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20231031151325.2903088-1-carlos.bilbao@amd.com>
authored by
Carlos Bilbao
and committed by
Jonathan Corbet
ed23b1b2
b85ea95d
+798
+797
Documentation/translations/sp_SP/process/handling-regressions.rst
+797
Documentation/translations/sp_SP/process/handling-regressions.rst
···
1
+
.. include:: ../disclaimer-sp.rst
2
+
3
+
:Translator: Sergio González Collado <sergio.collado@gmail.com>
4
+
5
+
.. _sp_handling_regressions:
6
+
7
+
Gestión de regresiones
8
+
++++++++++++++++++++++
9
+
10
+
*No causamos regresiones* -- este documento describe la que es la "primera
11
+
regla del desarrollo del kernel de Linux" y que implica en la práctica para
12
+
los desarrolladores. Y complementa la documentación:
13
+
Documentation/admin-guide/reporting-regressions.rst, que cubre el tema
14
+
desde el punto de vista de un usuario; si nunca ha leído ese texto, realice
15
+
al menos una lectura rápida del mismo antes de continuar.
16
+
17
+
Las partes importantes (el "TL;DR")
18
+
===================================
19
+
20
+
#. Asegúrese de que los suscriptores a la lista `regression mailing list
21
+
<https://lore.kernel.org/regressions/>`_ (regressions@lists.linux.dev)
22
+
son conocedores con rapidez de cualquier nuevo informe de regresión:
23
+
24
+
* Cuando se reciba un correo que no incluyó a la lista, inclúyalo en la
25
+
conversación de los correos, mandando un breve "Reply-all" con la
26
+
lista en CCed.
27
+
28
+
* Mande o redirija cualquier informe originado en los gestores de bugs
29
+
a la lista.
30
+
31
+
#. Haga que el bot del kernel de Linux "regzbot" realice el seguimiento del
32
+
incidente (esto es opcional, pero recomendado).
33
+
34
+
* Para reportes enviados por correo, verificar si contiene alguna línea
35
+
como ``#regzbot introduced v5.13..v5.14-rc1``. Si no, mandar una
36
+
respuesta (con la lista de regresiones en CC) que contenga un párrafo
37
+
como el siguiente, lo que le indica a regzbot cuando empezó a suceder
38
+
el incidente::
39
+
40
+
#regzbot ^introduced 1f2e3d4c5b6a
41
+
42
+
* Cuando se mandan informes desde un gestor de incidentes a la lista de
43
+
regresiones(ver más arriba), incluir un párrafo como el siguiente::
44
+
45
+
#regzbot introduced: v5.13..v5.14-rc1
46
+
#regzbot from: Some N. Ice Human <some.human@example.com>
47
+
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
48
+
49
+
#. Cuando se manden correcciones para las regresiones, añadir etiquetas
50
+
"Link:" a la descripción, apuntado a todos los sitios donde se informó
51
+
del incidente, como se indica en el documento:
52
+
Documentation/process/submitting-patches.rst y
53
+
:ref:`Documentation/process/5.Posting.rst <development_posting>`.
54
+
55
+
#. Intente arreglar las regresiones rápidamente una vez la causa haya sido
56
+
identificada; las correcciones para la mayor parte de las regresiones
57
+
deberían ser integradas en menos de dos semanas, pero algunas pueden
58
+
resolverse en dos o tres días.
59
+
60
+
Detalles importantes para desarrolladores en la regresiones de kernel de Linux
61
+
==============================================================================
62
+
63
+
Puntos básicos importantes más en detalle
64
+
-----------------------------------------
65
+
66
+
Qué hacer cuando se recibe un aviso de regresión.
67
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
68
+
69
+
Asegúrese de que el programa de gestión de regresiones del kernel de Linux
70
+
y los subscritos a la lista de correo `regression mailing list
71
+
<https://lore.kernel.org/regressions/>`_ (regressions@lists.linux.dev) son
72
+
conocedores de cualquier nuevo informe de regresión:
73
+
74
+
* Cuando se recibe un informe por email que no tiene en CC la lista,
75
+
inmediatamente meterla en el la cadena de emails mandado al menos un
76
+
breve "Reply-all" con la lista en CC; Intentar asegurar que la lista es
77
+
añadida en CC de nuevo en caso de que alguna respuesta la omita de la
78
+
lista.
79
+
80
+
* Si un informe enviado a un gestor de defectos, llega a su correo,
81
+
reenvíelo o redirijalo a la lista. Considere verificar los archivos de
82
+
la lista de antemano, si la persona que lo ha informado, lo ha enviado
83
+
anteriormente, como se indica en:
84
+
Documentation/admin-guide/reporting-issues.rst.
85
+
86
+
Cuando se realice cualquiera de las acciones anteriores, considere
87
+
inmediatamente iniciar el seguimiento de la regresión con "regzbot" el
88
+
gestor de regresiones del kernel de Linux.
89
+
90
+
* Para los informes enviados por email, verificar si se ha incluido un
91
+
comando a "regzbot", como ``#regzbot introduced 1f2e3d4c5b6a``. Si no es
92
+
así, envíe una respuesta (con la lista de regresiones en CC) con un
93
+
párrafo como el siguiente::
94
+
95
+
#regzbot ^introduced: v5.13..v5.14-rc1
96
+
97
+
Esto indica a regzbot el rango de versiones en el cual es defecto
98
+
comenzó a suceder; Puede especificar un rango usando los identificadores
99
+
de los commits así como un único commit, en caso en el que el informante
100
+
haya identificado el commit causante con 'bisect'.
101
+
102
+
Tenga en cuenta que el acento circunflejo (^) antes de "introduced":
103
+
Esto indica a regzbot, que debe tratar el email padre (el que ha sido
104
+
respondido) como el informeinicial para la regresión que quiere ser
105
+
seguida. Esto es importante, ya que regzbot buscará más tarde parches
106
+
con etiquetas "Link:" que apunten al al informe de losarchivos de
107
+
lore.kernel.org.
108
+
109
+
* Cuando mande informes de regresiones a un gestor de defectos, incluya un
110
+
párrafo con los siguientes comandos a regzbot::
111
+
112
+
#regzbot introduced: 1f2e3d4c5b6a
113
+
#regzbot from: Some N. Ice Human <some.human@example.com>
114
+
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
115
+
116
+
Regzbot asociará automáticamente parches con el informe que contengan
117
+
las etiquetas "Link:" apuntando a su email o el ticket indicado.
118
+
119
+
Qué es importante cuando se corrigen regresiones
120
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
121
+
122
+
No se necesita hacer nada especial cuando se mandan las correcciones para
123
+
las regresiones únicamente recordar lo que se explica en los documentos:
124
+
Documentation/process/submitting-patches.rst,
125
+
:ref:`Documentation/process/5.Posting.rst <development_posting>`, y
126
+
Documentation/process/stable-kernel-rules.rst
127
+
128
+
* Apunte a todos los lugares donde el incidente se reportó usando la
129
+
etiqueta "Link:" ::
130
+
131
+
Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
132
+
Link: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890
133
+
134
+
* Añada la etiqueta "Fixes:" para indicar el commit causante de la
135
+
regresión.
136
+
137
+
* Si el culpable ha sido "mergeado" en un ciclo de desarrollo anterior,
138
+
marque explícitamente el fix para retro-importarlo usando la etiqueta
139
+
``Cc: stable@vger.kernel.org`` tag.
140
+
141
+
Todo esto se espera y es importante en una regresión, ya que estas
142
+
etiquetas son de gran valor para todos (incluido usted) que pueda estar
143
+
mirando en ese incidente semanas, meses o años después. Estas etiquetas son
144
+
también cruciales para las herramientas y scripts usados por otros
145
+
desarrolladores del kernel o distribuciones de Linux; una de esas
146
+
herramientas es regzbot, el cual depende mucho de las etiquetas "Link:"
147
+
para asociar los informes por regresiones con los cambios que las
148
+
resuelven.
149
+
150
+
151
+
Priorización del trabajo en arreglar regresiones
152
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
153
+
154
+
Al final, los desarrolladores deberían hacer lo posible para evitar a los
155
+
usuarios situaciones donde una regresión les deje solo tres opciones:
156
+
157
+
* Ejecutar el kernel con una regresión que afecta seriamente al uso.
158
+
159
+
* Cambiar a un kernel nuevo o mas antiguo -- rebajarse a una versión
160
+
soportada del kernel que no tenga las funcionalidades requeridas.
161
+
162
+
* Continuar ejecutando una versión desfasada y potencialmente insegura del
163
+
kernel por más de dos semanas después de que el causante de una regresión
164
+
fuese identificado.
165
+
166
+
Cómo se ejecuta esto depende mucho de la situación. A continuación se
167
+
presentan unas reglas generales, en orden de importancia:
168
+
169
+
* Priorice el trabajo en la gestión de los informes de la regresión y
170
+
arreglar la regresión por encima de cualquier otro trabajo en el kernel
171
+
de Linux, a menos que lo último afecte profundamente a efectos de
172
+
seguridad, o cause errores en los que haya pérdida o daño de datos.
173
+
174
+
* Considere siempre revertir los commits responsables y re-aplicarlos
175
+
después, junto con las correcciones necesarias, ya que esto puede la
176
+
forma menos peligrosa y más rápida de arreglar la regresión.
177
+
178
+
* Los desarrolladores deberían gestionar la regresión en todos los kernels
179
+
soportados de la serie, pero son libres de delegar el trabajo al equipo
180
+
permanente el incidente no hubiese ocurrido en la línea principal.
181
+
182
+
* Intente resolver cualquier regresión que apareciera en el ciclo de
183
+
desarrollo antes de que este acabe. Si se teme que una corrección
184
+
pudiera ser demasiado arriesgada para aplicarla días antes de una
185
+
liberación de la línea principal de desarrollo, dejar decidir a Linus:
186
+
mande la corrección a él de forma separada, tan pronto como sea posible
187
+
con una explicación de la situación. El podrá decidir, y posponer la
188
+
liberación si fuese necesario, por ejemplo si aparecieran múltiples
189
+
cambios como ese.
190
+
191
+
* Gestione las regresiones en la rama estable, de largo término, o la
192
+
propia rama principal de las versiones, con más urgencia que la
193
+
regresiones en las preliberaciones. Esto cambia después de la liberación
194
+
de la quinta pre-liberación, aka "-rc5": la rama principal entonces se
195
+
vuelve más importante, asegurar que todas las mejoras y correcciones son
196
+
idealmente testeados juntos por al menos una semana antes de que Linux
197
+
libere la nueva versión en la rama principal.
198
+
199
+
* Intente arreglar regresiones en un intervalo de una semana después de
200
+
que se ha identificado el responsable, si el incidente fue introducido
201
+
en alguno de los siguientes casos:
202
+
203
+
* una versión estable/largo-plazo reciente
204
+
205
+
* en el último ciclo de desarrollo de la rama principal
206
+
207
+
En el último caso (por ejemplo v5.14), intentar gestionar las
208
+
regresiones incluso más rápido, si la versión estable precedente (v5.13)
209
+
ha de ser abandonada pronto o ya se ha etiquetado como de final de vida
210
+
(EOL de las siglas en inglés End-of-Life) -- esto sucede usualmente
211
+
sobre tres o cuatro semanas después de una liberación de una versión en
212
+
la rama principal.
213
+
214
+
* Intente arreglar cualquier otra regresión en un periodo de dos semanas
215
+
después de que el culpable haya sido identificado. Dos o tres semanas
216
+
adicionales son aceptables para regresiones de rendimiento y otros
217
+
incidentes que son molestos, pero no bloquean a nadie la ejecución de
218
+
Linux (a menos que se un incidente en el ciclo de desarrollo actual, en
219
+
ese caso se debería gestionar antes de la liberación de la versión).
220
+
Unas semanas son aceptables si la regresión únicamente puede ser
221
+
arreglada con un cambio arriesgado y al mismo tiempo únicamente afecta a
222
+
unos pocos usuarios; también está bien si se usa tanto tiempo como fuera
223
+
necesario si la regresión está presente en la segunda versión más nueva
224
+
de largo plazo del kernel.
225
+
226
+
Nota: Los intervalos de tiempo mencionados anteriormente para la resolución
227
+
de las regresiones, incluyen la verificación de esta, revisión e inclusión
228
+
en la rama principal, idealmente con la corrección incluida en la rama
229
+
"linux-next" al menos brevemente. Esto conllevará retrasos que también se
230
+
tienen tener en cuenta.
231
+
232
+
Se espera que los maintainers de los subsistemas, ayuden en conseguir esos
233
+
tiempos, haciendo revisiones con prontitud y gestionando con rapidez los
234
+
parches aceptados. Esto puede resultar en tener que mandar peticiones de
235
+
git-pull antes o de forma más frecuente que lo normal; dependiendo del
236
+
arreglo, podría incluso ser aceptable saltarse la verificación en
237
+
linux-next. Especialmente para las correcciones en las ramas de los kernels
238
+
estable y de largo plazo necesitan ser gestionadas rápidamente, y las
239
+
correcciones necesitan ser incluidas en la rama principal antes de que
240
+
puedan ser incluidas posteriormente a las series precedentes.
241
+
242
+
243
+
Más aspectos sobre regresiones que los desarrolladores deben saber
244
+
------------------------------------------------------------------
245
+
246
+
Cómo tratar con cambios donde se sabe que hay riesgo de regresión
247
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
248
+
249
+
Evalué cómo de grande es el riesgo de una regresión, por ejemplo realizando
250
+
una búsqueda en las distribuciones de linux y en Git forges. Considere
251
+
también preguntar a otros desarrolladores o proyectos que pudieran ser
252
+
afectados para evaluar o incluso testear el cambio propuesto; si
253
+
apareciesen problemas, quizás se pudiera encontrar una solución aceptable
254
+
para todos.
255
+
256
+
Si al final, el riesgo de la regresión parece ser relativamente pequeño,
257
+
entonces adelante con el cambio, pero siempre informe a todas las partes
258
+
involucradas del posible riesgo. Por tanto, asegúrese de que la descripción
259
+
del parche, se hace explícito este hecho. Una vez el cambio ha sido
260
+
integrado, informe al gestor de regresiones de Linux y a las listas de
261
+
correo de regresiones sobre el riesgo, de manera que cualquiera que tenga
262
+
el cambio en el radar, en el caso de que aparezcan reportes. Dependiendo
263
+
del riesgo, quizás se quiera preguntar al mantenedor del subsistema, que
264
+
mencione el hecho en su línea principal de desarrollo.
265
+
266
+
¿Qué más hay que saber sobre regresiones?
267
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
268
+
269
+
Repase la documentación: Documentation/admin-guide/reporting-regressions.rst,
270
+
esta cubre otros aspectos a tener a en cuenta y conocer:
271
+
272
+
* la finalidad de la "regla de no regresión"
273
+
274
+
* qué incidencias no se califican como regresión
275
+
276
+
* quién es el responsable de identificar la causa raíz de una regresión
277
+
278
+
* cómo gestionar situaciones difíciles, como por ejemplo cuando una
279
+
regresión es causada por una corrección de seguridad o cuando una
280
+
regresión causa otra regresión
281
+
282
+
A quién preguntar por consejo cuando se trata de regresiones
283
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
284
+
285
+
Mande un email a la lista de correo de regresiones
286
+
(regressions@lists.linux.dev) y CC al seguidor de regresiones del kernel de
287
+
Linux (regressions@leemhuis.info); Si el incidente pudiera ser mejor
288
+
gestionarlo en privado, puede omitirse la lista.
289
+
290
+
291
+
Más sobre la gestión de regresiones con regzbot
292
+
-----------------------------------------------
293
+
294
+
¿Por qué el kernel de Linux tiene un gestor de regresiones, y por qué se usa regzbot?
295
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
296
+
297
+
Reglas como "no regresiones" necesitan asegurar que se cumplen, de otro
298
+
modo se romperían accidentalmente o a propósito. La historia ha mostrado
299
+
que esto es verdad también para el kernel de Linux. Esto es por lo que
300
+
Thorsten Leemhuis se ofreció como voluntario para dar una solución a esto,
301
+
con el gestor de regresiones del kernel de Linux. A nadie se le paga por
302
+
hacer esto, y esa es la razón por la gestión de regresiones es un servicio
303
+
con el "mejor esfuerzo".
304
+
305
+
Intentos iniciales de gestionar manualmente las regresiones han demostrado
306
+
que es una tarea extenuante y frustrante, y por esa razón se dejaron de
307
+
hacer después de un tiempo. Para evitar que volviese a suceder esto,
308
+
Thorsten desarrollo regbot para facilitar el trabajo, con el objetivo a
309
+
largo plazo de automatizar la gestión de regresiones tanto como fuese
310
+
posible para cualquiera que estuviese involucrado.
311
+
312
+
¿Cómo funciona el seguimiento de regresiones con regzbot?
313
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
314
+
315
+
El bot monitoriza las respuestas de los informes de las regresiones
316
+
identificadas. Adicionalmente mira si se han publicado o enviado parches
317
+
que hagan referencia a esos informes con la etiqueta: "Link:"; respuestas a
318
+
esos parches también se siguen. Combinando esta información, también
319
+
proporciona una buena imagen del estado actual del proceso de corrección.
320
+
321
+
Regzbot intenta hacer todo este trabajo con tan poco retraso como sea
322
+
posible tanto para la gente que lo reporta, como para los desarrolladores.
323
+
De hecho, solo los informantes son requeridos para una tarea adicional:
324
+
necesitan informar a regzbot con el comando ``#regzbot introduced``
325
+
indicado anteriormente; si no hacen esto, alguien más puede hacerlo usando
326
+
``#regzbot ^introduced``.
327
+
328
+
Para los desarrolladores normalmente no hay un trabajo adicional que
329
+
realizar, únicamente necesitan asegurarse una cosa, que ya se hacía mucho
330
+
antes de que regzbot apareciera: añadir las etiquetas "Link:" a la
331
+
descripción del parche apuntando a todos los informes sobre el error
332
+
corregido.
333
+
334
+
¿Tengo que usar regzbot?
335
+
~~~~~~~~~~~~~~~~~~~~~~~~
336
+
337
+
Hacerlo es por el bien de todo el mundo, tanto los mantenedores del kernel,
338
+
como Linus Torvalds dependen parcialmente en regzbot para seguir su trabajo
339
+
-- por ejemplo cuando deciden liberar una nueva versión o ampliar la fase de
340
+
desarrollo. Para esto necesitan conocer todas las regresiones que están sin
341
+
corregir; para esto, es conocido que Linux mira los informes semanales que
342
+
manda regzbot.
343
+
344
+
¿He de informar a regzbot cada regresión que encuentre?
345
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
346
+
347
+
Idealmente, sí: todos somos humanos y olvidamos fácilmente los problemas
348
+
cuando algo más importante aparece inesperadamente -- por ejemplo un
349
+
problema mayor en el kernel de Linux o algo en la vida real que nos mantenga
350
+
alejados de los teclados por un tiempo. Por eso es mejor informar a regzbot
351
+
sobre cada regresión, excepto cuando inmediatamente escribimos un parche y
352
+
los mandamos al árbol de desarrollo en el que se integran habitualmente a
353
+
la serie del kernel.
354
+
355
+
¿Cómo ver qué regresiones esta siguiendo regbot actualmente?
356
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
357
+
358
+
Verifique el `interfaz web de regzbot <https://linux-regtracking.leemhuis.info/regzbot/>`_
359
+
para ver la última información; o `busque el último informe de regresiones
360
+
<https://lore.kernel.org/lkml/?q=%22Linux+regressions+report%22+f%3Aregzbot>`_,
361
+
el cual suele ser enviado por regzbot una vez a la semana el domingo por la
362
+
noche (UTC), lo cual es unas horas antes de que Linus normalmente anuncie
363
+
las "(pre-)releases".
364
+
365
+
¿Qué sitios supervisa regzbot?
366
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
367
+
368
+
Regzbot supervisa las listas de correo más importantes de Linux, como
369
+
también las de los repositorios linux-next, mainline y stable/longterm.
370
+
371
+
372
+
¿Qué tipos de incidentes han de ser monitorizados por regzbot?
373
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
374
+
El bot debe hacer seguimiento de las regresiones, y por tanto por favor,
375
+
no involucre a regzbot para incidencias normales. Pero es correcto para
376
+
el gestor de incidencias de kernel de Linux, monitorizar incidentes
377
+
graves, como informes sobre cuelgues, corrupción de datos o errores
378
+
internos (Panic, Oops, BUG(), warning, ...).
379
+
380
+
381
+
¿Puedo añadir una regresión detectada por un sistema de CI al seguimiento de regzbot?
382
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
383
+
384
+
Siéntase libre de hacerlo, si la regresión en concreto puede tener un
385
+
impacto en casos de uso prácticos y por tanto ser detectado por los usuarios;
386
+
Así, por favor no involucre a regzbot en regresiones teóricas que
387
+
difícilmente pudieran manifestarse en un uso real.
388
+
389
+
¿Cómo interactuar con regzbot?
390
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
391
+
392
+
Usando el comando 'regzbot' en una respuesta directa o indirecta al correo
393
+
con el informe de regresión. Ese comando necesita estar en su propio
394
+
párrafo (debe estar separado del resto del texto usando líneas en blanco):
395
+
396
+
Por ejemplo ``#regzbot introduced <version or commit>``, que hace que regzbot
397
+
considere el correo como un informe de regressión que se ha de añadir al
398
+
seguimiento, como se ha descrito anteriormente; ``#regzbot ^introduced <version or commit>``
399
+
es otro ejemplo del comando, el cual indica a regzbot que considere el email
400
+
anterior como el informe de una regresión que se ha de comenzar a monitorizar.
401
+
402
+
Una vez uno de esos dos comandos se ha utilizado, se pueden usar otros
403
+
comandos regzbot en respuestas directas o indirectas al informe. Puede
404
+
escribirlos debajo de uno de los comandos anteriormente usados o en las
405
+
respuestas al correo en el que se uso como respuesta a ese correo:
406
+
407
+
* Definir o actualizar el título::
408
+
409
+
#regzbot title: foo
410
+
411
+
* Monitorizar una discusión o un tiquet de bugzilla.kernel.org donde
412
+
aspectos adicionales del incidente o de la corrección se están
413
+
comentando -- por ejemplo presentar un parche que corrige la regresión::
414
+
415
+
#regzbot monitor: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/
416
+
417
+
Monitorizar solamente funciona para lore.kernel.org y bugzilla.kernel.org;
418
+
regzbot considerará todos los mensajes en ese hilo o el tiquet como
419
+
relacionados al proceso de corrección.
420
+
421
+
* Indicar a un lugar donde más detalles de interés, como un mensaje en una
422
+
lista de correo o un tiquet en un gestor de incidencias que pueden estar
423
+
levemente relacionados, pero con un tema diferente::
424
+
425
+
#regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
426
+
427
+
* Identificar una regresión como corregida por un commit que se ha mandado
428
+
aguas arriba o se ha publicado::
429
+
430
+
#regzbot fixed-by: 1f2e3d4c5d
431
+
432
+
433
+
* Identificar una regresión como un duplicado de otra que ya es seguida
434
+
por regzbot::
435
+
436
+
#regzbot dup-of: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/
437
+
438
+
* Identificar una regresión como inválida::
439
+
440
+
#regzbot invalid: wasn't a regression, problem has always existed
441
+
442
+
443
+
¿Algo más que decir sobre regzbot y sus comandos?
444
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
445
+
446
+
Hay información más detallada y actualizada sobre el bot de seguimiento de
447
+
regresiones del kernel de Linux en: `project page <https://gitlab.com/knurd42/regzbot>`_,
448
+
y entre otros contiene una `guia de inicio <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_
449
+
y `documentación de referencia <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_
450
+
Ambos contienen más detalles que las secciones anteriores.
451
+
452
+
453
+
Citas de Linus sobre regresiones
454
+
--------------------------------
455
+
456
+
A continuación se encuentran unos ejemplos reales (traducidos) de como
457
+
Linus Torvalds espera que se gestionen las regresiones:
458
+
459
+
460
+
* De 2017-10-26 (1/2)
461
+
<https://lore.kernel.org/lkml/CA+55aFwiiQYJ+YoLKCXjN_beDVfu38mg=Ggg5LFOcqHE8Qi7Zw@mail.gmail.com/>`_::
462
+
463
+
Si rompes la configuración de los espacios de usuario ESO ES UNA REGRESIÓN.
464
+
465
+
No está bien decir "pero nosotros arreglaremos la configuración del espacio
466
+
de usuario".
467
+
468
+
Realmente. NO ESTÁ BIEN.
469
+
470
+
[...]
471
+
472
+
La primera regla es:
473
+
474
+
- no causamos regresiones
475
+
476
+
y el corolario es que cuando una regresión pasa, lo admitimos y lo
477
+
arreglamos, en vez de echar la culpa al espacio de usuario.
478
+
479
+
El hecho de que aparentemente se haya negado la regresión durante
480
+
tres semanas, significa que lo revertiré y dejaré de integrar peticiones
481
+
de apparmor hasta que la gente involucrada entienda como se hace
482
+
el desarrollo del kernel.
483
+
484
+
485
+
* De `2017-10-26 (2/2)
486
+
<https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_::
487
+
488
+
La gente debería sentirse libre de actualizar su kernel y simplemente
489
+
no preocuparse por ello.
490
+
491
+
Me niego a imponer una limitación del tipo "solo puede actualizar
492
+
el kernel si actualiza otro programa". Si el kernel trabaja para tí,
493
+
la regla es que continúe trabajando para tí.
494
+
495
+
Ha habido algunas excepciones, pero son pocas y separadas entre sí, y
496
+
generalmente tienen una razón fundamental para haber sucedido, que era
497
+
básicamente inevitable, y la gente intentó evitarlas por todos los
498
+
medios. Quizás no podamos mantener el hardware más, después de que han
499
+
pasado décadas y nadie los usacon kernel modernos. Quizás haya un
500
+
problema de seguridad serio con cómo hicimos las cosas, y la gente
501
+
depende de un modelo fundamentalmente roto. Quizás haya algún otro roto
502
+
fundamental, que tenga que tener una _flag_ y por razones internas y
503
+
fundamentales.
504
+
505
+
Y nótese que esto trata sobre *romper* los entornos de la gente.
506
+
507
+
Cambios de comportamiento pasan, y quizás no se mantengan algunas
508
+
funcionalidades más. Hay un número de campos en /proc/<pid>/stat que
509
+
se imprimen como ceros, simplemente porque ni siquiera existen ya en
510
+
kernel, o porque mostrarlos era un error (típica una fuga de
511
+
información). Pero los números se sustituyeron por ceros, así que
512
+
el código que se usaba para parsear esos campos todavía existe. El
513
+
usuario puede no ver todo lo que podía ver antes, y por eso el
514
+
omportamiento es claramente diferente, pero las cosas todavía
515
+
_funcionan_, incluso si no se puede mostrar información sensible
516
+
(o que no es ya importante).
517
+
518
+
Pero si algo realmente se rompe, entonces el cambio debe de arreglarse
519
+
o revertirse. Y se arregla en el *kernel*. No diciendo "bueno, arreglaremos
520
+
tu espacio de usuario". Ha sido un cambio en el kernel el que creo
521
+
el problema, entonces ha de ser el kernel el que lo corrija, porque
522
+
tenemos un modelo de "actualización". Pero no tenemos una "actualización
523
+
con el nuevo espacio de usuario".
524
+
525
+
Y yo seriamente me negaré a coger código de gente que no entiende y
526
+
honre esta sencilla regla.
527
+
528
+
Y esta regla no va a cambiar.
529
+
530
+
Y sí, me doy cuenta que el kernel es "especial" en este respecto. Y
531
+
estoy orgulloso de ello.
532
+
533
+
Y he visto, y puedo señalar, muchos proyectos que dicen "Tenemos que
534
+
romper ese caso de uso para poder hacer progresos" o "estabas basandote
535
+
en comportamientos no documentados, debe ser duro ser tú" o "hay una
536
+
forma mejor de hacer lo que quieres hacer, y tienes que cambiar a esa
537
+
nueva forma", y yo simplemente no pienso que eso sea aceptable fuera
538
+
de una fase alfa muy temprana que tenga usuarios experimentales que
539
+
saben a lo que se han apuntado. El kernel no ha estado en esta
540
+
situación en las dos últimas décadas.
541
+
542
+
Nosotros rompemos la API _dentro_ del kernel todo el tiempo. Y
543
+
arreglaremos los problemas internos diciendo "tú ahora necesitas
544
+
hacer XYZ", pero entonces es sobre la API interna del kernel y la
545
+
gente que hace esto entonces tendrá obviamente que arreglar todos
546
+
los usos de esa API del kernel. Nadie puede decir "ahora, yo he roto
547
+
la API que usas, y ahora tú necesitas arreglarlo". Quién rompa algo,
548
+
lo arregla también.
549
+
550
+
Y nosotros, simplemente, no rompemos el espacio de usuario.
551
+
552
+
* De `2020-05-21
553
+
<https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/>`_::
554
+
555
+
Las reglas sobre regresiones nunca han sido sobre ningún tipo de
556
+
comportamiento documentado, o dónde está situado el código.
557
+
558
+
Las reglas sobre regresiones son siempre sobre "roturas en el
559
+
flujo de trabajo del usuario".
560
+
561
+
Los usuarios son literalmente la _única_ cosa que importa.
562
+
563
+
Argumentaciones como "no debería haber usado esto" o "ese
564
+
comportamiento es indefinido, es su culpa que su aplicación no
565
+
funcione" o "eso solía funcionar únicamente por un bug del kernel" son
566
+
irrelevantes.
567
+
568
+
Ahora, la realidad nunca es blanca o negra. Así hemos tenido situaciones
569
+
como "un serio incidente de seguridad" etc que solamente nos fuerza
570
+
a hacer cambios que pueden romper el espacio de usuario. Pero incluso
571
+
entonces la regla es que realmente no hay otras opciones para que
572
+
las cosas sigan funcionando.
573
+
574
+
Y obviamente, si los usuarios tardan años en darse cuenta que algo
575
+
se ha roto, o si hay formas adecuadas para sortear la rotura que
576
+
no causen muchos problemas para los usuarios (por ejemplo: "hay un
577
+
puñado de usuarios, y estos pueden usar la línea de comandos del
578
+
kernel para evitarlos"; ese tipo de casos), en esos casos se ha sido
579
+
un poco menos estricto.
580
+
581
+
Pero no, "eso que está documentado que está roto" (si es dado a que
582
+
el código estaba en preparación o porque el manual dice otra cosa) eso
583
+
es irrelevante. Si preparar el código es tan útil que la gente,
584
+
acaba usando, esto implica que básicamente es código del kernel con
585
+
una señal diciendo "por favor limpiar esto".
586
+
587
+
El otro lado de la moneda es que la gente que habla sobre "estabilidad
588
+
de las APIs" están totalmente equivocados. Las APIs tampoco importan.
589
+
Se puede hacer cualquier cambio que se quiera a una API ... siempre y
590
+
cuando nadie se de cuenta.
591
+
592
+
De nuevo, la regla de las regresiones no trata sobre la documentación,
593
+
tampoco sobre las APIs y tampoco sobre las fases de la Luna.
594
+
595
+
Únicamente trata sobre "hemos causado problemas al espacio de usuario que
596
+
antes funcionaba".
597
+
598
+
* De `2017-11-05
599
+
<https://lore.kernel.org/all/CA+55aFzUvbGjD8nQ-+3oiMBx14c_6zOj2n7KLN3UsJ-qsd4Dcw@mail.gmail.com/>`_::
600
+
601
+
Y nuestra regla sobre las regresiones nunca ha sido "el comportamiento
602
+
no cambia". Eso podría significar que nunca podríamos hacer ningún
603
+
cambio.
604
+
605
+
Por ejemplo, hacemos cosas como añadir una nueva gestión de
606
+
errores etc todo el tiempo, con lo cual a veces incluso añadimos
607
+
tests en el directorio de kselftest.
608
+
609
+
Así que claramente cambia el comportamiento todo el tiempo y
610
+
nosotros no consideramos eso una regresión per se.
611
+
612
+
La regla para regresiones para el kernel es para cuando se
613
+
rompe algo en el espacio de usuario. No en algún test. No en
614
+
"mira, antes podía hacer X, y ahora no puedo".
615
+
616
+
* De `2018-08-03
617
+
<https://lore.kernel.org/all/CA+55aFwWZX=CXmWDTkDGb36kf12XmTehmQjbiMPCqCRG2hi9kw@mail.gmail.com/>`_::
618
+
619
+
ESTÁS OLVIDANDO LA REGLA #1 DEL KERNEL.
620
+
621
+
No hacemos regresiones, y no hacemos regresiones porque estás 100%
622
+
equivocado.
623
+
624
+
Y la razón que apuntas en tú opinión es exactamente *PORQUÉ* estás
625
+
equivocado.
626
+
627
+
Tus "buenas razones" son honradas y pura basura.
628
+
629
+
El punto de "no hacemos regresiones" es para que la gente pueda
630
+
actualizar el kernel y nunca tengan que preocuparse por ello.
631
+
632
+
> El kernel tiene un bug que ha de ser arreglado
633
+
634
+
Eso es *TOTALMENTE* insustancial.
635
+
636
+
Chicos, si algo estaba roto o no, NO IMPORTA.
637
+
638
+
¿Porqué?
639
+
640
+
Los errores pasan. Eso es un hecho de la vida. Discutir que
641
+
"tenemos que romper algo porque estábamos arreglando un error" es
642
+
una locura. Arreglamos decenas de errores cada dia, pensando que
643
+
"arreglando un bug" significa que podemos romper otra cosa es algo
644
+
que simplemente NO ES VERDAD.
645
+
646
+
Así que los bugs no son realmente relevantes para la discusión. Estos
647
+
suceden y se detectan, se arreglan, y no tienen nada que ver con
648
+
"rompemos a los usuarios".
649
+
650
+
Porque la única cosa que importa ES EL USUARIO.
651
+
652
+
¿Cómo de complicado es eso de comprender?
653
+
654
+
Cualquier persona que use "pero no funcionaba correctamente" es
655
+
un argumento no tiene la razón. Con respecto al USUARIO, no era
656
+
erróneo - funcionaba para él/ella.
657
+
658
+
Quizás funcionaba *porque* el usuario había tenido el bug en cuenta,
659
+
y quizás funcionaba porque el usuario no lo había notado - de nuevo
660
+
no importa. Funcionaba para el usuario.
661
+
662
+
Romper el flujo del trabajo de un usuario, debido a un "bug" es la
663
+
PEOR razón que se pueda usar.
664
+
665
+
Es básicamente decir "He cogido algo que funcionaba, y lo he roto,
666
+
pero ahora es mejor". ¿No ves que un argumento como este es j*didamente
667
+
absurdo?
668
+
669
+
y sin usuarios, tu programa no es un programa, es una pieza de
670
+
código sin finalidad que puedes perfectamente tirar a la basura.
671
+
672
+
Seriamente. Esto es *porque* la regla #1 para el desarrollo del
673
+
kernel es "no rompemos el espacio de usuario". Porque "He arreglado
674
+
un error" PARA NADA ES UN ARGUMENTO si esa corrección del código
675
+
rompe el espacio de usuario.
676
+
677
+
si actualizamos el kernel TODO EL TIEMPO, sin actualizar ningún otro
678
+
programa en absoluto. Y esto es absolutamente necesario, porque
679
+
las dependencias son terribles.
680
+
681
+
Y esto es necesario simplemente porque yo como desarrollador del
682
+
kernel no actualizo al azar otras herramientas que ni siquiera me
683
+
importan como desarrollador del kernel, y yo quiero que mis usuarios
684
+
se sientan a salvo haciendo lo mismo.
685
+
686
+
Así que no. Tu regla está COMPLETAMENTE equivocada. Si no puedes
687
+
actualizar el kernel sin actualizar otro binario al azar, entonces
688
+
tenemos un problema.
689
+
690
+
* De `2021-06-05
691
+
<https://lore.kernel.org/all/CAHk-=wiUVqHN76YUwhkjZzwTdjMMJf_zN4+u7vEJjmEGh3recw@mail.gmail.com/>`_::
692
+
693
+
NO HAY ARGUMENTOS VÁLIDOS PARA UNA REGRESIÓN.
694
+
695
+
Honestamente, la gente de seguridad necesita entender que "no funciona"
696
+
no es un caso de éxito sobre seguridad. Es un caso de fallo.
697
+
698
+
Sí, "no funciona" puede ser seguro. Pero en este caso es totalmente
699
+
inutil.
700
+
701
+
* De `2011-05-06 (1/3)
702
+
<https://lore.kernel.org/all/BANLkTim9YvResB+PwRp7QTK-a5VNg2PvmQ@mail.gmail.com/>`_::
703
+
704
+
La compatibilidad de los binarios es más importante.
705
+
706
+
Y si los binarios no usan el interfaz para parsear el formato
707
+
(o justamente lo parsea incorrectamente - como el reciente ejemplo
708
+
de añadir uuid al /proc/self/mountinfo), entonces es una regresión.
709
+
710
+
Y las regresiones se revierten, a menos que haya problemas de
711
+
seguridad o similares que nos hagan decir "Dios mío, realmente
712
+
tenemos que romper las cosas".
713
+
714
+
No entiendo porqué esta simple lógica es tan difícil para algunos
715
+
desarrolladores del kernel. La realidad importa. Sus deseos personales
716
+
NO IMPORTAN NADA.
717
+
718
+
Si se crea un interface que puede usarse sin parsear la
719
+
descripción del interface, entonces estaḿos atascados en el interface.
720
+
La teoría simplemente no importa.
721
+
722
+
Podrias alludar a arreglar las herramientas, e intentar evitar los
723
+
errores de compatibilidad de ese modo. No hay tampoco tantos de esos.
724
+
725
+
De `2011-05-06 (2/3)
726
+
<https://lore.kernel.org/all/BANLkTi=KVXjKR82sqsz4gwjr+E0vtqCmvA@mail.gmail.com/>`_::
727
+
728
+
Esto claramente NO es un tracepoint interno. Por definición. Y está
729
+
siendo usado por powertop.
730
+
731
+
De `2011-05-06 (3/3)
732
+
<https://lore.kernel.org/all/BANLkTinazaXRdGovYL7rRVp+j6HbJ7pzhg@mail.gmail.com/>`_::
733
+
734
+
Tenemos programas que usan esa ABI y si eso se rompe eso es una
735
+
regresión.
736
+
737
+
* De `2012-07-06 <https://lore.kernel.org/all/CA+55aFwnLJ+0sjx92EGREGTWOx84wwKaraSzpTNJwPVV8edw8g@mail.gmail.com/>`_::
738
+
739
+
> Ahora esto me ha dejado preguntandome si Debian _inestable_
740
+
realmente califica
741
+
> como espacio de usuario estándar.
742
+
743
+
Oh, si el kernel rompe algún espacio de usuario estándar, eso cuenta.
744
+
Muchísima gente usa Debian inestable.
745
+
746
+
* De `2019-09-15
747
+
<https://lore.kernel.org/lkml/CAHk-=wiP4K8DRJWsCo=20hn_6054xBamGKF2kPgUzpB5aMaofA@mail.gmail.com/>`_::
748
+
749
+
Una reversión _en particular_ en el último minuto en el último commit
750
+
(no teniendo en cuenta el propio cambio de versión) justo antes
751
+
de la liberación, y aunque es bastante incómodo, quizás también es
752
+
instructivo.
753
+
754
+
Lo que es instructivo sobre esto es que he revertido un commit que no
755
+
tenía ningún error. De hecho, hacía exactamente lo que pretendía, y lo
756
+
hacía muy bien. De hecho lo hacía _tan_ bien que los muy mejorados
757
+
patrones de IO que causaba han acabado revelando una regresión observable
758
+
desde el espacio de usuario, debido a un error real en un componente
759
+
no relacionado en absoluto.
760
+
761
+
De todas maneras, los detalles actuales de esta regresión no son la
762
+
razón por la que señalo esto como instructivo. Es más que es un ejemplo
763
+
ilustrativo sobre lo que cuenta como una regresión, y lo que conlleva
764
+
la regla del kernel de "no regresiones". El commit que ha sido revertido
765
+
no cambiaba ninguna API, y no introducía ningún error nuevo en el código.
766
+
Pero acabó exponiendo otro problema, y como eso causaba que la
767
+
actualización del kernel fallara para el usuario. Así que ha sido
768
+
revertido.
769
+
770
+
El foco aquí, es que hemos hecho la reversión basándonos en el
771
+
comportamiento reportado en el espacio de usuario, no basado en
772
+
conceptos como "cambios de ABI" o "provocaba un error". Los mejores
773
+
patrones de IO que se han presentado debido al cambio únicamente han
774
+
expuesto un viejo error, y la gente ya dependía del benigno
775
+
comportamiento de ese viejo error.
776
+
777
+
Y que no haya miedo, reintroduciremos el arreglo que mejoraba los
778
+
patrones de IO una vez hayamos decidido cómo gestionar el hecho de
779
+
que hay una interacción incorrecta con un interfaz en el que la
780
+
gente dependía de ese comportamiento previo. Es únicamente que
781
+
tenemos que ver cómo gestionamos y cómo lo hacemos (no hay menos de
782
+
tres parches diferentes de tres desarrolladores distintos que estamos
783
+
evaluando, ... puede haber más por llegar). Mientras tanto, he
784
+
revertido lo que exponía el problema a los usuarios de esta release,
785
+
incluso cuando espero que el fix será reintroducido (quizás insertado
786
+
a posteriormente como un parche estable) una vez lleguemos a un
787
+
acuerdo sobre cómo se ha de exponer el error.
788
+
789
+
Lo que hay que recordar de todo el asunto no es sobre si el cambio
790
+
de kernel-espacio-de-usuario ABI, o la corrección de un error, o si
791
+
el código antiguo "en primer lugar nunca debería haber estado ahí".
792
+
Es sobre si algo rompe el actual flujo de trabajo del usuario.
793
+
794
+
De todas formas, esto era mi pequeña aclaración en todo este
795
+
tema de la regresión. Ya que es la "primera regla de la programación
796
+
del kernel", me ha parecido que quizás es bueno mencionarlo de
797
+
vez en cuando.