Spanish

Warning

Si tiene alguna duda sobre la exactitud del contenido de esta traducción, la única referencia válida es la documentación oficial en inglés. Además, por defecto, los enlaces a documentos redirigen a la documentación en inglés, incluso si existe una versión traducida. Consulte el índice para más información.

Translator

Sergio González Collado <sergio.collado@gmail.com>

Gestión de regresiones

No causamos regresiones -- este documento describe la que es la “primera regla del desarrollo del kernel de Linux” y que implica en la práctica para los desarrolladores. Y complementa la documentación: Reporting regressions, que cubre el tema desde el punto de vista de un usuario; si nunca ha leído ese texto, realice al menos una lectura rápida del mismo antes de continuar.

Las partes importantes (el “TL;DR”)

  1. Asegúrese de que los suscriptores a la lista regression mailing list (regressions@lists.linux.dev) son conocedores con rapidez de cualquier nuevo informe de regresión:

    • Cuando se reciba un correo que no incluyó a la lista, inclúyalo en la conversación de los correos, mandando un breve “Reply-all” con la lista en CCed.

    • Mande o redirija cualquier informe originado en los gestores de bugs a la lista.

  2. Haga que el bot del kernel de Linux “regzbot” realice el seguimiento del incidente (esto es opcional, pero recomendado).

    • Para reportes enviados por correo, verificar si contiene alguna línea como #regzbot introduced v5.13..v5.14-rc1. Si no, mandar una respuesta (con la lista de regresiones en CC) que contenga un párrafo como el siguiente, lo que le indica a regzbot cuando empezó a suceder el incidente:

      #regzbot ^introduced 1f2e3d4c5b6a

    • Cuando se mandan informes desde un gestor de incidentes a la lista de regresiones(ver más arriba), incluir un párrafo como el siguiente:

      #regzbot introduced: v5.13..v5.14-rc1
#regzbot from: Some N. Ice Human <some.human@example.com>
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789

  3. Cuando se manden correcciones para las regresiones, añadir etiquetas “Link:” a la descripción, apuntado a todos los sitios donde se informó del incidente, como se indica en el documento: Submitting patches: the essential guide to getting your code into the kernel y Documentation/process/5.Posting.rst.

  4. Intente arreglar las regresiones rápidamente una vez la causa haya sido identificada; las correcciones para la mayor parte de las regresiones deberían ser integradas en menos de dos semanas, pero algunas pueden resolverse en dos o tres días.

Detalles importantes para desarrolladores en la regresiones de kernel de Linux

Puntos básicos importantes más en detalle

Qué hacer cuando se recibe un aviso de regresión.

Asegúrese de que el programa de gestión de regresiones del kernel de Linux y los subscritos a la lista de correo regression mailing list (regressions@lists.linux.dev) son conocedores de cualquier nuevo informe de regresión:

  • Cuando se recibe un informe por email que no tiene en CC la lista, inmediatamente meterla en el la cadena de emails mandado al menos un breve “Reply-all” con la lista en CC; Intentar asegurar que la lista es añadida en CC de nuevo en caso de que alguna respuesta la omita de la lista.

  • Si un informe enviado a un gestor de defectos, llega a su correo, reenvíelo o redirijalo a la lista. Considere verificar los archivos de la lista de antemano, si la persona que lo ha informado, lo ha enviado anteriormente, como se indica en: Reporting issues.

Cuando se realice cualquiera de las acciones anteriores, considere inmediatamente iniciar el seguimiento de la regresión con “regzbot” el gestor de regresiones del kernel de Linux.

  • Para los informes enviados por email, verificar si se ha incluido un comando a “regzbot”, como #regzbot introduced 1f2e3d4c5b6a. Si no es así, envíe una respuesta (con la lista de regresiones en CC) con un párrafo como el siguiente:

    #regzbot ^introduced: v5.13..v5.14-rc1

    Esto indica a regzbot el rango de versiones en el cual es defecto comenzó a suceder; Puede especificar un rango usando los identificadores de los commits así como un único commit, en caso en el que el informante haya identificado el commit causante con ‘bisect’.

    Tenga en cuenta que el acento circunflejo (^) antes de “introduced”: Esto indica a regzbot, que debe tratar el email padre (el que ha sido respondido) como el informeinicial para la regresión que quiere ser seguida. Esto es importante, ya que regzbot buscará más tarde parches con etiquetas “Link:” que apunten al al informe de losarchivos de lore.kernel.org.

  • Cuando mande informes de regresiones a un gestor de defectos, incluya un párrafo con los siguientes comandos a regzbot:

    #regzbot introduced: 1f2e3d4c5b6a
