Lines Matching refs:el
13 Documentation/admin-guide/reporting-regressions.rst, que cubre el tema
14 desde el punto de vista de un usuario; si nunca ha leído ese texto, realice
17 Las partes importantes (el "TL;DR")
31 #. Haga que el bot del kernel de Linux "regzbot" realice el seguimiento del
37 como el siguiente, lo que le indica a regzbot cuando empezó a suceder
38 el incidente::
43 regresiones(ver más arriba), incluir un párrafo como el siguiente::
51 del incidente, como se indica en el documento:
69 Asegúrese de que el programa de gestión de regresiones del kernel de Linux
75 inmediatamente meterla en el la cadena de emails mandado al menos un
87 inmediatamente iniciar el seguimiento de la regresión con "regzbot" el
93 párrafo como el siguiente::
97 Esto indica a regzbot el rango de versiones en el cual es defecto
99 de los commits así como un único commit, en caso en el que el informante
100 haya identificado el commit causante con 'bisect'.
102 Tenga en cuenta que el acento circunflejo (^) antes de "introduced":
103 Esto indica a regzbot, que debe tratar el email padre (el que ha sido
104 respondido) como el informeinicial para la regresión que quiere ser
116 Regzbot asociará automáticamente parches con el informe que contengan
117 las etiquetas "Link:" apuntando a su email o el ticket indicado.
128 * Apunte a todos los lugares donde el incidente se reportó usando la
134 * Añada la etiqueta "Fixes:" para indicar el commit causante de la
137 * Si el culpable ha sido "mergeado" en un ciclo de desarrollo anterior,
138 marque explícitamente el fix para retro-importarlo usando la etiqueta
146 herramientas es regzbot, el cual depende mucho de las etiquetas "Link:"
157 * Ejecutar el kernel con una regresión que afecta seriamente al uso.
163 kernel por más de dos semanas después de que el causante de una regresión
169 * Priorice el trabajo en la gestión de los informes de la regresión y
170 arreglar la regresión por encima de cualquier otro trabajo en el kernel
179 soportados de la serie, pero son libres de delegar el trabajo al equipo
180 permanente el incidente no hubiese ocurrido en la línea principal.
182 * Intente resolver cualquier regresión que apareciera en el ciclo de
200 que se ha identificado el responsable, si el incidente fue introducido
205 * en el último ciclo de desarrollo de la rama principal
207 En el último caso (por ejemplo v5.14), intentar gestionar las
215 después de que el culpable haya sido identificado. Dos o tres semanas
218 Linux (a menos que se un incidente en el ciclo de desarrollo actual, en
249 Evalué cómo de grande es el riesgo de una regresión, por ejemplo realizando
252 afectados para evaluar o incluso testear el cambio propuesto; si
256 Si al final, el riesgo de la regresión parece ser relativamente pequeño,
257 entonces adelante con el cambio, pero siempre informe a todas las partes
259 del parche, se hace explícito este hecho. Una vez el cambio ha sido
261 correo de regresiones sobre el riesgo, de manera que cualquiera que tenga
262 el cambio en el radar, en el caso de que aparezcan reportes. Dependiendo
264 mencione el hecho en su línea principal de desarrollo.
276 * quién es el responsable de identificar la causa raíz de una regresión
287 Linux (regressions@leemhuis.info); Si el incidente pudiera ser mejor
294 ¿Por qué el kernel de Linux tiene un gestor de regresiones, y por qué se usa regzbot?
299 que esto es verdad también para el kernel de Linux. Esto es por lo que
301 con el gestor de regresiones del kernel de Linux. A nadie se le paga por
303 con el "mejor esfuerzo".
308 Thorsten desarrollo regbot para facilitar el trabajo, con el objetivo a
312 ¿Cómo funciona el seguimiento de regresiones con regzbot?
324 necesitan informar a regzbot con el comando ``#regzbot introduced``
331 descripción del parche apuntando a todos los informes sobre el error
337 Hacerlo es por el bien de todo el mundo, tanto los mantenedores del kernel,
349 problema mayor en el kernel de Linux o algo en la vida real que nos mantenga
352 los mandamos al árbol de desarrollo en el que se integran habitualmente a
358 Verifique el `interfaz web de regzbot <https://linux-regtracking.leemhuis.info/regzbot/>`_
359 para ver la última información; o `busque el último informe de regresiones
361 el cual suele ser enviado por regzbot una vez a la semana el domingo por la
376 el gestor de incidencias de kernel de Linux, monitorizar incidentes
392 Usando el comando 'regzbot' en una respuesta directa o indirecta al correo
393 con el informe de regresión. Ese comando necesita estar en su propio
397 considere el correo como un informe de regressión que se ha de añadir al
399 es otro ejemplo del comando, el cual indica a regzbot que considere el email
400 anterior como el informe de una regresión que se ha de comenzar a monitorizar.
405 respuestas al correo en el que se uso como respuesta a ese correo:
407 * Definir o actualizar el título::
418 regzbot considerará todos los mensajes en ese hilo o el tiquet como
446 Hay información más detallada y actualizada sobre el bot de seguimiento de
476 y el corolario es que cuando una regresión pasa, lo admitimos y lo
482 el desarrollo del kernel.
492 el kernel si actualiza otro programa". Si el kernel trabaja para tí,
498 medios. Quizás no podamos mantener el hardware más, después de que han
512 el código que se usaba para parsear esos campos todavía existe. El
513 usuario puede no ver todo lo que podía ver antes, y por eso el
518 Pero si algo realmente se rompe, entonces el cambio debe de arreglarse
519 o revertirse. Y se arregla en el *kernel*. No diciendo "bueno, arreglaremos
520 tu espacio de usuario". Ha sido un cambio en el kernel el que creo
521 el problema, entonces ha de ser el kernel el que lo corrija, porque
523 con el nuevo espacio de usuario".
530 Y sí, me doy cuenta que el kernel es "especial" en este respecto. Y
542 Nosotros rompemos la API _dentro_ del kernel todo el tiempo. Y
550 Y nosotros, simplemente, no rompemos el espacio de usuario.
556 comportamiento documentado, o dónde está situado el código.
558 Las reglas sobre regresiones son siempre sobre "roturas en el
570 a hacer cambios que pueden romper el espacio de usuario. Pero incluso
582 el código estaba en preparación o porque el manual dice otra cosa) eso
583 es irrelevante. Si preparar el código es tan útil que la gente,
601 Y nuestra regla sobre las regresiones nunca ha sido "el comportamiento
606 errores etc todo el tiempo, con lo cual a veces incluso añadimos
607 tests en el directorio de kselftest.
609 Así que claramente cambia el comportamiento todo el tiempo y
612 La regla para regresiones para el kernel es para cuando se
613 rompe algo en el espacio de usuario. No en algún test. No en
630 actualizar el kernel y nunca tengan que preocuparse por ello.
658 Quizás funcionaba *porque* el usuario había tenido el bug en cuenta,
659 y quizás funcionaba porque el usuario no lo había notado - de nuevo
660 no importa. Funcionaba para el usuario.
662 Romper el flujo del trabajo de un usuario, debido a un "bug" es la
672 Seriamente. Esto es *porque* la regla #1 para el desarrollo del
673 kernel es "no rompemos el espacio de usuario". Porque "He arreglado
675 rompe el espacio de usuario.
677 si actualizamos el kernel TODO EL TIEMPO, sin actualizar ningún otro
687 actualizar el kernel sin actualizar otro binario al azar, entonces
706 Y si los binarios no usan el interfaz para parsear el formato
707 (o justamente lo parsea incorrectamente - como el reciente ejemplo
719 descripción del interface, entonces estaḿos atascados en el interface.
743 Oh, si el kernel rompe algún espacio de usuario estándar, eso cuenta.
749 Una reversión _en particular_ en el último minuto en el último commit
750 (no teniendo en cuenta el propio cambio de versión) justo antes
758 desde el espacio de usuario, debido a un error real en un componente
765 no cambiaba ninguna API, y no introducía ningún error nuevo en el código.
767 actualización del kernel fallara para el usuario. Así que ha sido
770 El foco aquí, es que hemos hecho la reversión basándonos en el
771 comportamiento reportado en el espacio de usuario, no basado en
777 Y que no haya miedo, reintroduciremos el arreglo que mejoraba los
778 patrones de IO una vez hayamos decidido cómo gestionar el hecho de
779 que hay una interacción incorrecta con un interfaz en el que la
784 revertido lo que exponía el problema a los usuarios de esta release,
785 incluso cuando espero que el fix será reintroducido (quizás insertado
787 acuerdo sobre cómo se ha de exponer el error.
789 Lo que hay que recordar de todo el asunto no es sobre si el cambio
791 el código antiguo "en primer lugar nunca debería haber estado ahí".
792 Es sobre si algo rompe el actual flujo de trabajo del usuario.