| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20231031151325.2903088-1-carlos.bilbao@amd.com>
Date: Tue, 31 Oct 2023 10:13:25 -0500
From: Carlos Bilbao <carlos.bilbao@....com>
To: <corbet@....net>
CC: <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<sergio.collado@...il.com>, Carlos Bilbao <carlos.bilbao@....com>
Subject: [PATCH] docs/sp_SP: Add translation of process/handling-regressions
Translate Documentation/process/handling-regressions.rst into Spanish.
Co-developed-by: Sergio Gonzalez <sergio.collado@...il.com>
Signed-off-by: Sergio Gonzalez <sergio.collado@...il.com>
Signed-off-by: Carlos Bilbao <carlos.bilbao@....com>
---
.../sp_SP/process/handling-regressions.rst | 797 ++++++++++++++++++
.../translations/sp_SP/process/index.rst | 1 +
2 files changed, 798 insertions(+)
create mode 100644 Documentation/translations/sp_SP/process/handling-regressions.rst
diff --git a/Documentation/translations/sp_SP/process/handling-regressions.rst b/Documentation/translations/sp_SP/process/handling-regressions.rst
new file mode 100644
index 000000000000..aa0988985c55
--- /dev/null
+++ b/Documentation/translations/sp_SP/process/handling-regressions.rst
@@ -0,0 +1,797 @@
+.. include:: ../disclaimer-sp.rst
+
+:Translator: Sergio González Collado <sergio.collado@...il.com>
+
+.. _sp_handling_regressions:
+
+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:
+Documentation/admin-guide/reporting-regressions.rst, 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
+ <https://lore.kernel.org/regressions/>`_ (regressions@...ts.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@...mple.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:
+ Documentation/process/submitting-patches.rst y
+ :ref:`Documentation/process/5.Posting.rst <development_posting>`.
+
+#. 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
+<https://lore.kernel.org/regressions/>`_ (regressions@...ts.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:
+ Documentation/admin-guide/reporting-issues.rst.
+
+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@...mple.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:
+Documentation/process/submitting-patches.rst,
+:ref:`Documentation/process/5.Posting.rst <development_posting>`, y
+Documentation/process/stable-kernel-rules.rst
+
+ * 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@...r.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: Documentation/admin-guide/reporting-regressions.rst,
+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@...ts.linux.dev) y CC al seguidor de regresiones del kernel de
+Linux (regressions@...mhuis.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 <https://linux-regtracking.leemhuis.info/regzbot/>`_
+para ver la última información; o `busque el último informe de regresiones
+<https://lore.kernel.org/lkml/?q=%22Linux+regressions+report%22+f%3Aregzbot>`_,
+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 <https://gitlab.com/knurd42/regzbot>`_,
+y entre otros contiene una `guia de inicio <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_
+y `documentación de referencia <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_
+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)
+ <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_::
+
+ 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
+ <https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/>`_::
+
+ 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
+ <https://lore.kernel.org/all/CA+55aFzUvbGjD8nQ-+3oiMBx14c_6zOj2n7KLN3UsJ-qsd4Dcw@mail.gmail.com/>`_::
+
+ 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
+ <https://lore.kernel.org/all/CA+55aFwWZX=CXmWDTkDGb36kf12XmTehmQjbiMPCqCRG2hi9kw@mail.gmail.com/>`_::
+
+ 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
+ <https://lore.kernel.org/all/CAHk-=wiUVqHN76YUwhkjZzwTdjMMJf_zN4+u7vEJjmEGh3recw@mail.gmail.com/>`_::
+
+ 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)
+ <https://lore.kernel.org/all/BANLkTim9YvResB+PwRp7QTK-a5VNg2PvmQ@mail.gmail.com/>`_::
+
+ 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)
+ <https://lore.kernel.org/all/BANLkTi=KVXjKR82sqsz4gwjr+E0vtqCmvA@mail.gmail.com/>`_::
+
+ Esto claramente NO es un tracepoint interno. Por definición. Y está
+ siendo usado por powertop.
+
+ De `2011-05-06 (3/3)
+ <https://lore.kernel.org/all/BANLkTinazaXRdGovYL7rRVp+j6HbJ7pzhg@mail.gmail.com/>`_::
+
+ Tenemos programas que usan esa ABI y si eso se rompe eso es una
+ regresión.
+
+ * De `2012-07-06 <https://lore.kernel.org/all/CA+55aFwnLJ+0sjx92EGREGTWOx84wwKaraSzpTNJwPVV8edw8g@mail.gmail.com/>`_::
+
+ > 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
+ <https://lore.kernel.org/lkml/CAHk-=wiP4K8DRJWsCo=20hn_6054xBamGKF2kPgUzpB5aMaofA@mail.gmail.com/>`_::
+
+ 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.
diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst
index d6f3ccfb160e..a082e162168a 100644
--- a/Documentation/translations/sp_SP/process/index.rst
+++ b/Documentation/translations/sp_SP/process/index.rst
@@ -24,3 +24,4 @@
contribution-maturity-model
security-bugs
embargoed-hardware-issues
+ handling-regressions
--
2.34.1
Powered by blists - more mailing lists