#regzbot from: Some N. Ice Human <some.human@example.com>
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789

    Regzbot asociará automáticamente parches con el informe que contengan las etiquetas “Link:” apuntando a su email o el ticket indicado.

Qué es importante cuando se corrigen regresiones

No se necesita hacer nada especial cuando se mandan las correcciones para las regresiones únicamente recordar lo que se explica en los documentos: Submitting patches: the essential guide to getting your code into the kernel, Documentation/process/5.Posting.rst, y Everything you ever wanted to know about Linux -stable releases

  • Apunte a todos los lugares donde el incidente se reportó usando la etiqueta “Link:”

    Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890

  • Añada la etiqueta “Fixes:” para indicar el commit causante de la regresión.

  • Si el culpable ha sido “mergeado” en un ciclo de desarrollo anterior, marque explícitamente el fix para retro-importarlo usando la etiqueta Cc: stable@vger.kernel.org tag.

Todo esto se espera y es importante en una regresión, ya que estas etiquetas son de gran valor para todos (incluido usted) que pueda estar mirando en ese incidente semanas, meses o años después. Estas etiquetas son también cruciales para las herramientas y scripts usados por otros desarrolladores del kernel o distribuciones de Linux; una de esas herramientas es regzbot, el cual depende mucho de las etiquetas “Link:” para asociar los informes por regresiones con los cambios que las resuelven.

Priorización del trabajo en arreglar regresiones

Al final, los desarrolladores deberían hacer lo posible para evitar a los usuarios situaciones donde una regresión les deje solo tres opciones:

  • Ejecutar el kernel con una regresión que afecta seriamente al uso.

  • Cambiar a un kernel nuevo o mas antiguo -- rebajarse a una versión soportada del kernel que no tenga las funcionalidades requeridas.

  • Continuar ejecutando una versión desfasada y potencialmente insegura del kernel por más de dos semanas después de que el causante de una regresión fuese identificado.

Cómo se ejecuta esto depende mucho de la situación. A continuación se presentan unas reglas generales, en orden de importancia:

  • Priorice el trabajo en la gestión de los informes de la regresión y arreglar la regresión por encima de cualquier otro trabajo en el kernel de Linux, a menos que lo último afecte profundamente a efectos de seguridad, o cause errores en los que haya pérdida o daño de datos.

  • Considere siempre revertir los commits responsables y re-aplicarlos después, junto con las correcciones necesarias, ya que esto puede la forma menos peligrosa y más rápida de arreglar la regresión.

  • Los desarrolladores deberían gestionar la regresión en todos los kernels soportados de la serie, pero son libres de delegar el trabajo al equipo permanente el incidente no hubiese ocurrido en la línea principal.

  • Intente resolver cualquier regresión que apareciera en el ciclo de desarrollo antes de que este acabe. Si se teme que una corrección pudiera ser demasiado arriesgada para aplicarla días antes de una liberación de la línea principal de desarrollo, dejar decidir a Linus: mande la corrección a él de forma separada, tan pronto como sea posible con una explicación de la situación. El podrá decidir, y posponer la liberación si fuese necesario, por ejemplo si aparecieran múltiples cambios como ese.

  • Gestione las regresiones en la rama estable, de largo término, o la propia rama principal de las versiones, con más urgencia que la regresiones en las preliberaciones. Esto cambia después de la liberación de la quinta pre-liberación, aka “-rc5”: la rama principal entonces se vuelve más importante, asegurar que todas las mejoras y correcciones son idealmente testeados juntos por al menos una semana antes de que Linux libere la nueva versión en la rama principal.

  • Intente arreglar regresiones en un intervalo de una semana después de que se ha identificado el responsable, si el incidente fue introducido en alguno de los siguientes casos:

    • una versión estable/largo-plazo reciente

    • en el último ciclo de desarrollo de la rama principal

    En el último caso (por ejemplo v5.14), intentar gestionar las regresiones incluso más rápido, si la versión estable precedente (v5.13) ha de ser abandonada pronto o ya se ha etiquetado como de final de vida (EOL de las siglas en inglés End-of-Life) -- esto sucede usualmente sobre tres o cuatro semanas después de una liberación de una versión en la rama principal.

  • Intente arreglar cualquier otra regresión en un periodo de dos semanas después de que el culpable haya sido identificado. Dos o tres semanas adicionales son aceptables para regresiones de rendimiento y otros incidentes que son molestos, pero no bloquean a nadie la ejecución de Linux (a menos que se un incidente en el ciclo de desarrollo actual, en ese caso se debería gestionar antes de la liberación de la versión). Unas semanas son aceptables si la regresión únicamente puede ser arreglada con un cambio arriesgado y al mismo tiempo únicamente afecta a unos pocos usuarios; también está bien si se usa tanto tiempo como fuera necesario si la regresión está presente en la segunda versión más nueva de largo plazo del kernel.

