1.. include:: ../disclaimer-sp.rst 2 3:Translator: Sergio González Collado <sergio.collado@gmail.com> 4 5.. _sp_handling_regressions: 6 7Gestión de regresiones 8++++++++++++++++++++++ 9 10*No causamos regresiones* -- este documento describe la que es la "primera 11regla del desarrollo del kernel de Linux" y que implica en la práctica para 12los desarrolladores. Y complementa la documentación: 13Documentation/admin-guide/reporting-regressions.rst, que cubre el tema 14desde el punto de vista de un usuario; si nunca ha leído ese texto, realice 15al menos una lectura rápida del mismo antes de continuar. 16 17Las 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 60Detalles importantes para desarrolladores en la regresiones de kernel de Linux 61============================================================================== 62 63Puntos básicos importantes más en detalle 64----------------------------------------- 65 66Qué hacer cuando se recibe un aviso de regresión. 67~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 68 69Asegúrese de que el programa de gestión de regresiones del kernel de Linux 70y los subscritos a la lista de correo `regression mailing list 71<https://lore.kernel.org/regressions/>`_ (regressions@lists.linux.dev) son 72conocedores 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 86Cuando se realice cualquiera de las acciones anteriores, considere 87inmediatamente iniciar el seguimiento de la regresión con "regzbot" el 88gestor 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 119Qué es importante cuando se corrigen regresiones 120~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 121 122No se necesita hacer nada especial cuando se mandan las correcciones para 123las regresiones únicamente recordar lo que se explica en los documentos: 124Documentation/process/submitting-patches.rst, 125:ref:`Documentation/process/5.Posting.rst <development_posting>`, y 126Documentation/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 141Todo esto se espera y es importante en una regresión, ya que estas 142etiquetas son de gran valor para todos (incluido usted) que pueda estar 143mirando en ese incidente semanas, meses o años después. Estas etiquetas son 144también cruciales para las herramientas y scripts usados por otros 145desarrolladores del kernel o distribuciones de Linux; una de esas 146herramientas es regzbot, el cual depende mucho de las etiquetas "Link:" 147para asociar los informes por regresiones con los cambios que las 148resuelven. 149 150 151Priorización del trabajo en arreglar regresiones 152~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 153 154Al final, los desarrolladores deberían hacer lo posible para evitar a los 155usuarios 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 166Cómo se ejecuta esto depende mucho de la situación. A continuación se 167presentan 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 226Nota: Los intervalos de tiempo mencionados anteriormente para la resolución 227de las regresiones, incluyen la verificación de esta, revisión e inclusión 228en 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 230tienen tener en cuenta. 231 232Se espera que los maintainers de los subsistemas, ayuden en conseguir esos 233tiempos, haciendo revisiones con prontitud y gestionando con rapidez los 234parches aceptados. Esto puede resultar en tener que mandar peticiones de 235git-pull antes o de forma más frecuente que lo normal; dependiendo del 236arreglo, podría incluso ser aceptable saltarse la verificación en 237linux-next. Especialmente para las correcciones en las ramas de los kernels 238estable y de largo plazo necesitan ser gestionadas rápidamente, y las 239correcciones necesitan ser incluidas en la rama principal antes de que 240puedan ser incluidas posteriormente a las series precedentes. 241 242 243Más aspectos sobre regresiones que los desarrolladores deben saber 244------------------------------------------------------------------ 245 246Cómo tratar con cambios donde se sabe que hay riesgo de regresión 247~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 248 249Evalué cómo de grande es el riesgo de una regresión, por ejemplo realizando 250una búsqueda en las distribuciones de linux y en Git forges. Considere 251también preguntar a otros desarrolladores o proyectos que pudieran ser 252afectados para evaluar o incluso testear el cambio propuesto; si 253apareciesen problemas, quizás se pudiera encontrar una solución aceptable 254para todos. 255 256Si al final, el riesgo de la regresión parece ser relativamente pequeño, 257entonces adelante con el cambio, pero siempre informe a todas las partes 258involucradas del posible riesgo. Por tanto, asegúrese de que la descripción 259del parche, se hace explícito este hecho. Una vez el cambio ha sido 260integrado, informe al gestor de regresiones de Linux y a las listas de 261correo de regresiones sobre el riesgo, de manera que cualquiera que tenga 262el cambio en el radar, en el caso de que aparezcan reportes. Dependiendo 263del riesgo, quizás se quiera preguntar al mantenedor del subsistema, que 264mencione el hecho en su línea principal de desarrollo. 265 266¿Qué más hay que saber sobre regresiones? 267~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 268 269Repase la documentación: Documentation/admin-guide/reporting-regressions.rst, 270esta 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 282A quién preguntar por consejo cuando se trata de regresiones 283~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 284 285Mande un email a la lista de correo de regresiones 286(regressions@lists.linux.dev) y CC al seguidor de regresiones del kernel de 287Linux (regressions@leemhuis.info); Si el incidente pudiera ser mejor 288gestionarlo en privado, puede omitirse la lista. 289 290 291Má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 297Reglas como "no regresiones" necesitan asegurar que se cumplen, de otro 298modo se romperían accidentalmente o a propósito. La historia ha mostrado 299que esto es verdad también para el kernel de Linux. Esto es por lo que 300Thorsten Leemhuis se ofreció como voluntario para dar una solución a esto, 301con el gestor de regresiones del kernel de Linux. A nadie se le paga por 302hacer esto, y esa es la razón por la gestión de regresiones es un servicio 303con el "mejor esfuerzo". 304 305Intentos iniciales de gestionar manualmente las regresiones han demostrado 306que es una tarea extenuante y frustrante, y por esa razón se dejaron de 307hacer después de un tiempo. Para evitar que volviese a suceder esto, 308Thorsten desarrollo regbot para facilitar el trabajo, con el objetivo a 309largo plazo de automatizar la gestión de regresiones tanto como fuese 310posible para cualquiera que estuviese involucrado. 311 312¿Cómo funciona el seguimiento de regresiones con regzbot? 313~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 314 315El bot monitoriza las respuestas de los informes de las regresiones 316identificadas. Adicionalmente mira si se han publicado o enviado parches 317que hagan referencia a esos informes con la etiqueta: "Link:"; respuestas a 318esos parches también se siguen. Combinando esta información, también 319proporciona una buena imagen del estado actual del proceso de corrección. 320 321Regzbot intenta hacer todo este trabajo con tan poco retraso como sea 322posible tanto para la gente que lo reporta, como para los desarrolladores. 323De hecho, solo los informantes son requeridos para una tarea adicional: 324necesitan informar a regzbot con el comando ``#regzbot introduced`` 325indicado anteriormente; si no hacen esto, alguien más puede hacerlo usando 326``#regzbot ^introduced``. 327 328Para los desarrolladores normalmente no hay un trabajo adicional que 329realizar, únicamente necesitan asegurarse una cosa, que ya se hacía mucho 330antes de que regzbot apareciera: añadir las etiquetas "Link:" a la 331descripción del parche apuntando a todos los informes sobre el error 332corregido. 333 334¿Tengo que usar regzbot? 335~~~~~~~~~~~~~~~~~~~~~~~~ 336 337Hacerlo es por el bien de todo el mundo, tanto los mantenedores del kernel, 338como 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 340desarrollo. Para esto necesitan conocer todas las regresiones que están sin 341corregir; para esto, es conocido que Linux mira los informes semanales que 342manda regzbot. 343 344¿He de informar a regzbot cada regresión que encuentre? 345~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 346 347Idealmente, sí: todos somos humanos y olvidamos fácilmente los problemas 348cuando algo más importante aparece inesperadamente -- por ejemplo un 349problema mayor en el kernel de Linux o algo en la vida real que nos mantenga 350alejados de los teclados por un tiempo. Por eso es mejor informar a regzbot 351sobre cada regresión, excepto cuando inmediatamente escribimos un parche y 352los mandamos al árbol de desarrollo en el que se integran habitualmente a 353la serie del kernel. 354 355¿Cómo ver qué regresiones esta siguiendo regbot actualmente? 356~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 357 358Verifique el `interfaz web de regzbot <https://linux-regtracking.leemhuis.info/regzbot/>`_ 359para 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>`_, 361el cual suele ser enviado por regzbot una vez a la semana el domingo por la 362noche (UTC), lo cual es unas horas antes de que Linus normalmente anuncie 363las "(pre-)releases". 364 365¿Qué sitios supervisa regzbot? 366~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 367 368Regzbot supervisa las listas de correo más importantes de Linux, como 369tambié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~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 374El bot debe hacer seguimiento de las regresiones, y por tanto por favor, 375no involucre a regzbot para incidencias normales. Pero es correcto para 376el gestor de incidencias de kernel de Linux, monitorizar incidentes 377graves, como informes sobre cuelgues, corrupción de datos o errores 378internos (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 384Siéntase libre de hacerlo, si la regresión en concreto puede tener un 385impacto en casos de uso prácticos y por tanto ser detectado por los usuarios; 386Así, por favor no involucre a regzbot en regresiones teóricas que 387difícilmente pudieran manifestarse en un uso real. 388 389¿Cómo interactuar con regzbot? 390~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 391 392Usando el comando 'regzbot' en una respuesta directa o indirecta al correo 393con el informe de regresión. Ese comando necesita estar en su propio 394párrafo (debe estar separado del resto del texto usando líneas en blanco): 395 396Por ejemplo ``#regzbot introduced <version or commit>``, que hace que regzbot 397considere el correo como un informe de regressión que se ha de añadir al 398seguimiento, como se ha descrito anteriormente; ``#regzbot ^introduced <version or commit>`` 399es otro ejemplo del comando, el cual indica a regzbot que considere el email 400anterior como el informe de una regresión que se ha de comenzar a monitorizar. 401 402Una vez uno de esos dos comandos se ha utilizado, se pueden usar otros 403comandos regzbot en respuestas directas o indirectas al informe. Puede 404escribirlos debajo de uno de los comandos anteriormente usados o en las 405respuestas 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 446Hay información más detallada y actualizada sobre el bot de seguimiento de 447regresiones del kernel de Linux en: `project page <https://gitlab.com/knurd42/regzbot>`_, 448y entre otros contiene una `guia de inicio <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_ 449y `documentación de referencia <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_ 450Ambos contienen más detalles que las secciones anteriores. 451 452 453Citas de Linus sobre regresiones 454-------------------------------- 455 456A continuación se encuentran unos ejemplos reales (traducidos) de como 457Linus 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. 798