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")¶
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.
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
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.
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-rc1Esto 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=123456789Regzbot 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=1234567890Añ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: fooMonitorizar 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=123456789Identificar una regresión como corregida por un commit que se ha mandado aguas arriba o se ha publicado:
#regzbot fixed-by: 1f2e3d4c5dIdentificar 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.