Nota: Los intervalos de tiempo mencionados anteriormente para la resolución de las regresiones, incluyen la verificación de esta, revisión e inclusión en la rama principal, idealmente con la corrección incluida en la rama “linux-next” al menos brevemente. Esto conllevará retrasos que también se tienen tener en cuenta.

Se espera que los maintainers de los subsistemas, ayuden en conseguir esos tiempos, haciendo revisiones con prontitud y gestionando con rapidez los parches aceptados. Esto puede resultar en tener que mandar peticiones de git-pull antes o de forma más frecuente que lo normal; dependiendo del arreglo, podría incluso ser aceptable saltarse la verificación en linux-next. Especialmente para las correcciones en las ramas de los kernels estable y de largo plazo necesitan ser gestionadas rápidamente, y las correcciones necesitan ser incluidas en la rama principal antes de que puedan ser incluidas posteriormente a las series precedentes.

Más aspectos sobre regresiones que los desarrolladores deben saber

Cómo tratar con cambios donde se sabe que hay riesgo de regresión

Evalué cómo de grande es el riesgo de una regresión, por ejemplo realizando una búsqueda en las distribuciones de linux y en Git forges. Considere también preguntar a otros desarrolladores o proyectos que pudieran ser afectados para evaluar o incluso testear el cambio propuesto; si apareciesen problemas, quizás se pudiera encontrar una solución aceptable para todos.

Si al final, el riesgo de la regresión parece ser relativamente pequeño, entonces adelante con el cambio, pero siempre informe a todas las partes involucradas del posible riesgo. Por tanto, asegúrese de que la descripción del parche, se hace explícito este hecho. Una vez el cambio ha sido integrado, informe al gestor de regresiones de Linux y a las listas de correo de regresiones sobre el riesgo, de manera que cualquiera que tenga el cambio en el radar, en el caso de que aparezcan reportes. Dependiendo del riesgo, quizás se quiera preguntar al mantenedor del subsistema, que mencione el hecho en su línea principal de desarrollo.

¿Qué más hay que saber sobre regresiones?

Repase la documentación: Reporting regressions, esta cubre otros aspectos a tener a en cuenta y conocer:

  • la finalidad de la “regla de no regresión”

  • qué incidencias no se califican como regresión

  • quién es el responsable de identificar la causa raíz de una regresión

  • cómo gestionar situaciones difíciles, como por ejemplo cuando una regresión es causada por una corrección de seguridad o cuando una regresión causa otra regresión

A quién preguntar por consejo cuando se trata de regresiones

Mande un email a la lista de correo de regresiones (regressions@lists.linux.dev) y CC al seguidor de regresiones del kernel de Linux (regressions@leemhuis.info); Si el incidente pudiera ser mejor gestionarlo en privado, puede omitirse la lista.

Más sobre la gestión de regresiones con regzbot

¿Por qué el kernel de Linux tiene un gestor de regresiones, y por qué se usa regzbot?

