798 lines · plain
1.. include:: ../disclaimer-sp.rst2 3:Translator: Sergio González Collado <sergio.collado@gmail.com>4 5.. _sp_handling_regressions:6 7Gestión de regresiones8++++++++++++++++++++++9 10*No causamos regresiones* -- este documento describe la que es la "primera11regla del desarrollo del kernel de Linux" y que implica en la práctica para12los desarrolladores. Y complementa la documentación:13Documentation/admin-guide/reporting-regressions.rst, que cubre el tema14desde el punto de vista de un usuario; si nunca ha leído ese texto, realice15al 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 list21 <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 la25 conversación de los correos, mandando un breve "Reply-all" con la26 lista en CCed.27 28 * Mande o redirija cualquier informe originado en los gestores de bugs29 a la lista.30 31#. Haga que el bot del kernel de Linux "regzbot" realice el seguimiento del32 incidente (esto es opcional, pero recomendado).33 34 * Para reportes enviados por correo, verificar si contiene alguna línea35 como ``#regzbot introduced v5.13..v5.14-rc1``. Si no, mandar una36 respuesta (con la lista de regresiones en CC) que contenga un párrafo37 como el siguiente, lo que le indica a regzbot cuando empezó a suceder38 el incidente::39 40 #regzbot ^introduced 1f2e3d4c5b6a41 42 * Cuando se mandan informes desde un gestor de incidentes a la lista de43 regresiones(ver más arriba), incluir un párrafo como el siguiente::44 45 #regzbot introduced: v5.13..v5.14-rc146 #regzbot from: Some N. Ice Human <some.human@example.com>47 #regzbot monitor: http://some.bugtracker.example.com/ticket?id=12345678948 49#. Cuando se manden correcciones para las regresiones, añadir etiquetas50 "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 y53 :ref:`Documentation/process/5.Posting.rst <development_posting>`.54 55#. Intente arreglar las regresiones rápidamente una vez la causa haya sido56 identificada; las correcciones para la mayor parte de las regresiones57 deberían ser integradas en menos de dos semanas, pero algunas pueden58 resolverse en dos o tres días.59 60Detalles importantes para desarrolladores en la regresiones de kernel de Linux61==============================================================================62 63Puntos básicos importantes más en detalle64-----------------------------------------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 Linux70y los subscritos a la lista de correo `regression mailing list71<https://lore.kernel.org/regressions/>`_ (regressions@lists.linux.dev) son72conocedores 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 un76 breve "Reply-all" con la lista en CC; Intentar asegurar que la lista es77 añadida en CC de nuevo en caso de que alguna respuesta la omita de la78 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 de82 la lista de antemano, si la persona que lo ha informado, lo ha enviado83 anteriormente, como se indica en:84 Documentation/admin-guide/reporting-issues.rst.85 86Cuando se realice cualquiera de las acciones anteriores, considere87inmediatamente iniciar el seguimiento de la regresión con "regzbot" el88gestor de regresiones del kernel de Linux.89 90 * Para los informes enviados por email, verificar si se ha incluido un91 comando a "regzbot", como ``#regzbot introduced 1f2e3d4c5b6a``. Si no es92 así, envíe una respuesta (con la lista de regresiones en CC) con un93 párrafo como el siguiente::94 95 #regzbot ^introduced: v5.13..v5.14-rc196 97 Esto indica a regzbot el rango de versiones en el cual es defecto98 comenzó a suceder; Puede especificar un rango usando los identificadores99 de los commits así como un único commit, en caso en el que el informante100 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 sido104 respondido) como el informeinicial para la regresión que quiere ser105 seguida. Esto es importante, ya que regzbot buscará más tarde parches106 con etiquetas "Link:" que apunten al al informe de losarchivos de107 lore.kernel.org.108 109 * Cuando mande informes de regresiones a un gestor de defectos, incluya un110 párrafo con los siguientes comandos a regzbot::111 112 #regzbot introduced: 1f2e3d4c5b6a113 #regzbot from: Some N. Ice Human <some.human@example.com>114 #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789115 116 Regzbot asociará automáticamente parches con el informe que contengan117 las etiquetas "Link:" apuntando a su email o el ticket indicado.118 119Qué es importante cuando se corrigen regresiones120~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~121 122No se necesita hacer nada especial cuando se mandan las correcciones para123las regresiones únicamente recordar lo que se explica en los documentos:124Documentation/process/submitting-patches.rst,125:ref:`Documentation/process/5.Posting.rst <development_posting>`, y126Documentation/process/stable-kernel-rules.rst127 128 * Apunte a todos los lugares donde el incidente se reportó usando la129 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=1234567890133 134 * Añada la etiqueta "Fixes:" para indicar el commit causante de la135 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 etiqueta139 ``Cc: stable@vger.kernel.org`` tag.140 141Todo esto se espera y es importante en una regresión, ya que estas142etiquetas son de gran valor para todos (incluido usted) que pueda estar143mirando en ese incidente semanas, meses o años después. Estas etiquetas son144también cruciales para las herramientas y scripts usados por otros145desarrolladores del kernel o distribuciones de Linux; una de esas146herramientas es regzbot, el cual depende mucho de las etiquetas "Link:"147para asociar los informes por regresiones con los cambios que las148resuelven.149 150 151Priorización del trabajo en arreglar regresiones152~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~153 154Al final, los desarrolladores deberían hacer lo posible para evitar a los155usuarios 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ón160 soportada del kernel que no tenga las funcionalidades requeridas.161 162 * Continuar ejecutando una versión desfasada y potencialmente insegura del163 kernel por más de dos semanas después de que el causante de una regresión164 fuese identificado.165 166Cómo se ejecuta esto depende mucho de la situación. A continuación se167presentan unas reglas generales, en orden de importancia:168 169 * Priorice el trabajo en la gestión de los informes de la regresión y170 arreglar la regresión por encima de cualquier otro trabajo en el kernel171 de Linux, a menos que lo último afecte profundamente a efectos de172 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-aplicarlos175 después, junto con las correcciones necesarias, ya que esto puede la176 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 kernels179 soportados de la serie, pero son libres de delegar el trabajo al equipo180 permanente el incidente no hubiese ocurrido en la línea principal.181 182 * Intente resolver cualquier regresión que apareciera en el ciclo de183 desarrollo antes de que este acabe. Si se teme que una corrección184 pudiera ser demasiado arriesgada para aplicarla días antes de una185 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 posible187 con una explicación de la situación. El podrá decidir, y posponer la188 liberación si fuese necesario, por ejemplo si aparecieran múltiples189 cambios como ese.190 191 * Gestione las regresiones en la rama estable, de largo término, o la192 propia rama principal de las versiones, con más urgencia que la193 regresiones en las preliberaciones. Esto cambia después de la liberación194 de la quinta pre-liberación, aka "-rc5": la rama principal entonces se195 vuelve más importante, asegurar que todas las mejoras y correcciones son196 idealmente testeados juntos por al menos una semana antes de que Linux197 libere la nueva versión en la rama principal.198 199 * Intente arreglar regresiones en un intervalo de una semana después de200 que se ha identificado el responsable, si el incidente fue introducido201 en alguno de los siguientes casos:202 203 * una versión estable/largo-plazo reciente204 205 * en el último ciclo de desarrollo de la rama principal206 207 En el último caso (por ejemplo v5.14), intentar gestionar las208 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 vida210 (EOL de las siglas en inglés End-of-Life) -- esto sucede usualmente211 sobre tres o cuatro semanas después de una liberación de una versión en212 la rama principal.213 214 * Intente arreglar cualquier otra regresión en un periodo de dos semanas215 después de que el culpable haya sido identificado. Dos o tres semanas216 adicionales son aceptables para regresiones de rendimiento y otros217 incidentes que son molestos, pero no bloquean a nadie la ejecución de218 Linux (a menos que se un incidente en el ciclo de desarrollo actual, en219 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 ser221 arreglada con un cambio arriesgado y al mismo tiempo únicamente afecta a222 unos pocos usuarios; también está bien si se usa tanto tiempo como fuera223 necesario si la regresión está presente en la segunda versión más nueva224 de largo plazo del kernel.225 226Nota: Los intervalos de tiempo mencionados anteriormente para la resolución227de las regresiones, incluyen la verificación de esta, revisión e inclusión228en la rama principal, idealmente con la corrección incluida en la rama229"linux-next" al menos brevemente. Esto conllevará retrasos que también se230tienen tener en cuenta.231 232Se espera que los maintainers de los subsistemas, ayuden en conseguir esos233tiempos, haciendo revisiones con prontitud y gestionando con rapidez los234parches aceptados. Esto puede resultar en tener que mandar peticiones de235git-pull antes o de forma más frecuente que lo normal; dependiendo del236arreglo, podría incluso ser aceptable saltarse la verificación en237linux-next. Especialmente para las correcciones en las ramas de los kernels238estable y de largo plazo necesitan ser gestionadas rápidamente, y las239correcciones necesitan ser incluidas en la rama principal antes de que240puedan ser incluidas posteriormente a las series precedentes.241 242 243Más aspectos sobre regresiones que los desarrolladores deben saber244------------------------------------------------------------------245 246Cómo tratar con cambios donde se sabe que hay riesgo de regresión247~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~248 249Evalué cómo de grande es el riesgo de una regresión, por ejemplo realizando250una búsqueda en las distribuciones de linux y en Git forges. Considere251también preguntar a otros desarrolladores o proyectos que pudieran ser252afectados para evaluar o incluso testear el cambio propuesto; si253apareciesen problemas, quizás se pudiera encontrar una solución aceptable254para 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 partes258involucradas del posible riesgo. Por tanto, asegúrese de que la descripción259del parche, se hace explícito este hecho. Una vez el cambio ha sido260integrado, informe al gestor de regresiones de Linux y a las listas de261correo de regresiones sobre el riesgo, de manera que cualquiera que tenga262el cambio en el radar, en el caso de que aparezcan reportes. Dependiendo263del riesgo, quizás se quiera preguntar al mantenedor del subsistema, que264mencione 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ón275 276 * quién es el responsable de identificar la causa raíz de una regresión277 278 * cómo gestionar situaciones difíciles, como por ejemplo cuando una279 regresión es causada por una corrección de seguridad o cuando una280 regresión causa otra regresión281 282A quién preguntar por consejo cuando se trata de regresiones283~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~284 285Mande un email a la lista de correo de regresiones286(regressions@lists.linux.dev) y CC al seguidor de regresiones del kernel de287Linux (regressions@leemhuis.info); Si el incidente pudiera ser mejor288gestionarlo en privado, puede omitirse la lista.289 290 291Más sobre la gestión de regresiones con regzbot292-----------------------------------------------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 otro298modo se romperían accidentalmente o a propósito. La historia ha mostrado299que esto es verdad también para el kernel de Linux. Esto es por lo que300Thorsten 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 por302hacer esto, y esa es la razón por la gestión de regresiones es un servicio303con el "mejor esfuerzo".304 305Intentos iniciales de gestionar manualmente las regresiones han demostrado306que es una tarea extenuante y frustrante, y por esa razón se dejaron de307hacer después de un tiempo. Para evitar que volviese a suceder esto,308Thorsten desarrollo regbot para facilitar el trabajo, con el objetivo a309largo plazo de automatizar la gestión de regresiones tanto como fuese310posible 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 regresiones316identificadas. Adicionalmente mira si se han publicado o enviado parches317que hagan referencia a esos informes con la etiqueta: "Link:"; respuestas a318esos parches también se siguen. Combinando esta información, también319proporciona una buena imagen del estado actual del proceso de corrección.320 321Regzbot intenta hacer todo este trabajo con tan poco retraso como sea322posible 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 usando326``#regzbot ^introduced``.327 328Para los desarrolladores normalmente no hay un trabajo adicional que329realizar, únicamente necesitan asegurarse una cosa, que ya se hacía mucho330antes de que regzbot apareciera: añadir las etiquetas "Link:" a la331descripción del parche apuntando a todos los informes sobre el error332corregido.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 trabajo339-- por ejemplo cuando deciden liberar una nueva versión o ampliar la fase de340desarrollo. Para esto necesitan conocer todas las regresiones que están sin341corregir; para esto, es conocido que Linux mira los informes semanales que342manda 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 problemas348cuando algo más importante aparece inesperadamente -- por ejemplo un349problema mayor en el kernel de Linux o algo en la vida real que nos mantenga350alejados de los teclados por un tiempo. Por eso es mejor informar a regzbot351sobre cada regresión, excepto cuando inmediatamente escribimos un parche y352los mandamos al árbol de desarrollo en el que se integran habitualmente a353la 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 regresiones360<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 la362noche (UTC), lo cual es unas horas antes de que Linus normalmente anuncie363las "(pre-)releases".364 365¿Qué sitios supervisa regzbot?366~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~367 368Regzbot supervisa las listas de correo más importantes de Linux, como369tambié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 para376el gestor de incidencias de kernel de Linux, monitorizar incidentes377graves, como informes sobre cuelgues, corrupción de datos o errores378internos (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 un385impacto 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 que387difí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 correo393con el informe de regresión. Ese comando necesita estar en su propio394párrafo (debe estar separado del resto del texto usando líneas en blanco):395 396Por ejemplo ``#regzbot introduced <version or commit>``, que hace que regzbot397considere el correo como un informe de regressión que se ha de añadir al398seguimiento, como se ha descrito anteriormente; ``#regzbot ^introduced <version or commit>``399es otro ejemplo del comando, el cual indica a regzbot que considere el email400anterior 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 otros403comandos regzbot en respuestas directas o indirectas al informe. Puede404escribirlos debajo de uno de los comandos anteriormente usados o en las405respuestas al correo en el que se uso como respuesta a ese correo:406 407 * Definir o actualizar el título::408 409 #regzbot title: foo410 411 * Monitorizar una discusión o un tiquet de bugzilla.kernel.org donde412 aspectos adicionales del incidente o de la corrección se están413 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 como419 relacionados al proceso de corrección.420 421 * Indicar a un lugar donde más detalles de interés, como un mensaje en una422 lista de correo o un tiquet en un gestor de incidencias que pueden estar423 levemente relacionados, pero con un tema diferente::424 425 #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789426 427 * Identificar una regresión como corregida por un commit que se ha mandado428 aguas arriba o se ha publicado::429 430 #regzbot fixed-by: 1f2e3d4c5d431 432 433 * Identificar una regresión como un duplicado de otra que ya es seguida434 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 existed441 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 de447regresiones 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 regresiones454--------------------------------455 456A continuación se encuentran unos ejemplos reales (traducidos) de como457Linus 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 espacio466 de usuario".467 468 Realmente. NO ESTÁ BIEN.469 470 [...]471 472 La primera regla es:473 474 - no causamos regresiones475 476 y el corolario es que cuando una regresión pasa, lo admitimos y lo477 arreglamos, en vez de echar la culpa al espacio de usuario.478 479 El hecho de que aparentemente se haya negado la regresión durante480 tres semanas, significa que lo revertiré y dejaré de integrar peticiones481 de apparmor hasta que la gente involucrada entienda como se hace482 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 simplemente489 no preocuparse por ello.490 491 Me niego a imponer una limitación del tipo "solo puede actualizar492 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í, y496 generalmente tienen una razón fundamental para haber sucedido, que era497 básicamente inevitable, y la gente intentó evitarlas por todos los498 medios. Quizás no podamos mantener el hardware más, después de que han499 pasado décadas y nadie los usacon kernel modernos. Quizás haya un500 problema de seguridad serio con cómo hicimos las cosas, y la gente501 depende de un modelo fundamentalmente roto. Quizás haya algún otro roto502 fundamental, que tenga que tener una _flag_ y por razones internas y503 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 algunas508 funcionalidades más. Hay un número de campos en /proc/<pid>/stat que509 se imprimen como ceros, simplemente porque ni siquiera existen ya en510 kernel, o porque mostrarlos era un error (típica una fuga de511 información). Pero los números se sustituyeron por ceros, así que512 el código que se usaba para parsear esos campos todavía existe. El513 usuario puede no ver todo lo que podía ver antes, y por eso el514 omportamiento es claramente diferente, pero las cosas todavía515 _funcionan_, incluso si no se puede mostrar información sensible516 (o que no es ya importante).517 518 Pero si algo realmente se rompe, entonces el cambio debe de arreglarse519 o revertirse. Y se arregla en el *kernel*. No diciendo "bueno, arreglaremos520 tu espacio de usuario". Ha sido un cambio en el kernel el que creo521 el problema, entonces ha de ser el kernel el que lo corrija, porque522 tenemos un modelo de "actualización". Pero no tenemos una "actualización523 con el nuevo espacio de usuario".524 525 Y yo seriamente me negaré a coger código de gente que no entiende y526 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. Y531 estoy orgulloso de ello.532 533 Y he visto, y puedo señalar, muchos proyectos que dicen "Tenemos que534 romper ese caso de uso para poder hacer progresos" o "estabas basandote535 en comportamientos no documentados, debe ser duro ser tú" o "hay una536 forma mejor de hacer lo que quieres hacer, y tienes que cambiar a esa537 nueva forma", y yo simplemente no pienso que eso sea aceptable fuera538 de una fase alfa muy temprana que tenga usuarios experimentales que539 saben a lo que se han apuntado. El kernel no ha estado en esta540 situación en las dos últimas décadas.541 542 Nosotros rompemos la API _dentro_ del kernel todo el tiempo. Y543 arreglaremos los problemas internos diciendo "tú ahora necesitas544 hacer XYZ", pero entonces es sobre la API interna del kernel y la545 gente que hace esto entonces tendrá obviamente que arreglar todos546 los usos de esa API del kernel. Nadie puede decir "ahora, yo he roto547 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-21553 <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 de556 comportamiento documentado, o dónde está situado el código.557 558 Las reglas sobre regresiones son siempre sobre "roturas en el559 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 "ese564 comportamiento es indefinido, es su culpa que su aplicación no565 funcione" o "eso solía funcionar únicamente por un bug del kernel" son566 irrelevantes.567 568 Ahora, la realidad nunca es blanca o negra. Así hemos tenido situaciones569 como "un serio incidente de seguridad" etc que solamente nos fuerza570 a hacer cambios que pueden romper el espacio de usuario. Pero incluso571 entonces la regla es que realmente no hay otras opciones para que572 las cosas sigan funcionando.573 574 Y obviamente, si los usuarios tardan años en darse cuenta que algo575 se ha roto, o si hay formas adecuadas para sortear la rotura que576 no causen muchos problemas para los usuarios (por ejemplo: "hay un577 puñado de usuarios, y estos pueden usar la línea de comandos del578 kernel para evitarlos"; ese tipo de casos), en esos casos se ha sido579 un poco menos estricto.580 581 Pero no, "eso que está documentado que está roto" (si es dado a que582 el código estaba en preparación o porque el manual dice otra cosa) eso583 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 con585 una señal diciendo "por favor limpiar esto".586 587 El otro lado de la moneda es que la gente que habla sobre "estabilidad588 de las APIs" están totalmente equivocados. Las APIs tampoco importan.589 Se puede hacer cualquier cambio que se quiera a una API ... siempre y590 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 que596 antes funcionaba".597 598 * De `2017-11-05599 <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 comportamiento602 no cambia". Eso podría significar que nunca podríamos hacer ningún603 cambio.604 605 Por ejemplo, hacemos cosas como añadir una nueva gestión de606 errores etc todo el tiempo, con lo cual a veces incluso añadimos607 tests en el directorio de kselftest.608 609 Así que claramente cambia el comportamiento todo el tiempo y610 nosotros no consideramos eso una regresión per se.611 612 La regla para regresiones para el kernel es para cuando se613 rompe algo en el espacio de usuario. No en algún test. No en614 "mira, antes podía hacer X, y ahora no puedo".615 616 * De `2018-08-03617 <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ás625 equivocado.626 627 Tus "buenas razones" son honradas y pura basura.628 629 El punto de "no hacemos regresiones" es para que la gente pueda630 actualizar el kernel y nunca tengan que preocuparse por ello.631 632 > El kernel tiene un bug que ha de ser arreglado633 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 que641 "tenemos que romper algo porque estábamos arreglando un error" es642 una locura. Arreglamos decenas de errores cada dia, pensando que643 "arreglando un bug" significa que podemos romper otra cosa es algo644 que simplemente NO ES VERDAD.645 646 Así que los bugs no son realmente relevantes para la discusión. Estos647 suceden y se detectan, se arreglan, y no tienen nada que ver con648 "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" es655 un argumento no tiene la razón. Con respecto al USUARIO, no era656 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 nuevo660 no importa. Funcionaba para el usuario.661 662 Romper el flujo del trabajo de un usuario, debido a un "bug" es la663 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*didamente667 absurdo?668 669 y sin usuarios, tu programa no es un programa, es una pieza de670 código sin finalidad que puedes perfectamente tirar a la basura.671 672 Seriamente. Esto es *porque* la regla #1 para el desarrollo del673 kernel es "no rompemos el espacio de usuario". Porque "He arreglado674 un error" PARA NADA ES UN ARGUMENTO si esa corrección del código675 rompe el espacio de usuario.676 677 si actualizamos el kernel TODO EL TIEMPO, sin actualizar ningún otro678 programa en absoluto. Y esto es absolutamente necesario, porque679 las dependencias son terribles.680 681 Y esto es necesario simplemente porque yo como desarrollador del682 kernel no actualizo al azar otras herramientas que ni siquiera me683 importan como desarrollador del kernel, y yo quiero que mis usuarios684 se sientan a salvo haciendo lo mismo.685 686 Así que no. Tu regla está COMPLETAMENTE equivocada. Si no puedes687 actualizar el kernel sin actualizar otro binario al azar, entonces688 tenemos un problema.689 690 * De `2021-06-05691 <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 totalmente699 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 formato707 (o justamente lo parsea incorrectamente - como el reciente ejemplo708 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 de711 seguridad o similares que nos hagan decir "Dios mío, realmente712 tenemos que romper las cosas".713 714 No entiendo porqué esta simple lógica es tan difícil para algunos715 desarrolladores del kernel. La realidad importa. Sus deseos personales716 NO IMPORTAN NADA.717 718 Si se crea un interface que puede usarse sin parsear la719 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 los723 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 una735 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 califica741 > 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-15747 <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 commit750 (no teniendo en cuenta el propio cambio de versión) justo antes751 de la liberación, y aunque es bastante incómodo, quizás también es752 instructivo.753 754 Lo que es instructivo sobre esto es que he revertido un commit que no755 tenía ningún error. De hecho, hacía exactamente lo que pretendía, y lo756 hacía muy bien. De hecho lo hacía _tan_ bien que los muy mejorados757 patrones de IO que causaba han acabado revelando una regresión observable758 desde el espacio de usuario, debido a un error real en un componente759 no relacionado en absoluto.760 761 De todas maneras, los detalles actuales de esta regresión no son la762 razón por la que señalo esto como instructivo. Es más que es un ejemplo763 ilustrativo sobre lo que cuenta como una regresión, y lo que conlleva764 la regla del kernel de "no regresiones". El commit que ha sido revertido765 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 la767 actualización del kernel fallara para el usuario. Así que ha sido768 revertido.769 770 El foco aquí, es que hemos hecho la reversión basándonos en el771 comportamiento reportado en el espacio de usuario, no basado en772 conceptos como "cambios de ABI" o "provocaba un error". Los mejores773 patrones de IO que se han presentado debido al cambio únicamente han774 expuesto un viejo error, y la gente ya dependía del benigno775 comportamiento de ese viejo error.776 777 Y que no haya miedo, reintroduciremos el arreglo que mejoraba los778 patrones de IO una vez hayamos decidido cómo gestionar el hecho de779 que hay una interacción incorrecta con un interfaz en el que la780 gente dependía de ese comportamiento previo. Es únicamente que781 tenemos que ver cómo gestionamos y cómo lo hacemos (no hay menos de782 tres parches diferentes de tres desarrolladores distintos que estamos783 evaluando, ... puede haber más por llegar). Mientras tanto, he784 revertido lo que exponía el problema a los usuarios de esta release,785 incluso cuando espero que el fix será reintroducido (quizás insertado786 a posteriormente como un parche estable) una vez lleguemos a un787 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 cambio790 de kernel-espacio-de-usuario ABI, o la corrección de un error, o si791 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 este795 tema de la regresión. Ya que es la "primera regla de la programación796 del kernel", me ha parecido que quizás es bueno mencionarlo de797 vez en cuando.798