Reglas como “no regresiones” necesitan asegurar que se cumplen, de otro modo se romperían accidentalmente o a propósito. La historia ha mostrado que esto es verdad también para el kernel de Linux. Esto es por lo que Thorsten Leemhuis se ofreció como voluntario para dar una solución a esto, con el gestor de regresiones del kernel de Linux. A nadie se le paga por hacer esto, y esa es la razón por la gestión de regresiones es un servicio con el “mejor esfuerzo”.

Intentos iniciales de gestionar manualmente las regresiones han demostrado que es una tarea extenuante y frustrante, y por esa razón se dejaron de hacer después de un tiempo. Para evitar que volviese a suceder esto, Thorsten desarrollo regbot para facilitar el trabajo, con el objetivo a largo plazo de automatizar la gestión de regresiones tanto como fuese posible para cualquiera que estuviese involucrado.

¿Cómo funciona el seguimiento de regresiones con regzbot?

El bot monitoriza las respuestas de los informes de las regresiones identificadas. Adicionalmente mira si se han publicado o enviado parches que hagan referencia a esos informes con la etiqueta: “Link:”; respuestas a esos parches también se siguen. Combinando esta información, también proporciona una buena imagen del estado actual del proceso de corrección.

Regzbot intenta hacer todo este trabajo con tan poco retraso como sea posible tanto para la gente que lo reporta, como para los desarrolladores. De hecho, solo los informantes son requeridos para una tarea adicional: necesitan informar a regzbot con el comando #regzbot introduced indicado anteriormente; si no hacen esto, alguien más puede hacerlo usando #regzbot ^introduced.

Para los desarrolladores normalmente no hay un trabajo adicional que realizar, únicamente necesitan asegurarse una cosa, que ya se hacía mucho antes de que regzbot apareciera: añadir las etiquetas “Link:” a la descripción del parche apuntando a todos los informes sobre el error corregido.

¿Tengo que usar regzbot?

Hacerlo es por el bien de todo el mundo, tanto los mantenedores del kernel, como Linus Torvalds dependen parcialmente en regzbot para seguir su trabajo -- por ejemplo cuando deciden liberar una nueva versión o ampliar la fase de desarrollo. Para esto necesitan conocer todas las regresiones que están sin corregir; para esto, es conocido que Linux mira los informes semanales que manda regzbot.

¿He de informar a regzbot cada regresión que encuentre?

Idealmente, sí: todos somos humanos y olvidamos fácilmente los problemas cuando algo más importante aparece inesperadamente -- por ejemplo un problema mayor en el kernel de Linux o algo en la vida real que nos mantenga alejados de los teclados por un tiempo. Por eso es mejor informar a regzbot sobre cada regresión, excepto cuando inmediatamente escribimos un parche y los mandamos al árbol de desarrollo en el que se integran habitualmente a la serie del kernel.

¿Cómo ver qué regresiones esta siguiendo regbot actualmente?

Verifique el interfaz web de regzbot para ver la última información; o busque el último informe de regresiones, el cual suele ser enviado por regzbot una vez a la semana el domingo por la noche (UTC), lo cual es unas horas antes de que Linus normalmente anuncie las “(pre-)releases”.

¿Qué sitios supervisa regzbot?

Regzbot supervisa las listas de correo más importantes de Linux, como también las de los repositorios linux-next, mainline y stable/longterm.

¿Qué tipos de incidentes han de ser monitorizados por regzbot?

El bot debe hacer seguimiento de las regresiones, y por tanto por favor, no involucre a regzbot para incidencias normales. Pero es correcto para el gestor de incidencias de kernel de Linux, monitorizar incidentes graves, como informes sobre cuelgues, corrupción de datos o errores internos (Panic, Oops, BUG(), warning, ...).

¿Puedo añadir una regresión detectada por un sistema de CI al seguimiento de regzbot?

Siéntase libre de hacerlo, si la regresión en concreto puede tener un impacto en casos de uso prácticos y por tanto ser detectado por los usuarios; Así, por favor no involucre a regzbot en regresiones teóricas que difícilmente pudieran manifestarse en un uso real.

¿Cómo interactuar con regzbot?

Usando el comando ‘regzbot’ en una respuesta directa o indirecta al correo con el informe de regresión. Ese comando necesita estar en su propio párrafo (debe estar separado del resto del texto usando líneas en blanco):

Por ejemplo #regzbot introduced <version or commit>, que hace que regzbot considere el correo como un informe de regressión que se ha de añadir al seguimiento, como se ha descrito anteriormente; #regzbot ^introduced <version or commit> es otro ejemplo del comando, el cual indica a regzbot que considere el email anterior como el informe de una regresión que se ha de comenzar a monitorizar.

Una vez uno de esos dos comandos se ha utilizado, se pueden usar otros comandos regzbot en respuestas directas o indirectas al informe. Puede escribirlos debajo de uno de los comandos anteriormente usados o en las respuestas al correo en el que se uso como respuesta a ese correo:

  • Definir o actualizar el título:

    #regzbot title: foo

  • Monitorizar una discusión o un tiquet de bugzilla.kernel.org donde aspectos adicionales del incidente o de la corrección se están comentando -- por ejemplo presentar un parche que corrige la regresión:

    #regzbot monitor: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/

Monitorizar solamente funciona para lore.kernel.org y bugzilla.kernel.org; regzbot considerará todos los mensajes en ese hilo o el tiquet como relacionados al proceso de corrección.

  • Indicar a un lugar donde más detalles de interés, como un mensaje en una lista de correo o un tiquet en un gestor de incidencias que pueden estar levemente relacionados, pero con un tema diferente:

    #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789

  • Identificar una regresión como corregida por un commit que se ha mandado aguas arriba o se ha publicado:

    #regzbot fixed-by: 1f2e3d4c5d

  • Identificar una regresión como un duplicado de otra que ya es seguida por regzbot:

    #regzbot dup-of: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/

  • Identificar una regresión como inválida:

    #regzbot invalid: wasn't a regression, problem has always existed

¿Algo más que decir sobre regzbot y sus comandos?

Hay información más detallada y actualizada sobre el bot de seguimiento de regresiones del kernel de Linux en: project page, y entre otros contiene una guia de inicio y documentación de referencia Ambos contienen más detalles que las secciones anteriores.

Citas de Linus sobre regresiones

A continuación se encuentran unos ejemplos reales (traducidos) de como Linus Torvalds espera que se gestionen las regresiones:

  • De 2017-10-26 (1/2) <https://lore.kernel.org/lkml/CA+55aFwiiQYJ+YoLKCXjN_beDVfu38mg=Ggg5LFOcqHE8Qi7Zw@mail.gmail.com/>`_:

    Si rompes la configuración de los espacios de usuario ESO ES UNA REGRESIÓN.

No está bien decir "pero nosotros arreglaremos la configuración del espacio
de usuario".

Realmente. NO ESTÁ BIEN.

[...]

La primera regla es:

- no causamos regresiones

y el corolario es que cuando una regresión pasa, lo admitimos y lo
arreglamos, en vez de echar la culpa al espacio de usuario.

El hecho de que aparentemente se haya negado la regresión durante
tres semanas, significa que lo revertiré y dejaré de integrar peticiones
de apparmor hasta que la gente involucrada entienda como se hace
el desarrollo del kernel.

  • De 2017-10-26 (2/2):

    La gente debería sentirse libre de actualizar su kernel y simplemente
no preocuparse por ello.

Me niego a imponer una limitación del tipo "solo puede actualizar
el kernel si actualiza otro programa". Si el kernel trabaja para tí,
la regla es que continúe trabajando para tí.

Ha habido algunas excepciones, pero son pocas y separadas entre sí, y
generalmente tienen una razón fundamental para haber sucedido, que era
básicamente inevitable, y la gente intentó evitarlas por todos los
medios. Quizás no podamos mantener el hardware más, después de que han
pasado décadas y nadie los usacon kernel modernos. Quizás haya un
problema de seguridad serio con cómo hicimos las cosas, y la gente
depende de un modelo fundamentalmente roto. Quizás haya algún otro roto
fundamental, que tenga que tener una _flag_ y por razones internas y
fundamentales.

Y nótese que esto trata sobre *romper* los entornos de la gente.

Cambios de comportamiento pasan, y quizás no se mantengan algunas
funcionalidades más. Hay un número de campos en /proc/<pid>/stat que
se imprimen como ceros, simplemente porque ni siquiera existen ya en
kernel, o porque mostrarlos era un error (típica una fuga de
información). Pero los números se sustituyeron por ceros, así que
el código que se usaba para parsear esos campos todavía existe. El
usuario puede no ver todo lo que podía ver antes, y por eso el
omportamiento es claramente diferente, pero las cosas todavía
_funcionan_, incluso si no se puede mostrar información sensible
(o que no es ya importante).

Pero si algo realmente se rompe, entonces el cambio debe de arreglarse
o revertirse. Y se arregla en el *kernel*. No diciendo "bueno, arreglaremos
tu espacio de usuario". Ha sido un cambio en el kernel el que creo
el problema, entonces ha de ser el kernel el que lo corrija, porque
tenemos un modelo de "actualización". Pero no tenemos una "actualización
con el nuevo espacio de usuario".

Y yo seriamente me negaré a coger código de gente que no entiende y
honre esta sencilla regla.

Y esta regla no va a cambiar.

Y sí, me doy cuenta que el kernel es "especial" en este respecto. Y
estoy orgulloso de ello.

Y he visto, y puedo señalar, muchos proyectos que dicen "Tenemos que
romper ese caso de uso para poder hacer progresos" o "estabas basandote
en comportamientos no documentados, debe ser duro ser tú" o "hay una
forma mejor de hacer lo que quieres hacer, y tienes que cambiar a esa
nueva forma", y yo simplemente no pienso que eso sea aceptable fuera
de una fase alfa muy temprana que tenga usuarios experimentales que
saben a lo que se han apuntado. El kernel no ha estado en esta
situación en las dos últimas décadas.

Nosotros rompemos la API _dentro_ del kernel todo el tiempo. Y
arreglaremos los problemas internos diciendo "tú ahora necesitas
hacer XYZ", pero entonces es sobre la API interna del kernel y la
gente que hace esto entonces tendrá obviamente que arreglar todos
los usos de esa API del kernel. Nadie puede decir "ahora, yo he roto
la API que usas, y ahora tú necesitas arreglarlo". Quién rompa algo,
lo arregla también.

Y nosotros, simplemente, no rompemos el espacio de usuario.

  • De 2020-05-21:

    Las reglas sobre regresiones nunca han sido sobre ningún tipo de
comportamiento documentado, o dónde está situado el código.

Las reglas sobre regresiones son siempre sobre "roturas en el
flujo de trabajo del usuario".

Los usuarios son literalmente la _única_ cosa que importa.

Argumentaciones como "no debería haber usado esto" o "ese
comportamiento es indefinido, es su culpa que su aplicación no
funcione" o "eso solía funcionar únicamente por un bug del kernel" son
irrelevantes.

Ahora, la realidad nunca es blanca o negra. Así hemos tenido situaciones
como "un serio incidente de seguridad" etc que solamente nos fuerza
a hacer cambios que pueden romper el espacio de usuario. Pero incluso
entonces la regla es que realmente no hay otras opciones para que
las cosas sigan funcionando.

Y obviamente, si los usuarios tardan años en darse cuenta que algo
se ha roto, o si hay formas adecuadas para sortear la rotura que
no causen muchos problemas para los usuarios (por ejemplo: "hay un
puñado de usuarios, y estos pueden usar la línea de comandos del
kernel para evitarlos"; ese tipo de casos), en esos casos se ha sido
un poco menos estricto.

Pero no, "eso que está documentado que está roto" (si es dado a que
el código estaba en preparación o porque el manual dice otra cosa) eso
es irrelevante. Si preparar el código es tan útil que la gente,
acaba usando, esto implica que básicamente es código del kernel con
una señal diciendo "por favor limpiar esto".

El otro lado de la moneda es que la gente que habla sobre "estabilidad
de las APIs" están totalmente equivocados. Las APIs tampoco importan.
Se puede hacer cualquier cambio que se quiera a una API ... siempre y
cuando nadie se de cuenta.

De nuevo, la regla de las regresiones no trata sobre la documentación,
tampoco sobre las APIs y tampoco sobre las fases de la Luna.

Únicamente trata sobre "hemos causado problemas al espacio de usuario que
antes funcionaba".

  • De 2017-11-05:

    Y nuestra regla sobre las regresiones nunca ha sido "el comportamiento
no cambia". Eso podría significar que nunca podríamos hacer ningún
cambio.

Por ejemplo, hacemos cosas como añadir una nueva gestión de
errores etc todo el tiempo, con lo cual a veces incluso añadimos
tests en el directorio de kselftest.

Así que claramente cambia el comportamiento todo el tiempo y
nosotros no consideramos eso una regresión per se.

La regla para regresiones para el kernel es para cuando se
rompe algo en el espacio de usuario. No en algún test. No en
"mira, antes podía hacer X, y ahora no puedo".

  • De 2018-08-03:

    ESTÁS OLVIDANDO LA REGLA #1 DEL KERNEL.

No hacemos regresiones, y no hacemos regresiones porque estás 100%
equivocado.

Y la razón que apuntas en tú opinión es exactamente *PORQUÉ* estás
equivocado.

Tus "buenas razones" son honradas y pura basura.

El punto de "no hacemos regresiones" es para que la gente pueda
actualizar el kernel y nunca tengan que preocuparse por ello.

> El kernel tiene un bug que ha de ser arreglado

Eso es *TOTALMENTE* insustancial.

Chicos, si algo estaba roto o no, NO IMPORTA.

¿Porqué?

Los errores pasan. Eso es un hecho de la vida. Discutir que
"tenemos que romper algo porque estábamos arreglando un error" es
una locura. Arreglamos decenas de errores cada dia, pensando que
"arreglando un bug" significa que podemos romper otra cosa es algo
que simplemente NO ES VERDAD.

Así que los bugs no son realmente relevantes para la discusión. Estos
suceden y se detectan, se arreglan, y no tienen nada que ver con
"rompemos a los usuarios".

Porque la única cosa que importa ES EL USUARIO.

¿Cómo de complicado es eso de comprender?

Cualquier persona que use "pero no funcionaba correctamente" es
un argumento no tiene la razón. Con respecto al USUARIO, no era
erróneo - funcionaba para él/ella.

Quizás funcionaba *porque* el usuario había tenido el bug en cuenta,
y quizás funcionaba porque el usuario no lo había notado - de nuevo
no importa. Funcionaba para el usuario.

Romper el flujo del trabajo de un usuario, debido a un "bug" es la
PEOR razón que se pueda usar.

Es básicamente decir "He cogido algo que funcionaba, y lo he roto,
pero ahora es mejor". ¿No ves que un argumento como este es j*didamente
absurdo?

y sin usuarios, tu programa no es un programa, es una pieza de
código sin finalidad que puedes perfectamente tirar a la basura.

Seriamente. Esto es *porque* la regla #1 para el desarrollo del
kernel es "no rompemos el espacio de usuario". Porque "He arreglado
un error" PARA NADA ES UN ARGUMENTO si esa corrección del código
rompe el espacio de usuario.

si actualizamos el kernel TODO EL TIEMPO, sin actualizar ningún otro
programa en absoluto. Y esto es absolutamente necesario, porque
las dependencias son terribles.

Y esto es necesario simplemente porque yo como desarrollador del
kernel no actualizo al azar otras herramientas que ni siquiera me
importan como desarrollador del kernel, y yo quiero que mis usuarios
se sientan a salvo haciendo lo mismo.

Así que no. Tu regla está COMPLETAMENTE equivocada. Si no puedes
actualizar el kernel sin actualizar otro binario al azar, entonces
tenemos un problema.

  • De 2021-06-05:

    NO HAY ARGUMENTOS VÁLIDOS PARA UNA REGRESIÓN.

Honestamente, la gente de seguridad necesita entender que "no funciona"
no es un caso de éxito sobre seguridad. Es un caso de fallo.

Sí, "no funciona" puede ser seguro. Pero en este caso es totalmente
inutil.

  • De 2011-05-06 (1/3):

    La compatibilidad de los binarios es más importante.

Y si los binarios no usan el interfaz para parsear el formato
(o justamente lo parsea incorrectamente - como el reciente ejemplo
de añadir uuid al /proc/self/mountinfo), entonces es una regresión.

Y las regresiones se revierten, a menos que haya problemas de
seguridad o similares que nos hagan decir "Dios mío, realmente
tenemos que romper las cosas".

No entiendo porqué esta simple lógica es tan difícil para algunos
desarrolladores del kernel. La realidad importa. Sus deseos personales
NO IMPORTAN NADA.

Si se crea un interface que puede usarse sin parsear la
descripción del interface, entonces estaḿos atascados en el interface.
La teoría simplemente no importa.

Podrias alludar a arreglar las herramientas, e intentar evitar los
errores de compatibilidad de ese modo. No hay tampoco tantos de esos.

    De 2011-05-06 (2/3):

    Esto claramente NO es un tracepoint interno. Por definición. Y está
siendo usado por powertop.

    De 2011-05-06 (3/3):

    Tenemos programas que usan esa ABI y si eso se rompe eso es una
regresión.

  • De 2012-07-06:

    > Ahora esto me ha dejado preguntandome si Debian _inestable_
realmente califica
> como espacio de usuario estándar.

Oh, si el kernel rompe algún espacio de usuario estándar, eso cuenta.
Muchísima gente usa Debian inestable.

  • De 2019-09-15:

    Una reversión _en particular_ en el último minuto en el último commit
(no teniendo en cuenta el propio cambio de versión) justo antes
de la liberación, y aunque es bastante incómodo, quizás también es
instructivo.

Lo que es instructivo sobre esto es que he revertido un commit que no
tenía ningún error. De hecho, hacía exactamente lo que pretendía, y lo
hacía muy bien. De hecho lo hacía _tan_ bien que los muy mejorados
patrones de IO que causaba han acabado revelando una regresión observable
desde el espacio de usuario, debido a un error real en un componente
no relacionado en absoluto.

De todas maneras, los detalles actuales de esta regresión no son la
razón por la que señalo esto como instructivo. Es más que es un ejemplo
ilustrativo sobre lo que cuenta como una regresión, y lo que conlleva
la regla del kernel de "no regresiones". El commit que ha sido revertido
no cambiaba ninguna API, y no introducía ningún error nuevo en el código.
Pero acabó exponiendo otro problema, y como eso causaba que la
actualización del kernel fallara para el usuario. Así que ha sido
revertido.

El foco aquí, es que hemos hecho la reversión basándonos en el
comportamiento reportado en el espacio de usuario, no basado en
conceptos como "cambios de ABI" o "provocaba un error". Los mejores
patrones de IO que se han presentado debido al cambio únicamente han
expuesto un viejo error, y la gente ya dependía del benigno
comportamiento de ese viejo error.

Y que no haya miedo, reintroduciremos el arreglo que mejoraba los
patrones de IO una vez hayamos decidido cómo gestionar el hecho de
que hay una interacción incorrecta con un interfaz en el que la
gente dependía de ese comportamiento previo. Es únicamente que
tenemos que ver cómo gestionamos y cómo lo hacemos (no hay menos de
tres parches diferentes de tres desarrolladores distintos que estamos
evaluando, ... puede haber más por llegar). Mientras tanto, he
revertido lo que exponía el problema a los usuarios de esta release,
incluso cuando espero que el fix será reintroducido (quizás insertado
a posteriormente como un parche estable) una vez lleguemos a un
acuerdo sobre cómo se ha de exponer el error.

Lo que hay que recordar de todo el asunto no es sobre si el cambio
de kernel-espacio-de-usuario ABI, o la corrección de un error, o si
el código antiguo "en primer lugar nunca debería haber estado ahí".
Es sobre si algo rompe el actual flujo de trabajo del usuario.

De todas formas, esto era mi pequeña aclaración en todo este
tema de la regresión. Ya que es la "primera regla de la programación
del kernel", me ha parecido que quizás es bueno mencionarlo de
vez en cuando.