Lines Matching refs:de
7 Gestión de regresiones
11 regla del desarrollo del kernel de Linux" y que implica en la práctica para
14 desde el punto de vista de un usuario; si nunca ha leído ese texto, realice
15 al menos una lectura rápida del mismo antes de continuar.
20 #. Asegúrese de que los suscriptores a la lista `regression mailing list
22 son conocedores con rapidez de cualquier nuevo informe de regresión:
25 conversación de los correos, mandando un breve "Reply-all" con la
28 * Mande o redirija cualquier informe originado en los gestores de bugs
31 #. Haga que el bot del kernel de Linux "regzbot" realice el seguimiento del
36 respuesta (con la lista de regresiones en CC) que contenga un párrafo
42 * Cuando se mandan informes desde un gestor de incidentes a la lista de
56 identificada; las correcciones para la mayor parte de las regresiones
57 deberían ser integradas en menos de dos semanas, pero algunas pueden
60 Detalles importantes para desarrolladores en la regresiones de kernel de Linux
66 Qué hacer cuando se recibe un aviso de regresión.
69 Asegúrese de que el programa de gestión de regresiones del kernel de Linux
70 y los subscritos a la lista de correo `regression mailing list
72 conocedores de cualquier nuevo informe de regresión:
75 inmediatamente meterla en el la cadena de emails mandado al menos un
77 añadida en CC de nuevo en caso de que alguna respuesta la omita de la
80 * Si un informe enviado a un gestor de defectos, llega a su correo,
81 reenvíelo o redirijalo a la lista. Considere verificar los archivos de
82 la lista de antemano, si la persona que lo ha informado, lo ha enviado
86 Cuando se realice cualquiera de las acciones anteriores, considere
87 inmediatamente iniciar el seguimiento de la regresión con "regzbot" el
88 gestor de regresiones del kernel de Linux.
92 así, envíe una respuesta (con la lista de regresiones en CC) con un
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
102 Tenga en cuenta que el acento circunflejo (^) antes de "introduced":
106 con etiquetas "Link:" que apunten al al informe de losarchivos de
109 * Cuando mande informes de regresiones a un gestor de defectos, incluya un
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,
142 etiquetas son de gran valor para todos (incluido usted) que pueda estar
145 desarrolladores del kernel o distribuciones de Linux; una de esas
146 herramientas es regzbot, el cual depende mucho de las etiquetas "Link:"
163 kernel por más de dos semanas después de que el causante de una regresión
166 Cómo se ejecuta esto depende mucho de la situación. A continuación se
167 presentan unas reglas generales, en orden de importancia:
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
171 de Linux, a menos que lo último afecte profundamente a efectos de
172 seguridad, o cause errores en los que haya pérdida o daño de datos.
176 forma menos peligrosa y más rápida de arreglar la regresión.
179 soportados de la serie, pero son libres de delegar el trabajo al equipo
182 * Intente resolver cualquier regresión que apareciera en el ciclo de
183 desarrollo antes de que este acabe. Si se teme que una corrección
184 pudiera ser demasiado arriesgada para aplicarla días antes de una
185 liberación de la línea principal de desarrollo, dejar decidir a Linus:
186 mande la corrección a él de forma separada, tan pronto como sea posible
187 con una explicación de la situación. El podrá decidir, y posponer la
191 * Gestione las regresiones en la rama estable, de largo término, o la
192 propia rama principal de las versiones, con más urgencia que la
193 regresiones en las preliberaciones. Esto cambia después de la liberación
194 de la quinta pre-liberación, aka "-rc5": la rama principal entonces se
196 idealmente testeados juntos por al menos una semana antes de que Linux
199 * Intente arreglar regresiones en un intervalo de una semana después de
201 en alguno de los siguientes casos:
205 * en el último ciclo de desarrollo de la rama principal
209 ha de ser abandonada pronto o ya se ha etiquetado como de final de vida
210 (EOL de las siglas en inglés End-of-Life) -- esto sucede usualmente
211 sobre tres o cuatro semanas después de una liberación de una versión en
214 * Intente arreglar cualquier otra regresión en un periodo de dos semanas
215 después de que el culpable haya sido identificado. Dos o tres semanas
216 adicionales son aceptables para regresiones de rendimiento y otros
217 incidentes que son molestos, pero no bloquean a nadie la ejecución de
218 Linux (a menos que se un incidente en el ciclo de desarrollo actual, en
219 ese caso se debería gestionar antes de la liberación de la versión).
224 de largo plazo del kernel.
226 Nota: Los intervalos de tiempo mencionados anteriormente para la resolución
227 de las regresiones, incluyen la verificación de esta, revisión e inclusión
232 Se espera que los maintainers de los subsistemas, ayuden en conseguir esos
234 parches aceptados. Esto puede resultar en tener que mandar peticiones de
235 git-pull antes o de forma más frecuente que lo normal; dependiendo del
237 linux-next. Especialmente para las correcciones en las ramas de los kernels
238 estable y de largo plazo necesitan ser gestionadas rápidamente, y las
239 correcciones necesitan ser incluidas en la rama principal antes de que
246 Cómo tratar con cambios donde se sabe que hay riesgo de regresión
249 Evalué cómo de grande es el riesgo de una regresión, por ejemplo realizando
250 una búsqueda en las distribuciones de linux y en Git forges. Considere
256 Si al final, el riesgo de la regresión parece ser relativamente pequeño,
258 involucradas del posible riesgo. Por tanto, asegúrese de que la descripción
260 integrado, informe al gestor de regresiones de Linux y a las listas de
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.
272 * la finalidad de la "regla de no regresión"
276 * quién es el responsable de identificar la causa raíz de una regresión
279 regresión es causada por una corrección de seguridad o cuando una
282 A quién preguntar por consejo cuando se trata de regresiones
285 Mande un email a la lista de correo de regresiones
286 (regressions@lists.linux.dev) y CC al seguidor de regresiones del kernel de
291 Más sobre la gestión de regresiones con regzbot
294 ¿Por qué el kernel de Linux tiene un gestor de regresiones, y por qué se usa regzbot?
297 Reglas como "no regresiones" necesitan asegurar que se cumplen, de otro
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
302 hacer esto, y esa es la razón por la gestión de regresiones es un servicio
305 Intentos iniciales de gestionar manualmente las regresiones han demostrado
306 que es una tarea extenuante y frustrante, y por esa razón se dejaron de
307 hacer después de un tiempo. Para evitar que volviese a suceder esto,
309 largo plazo de automatizar la gestión de regresiones tanto como fuese
312 ¿Cómo funciona el seguimiento de regresiones con regzbot?
315 El bot monitoriza las respuestas de los informes de las regresiones
319 proporciona una buena imagen del estado actual del proceso de corrección.
330 antes de que regzbot apareciera: añadir las etiquetas "Link:" a la
337 Hacerlo es por el bien de todo el mundo, tanto los mantenedores del kernel,
339 -- por ejemplo cuando deciden liberar una nueva versión o ampliar la fase de
344 ¿He de informar a regzbot cada regresión que encuentre?
349 problema mayor en el kernel de Linux o algo en la vida real que nos mantenga
350 alejados de los teclados por un tiempo. Por eso es mejor informar a regzbot
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
362 noche (UTC), lo cual es unas horas antes de que Linus normalmente anuncie
368 Regzbot supervisa las listas de correo más importantes de Linux, como
369 también las de los repositorios linux-next, mainline y stable/longterm.
372 ¿Qué tipos de incidentes han de ser monitorizados por regzbot?
374 El bot debe hacer seguimiento de las regresiones, y por tanto por favor,
376 el gestor de incidencias de kernel de Linux, monitorizar incidentes
377 graves, como informes sobre cuelgues, corrupción de datos o errores
381 ¿Puedo añadir una regresión detectada por un sistema de CI al seguimiento de regzbot?
384 Siéntase libre de hacerlo, si la regresión en concreto puede tener un
385 impacto en casos de uso prácticos y por tanto ser detectado por los usuarios;
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
400 anterior como el informe de una regresión que se ha de comenzar a monitorizar.
402 Una vez uno de esos dos comandos se ha utilizado, se pueden usar otros
404 escribirlos debajo de uno de los comandos anteriormente usados o en las
411 * Monitorizar una discusión o un tiquet de bugzilla.kernel.org donde
412 aspectos adicionales del incidente o de la corrección se están
419 relacionados al proceso de corrección.
421 * Indicar a un lugar donde más detalles de interés, como un mensaje en una
422 lista de correo o un tiquet en un gestor de incidencias que pueden estar
433 * Identificar una regresión como un duplicado de otra que ya es seguida
446 Hay información más detallada y actualizada sobre el bot de seguimiento de
447 regresiones del kernel de Linux en: `project page <https://gitlab.com/knurd42/regzbot>`_,
448 y entre otros contiene una `guia de inicio <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/ge…
449 y `documentación de referencia <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_
453 Citas de Linus sobre regresiones
456 A continuación se encuentran unos ejemplos reales (traducidos) de como
463 Si rompes la configuración de los espacios de usuario ESO ES UNA REGRESIÓN.
466 de usuario".
477 arreglamos, en vez de echar la culpa al espacio de usuario.
479 El hecho de que aparentemente se haya negado la regresión durante
480 tres semanas, significa que lo revertiré y dejaré de integrar peticiones
481 de apparmor hasta que la gente involucrada entienda como se hace
488 La gente debería sentirse libre de actualizar su kernel y simplemente
498 medios. Quizás no podamos mantener el hardware más, después de que han
500 problema de seguridad serio con cómo hicimos las cosas, y la gente
501 depende de un modelo fundamentalmente roto. Quizás haya algún otro roto
505 Y nótese que esto trata sobre *romper* los entornos de la gente.
507 Cambios de comportamiento pasan, y quizás no se mantengan algunas
508 funcionalidades más. Hay un número de campos en /proc/<pid>/stat que
510 kernel, o porque mostrarlos era un error (típica una fuga de
518 Pero si algo realmente se rompe, entonces el cambio debe de arreglarse
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
522 tenemos un modelo de "actualización". Pero no tenemos una "actualización
523 con el nuevo espacio de usuario".
525 Y yo seriamente me negaré a coger código de gente que no entiende y
531 estoy orgulloso de ello.
534 romper ese caso de uso para poder hacer progresos" o "estabas basandote
536 forma mejor de hacer lo que quieres hacer, y tienes que cambiar a esa
538 de una fase alfa muy temprana que tenga usuarios experimentales que
546 los usos de esa API del kernel. Nadie puede decir "ahora, yo he roto
550 Y nosotros, simplemente, no rompemos el espacio de usuario.
555 Las reglas sobre regresiones nunca han sido sobre ningún tipo de
559 flujo de trabajo del usuario".
569 como "un serio incidente de seguridad" etc que solamente nos fuerza
570 a hacer cambios que pueden romper el espacio de usuario. Pero incluso
577 puñado de usuarios, y estos pueden usar la línea de comandos del
578 kernel para evitarlos"; ese tipo de casos), en esos casos se ha sido
587 El otro lado de la moneda es que la gente que habla sobre "estabilidad
588 de las APIs" están totalmente equivocados. Las APIs tampoco importan.
590 cuando nadie se de cuenta.
592 De nuevo, la regla de las regresiones no trata sobre la documentación,
593 tampoco sobre las APIs y tampoco sobre las fases de la Luna.
595 Únicamente trata sobre "hemos causado problemas al espacio de usuario que
605 Por ejemplo, hacemos cosas como añadir una nueva gestión de
607 tests en el directorio de kselftest.
613 rompe algo en el espacio de usuario. No en algún test. No en
629 El punto de "no hacemos regresiones" es para que la gente pueda
632 > El kernel tiene un bug que ha de ser arreglado
640 Los errores pasan. Eso es un hecho de la vida. Discutir que
642 una locura. Arreglamos decenas de errores cada dia, pensando que
652 ¿Cómo de complicado es eso de comprender?
659 y quizás funcionaba porque el usuario no lo había notado - de nuevo
662 Romper el flujo del trabajo de un usuario, debido a un "bug" es la
669 y sin usuarios, tu programa no es un programa, es una pieza de
673 kernel es "no rompemos el espacio de usuario". Porque "He arreglado
675 rompe el espacio de usuario.
695 Honestamente, la gente de seguridad necesita entender que "no funciona"
696 no es un caso de éxito sobre seguridad. Es un caso de fallo.
704 La compatibilidad de los binarios es más importante.
708 de añadir uuid al /proc/self/mountinfo), entonces es una regresión.
710 Y las regresiones se revierten, a menos que haya problemas de
723 errores de compatibilidad de ese modo. No hay tampoco tantos de esos.
741 > como espacio de usuario estándar.
743 Oh, si el kernel rompe algún espacio de usuario estándar, eso cuenta.
750 (no teniendo en cuenta el propio cambio de versión) justo antes
751 de la liberación, y aunque es bastante incómodo, quizás también es
757 patrones de IO que causaba han acabado revelando una regresión observable
758 desde el espacio de usuario, debido a un error real en un componente
761 De todas maneras, los detalles actuales de esta regresión no son la
764 la regla del kernel de "no regresiones". El commit que ha sido revertido
771 comportamiento reportado en el espacio de usuario, no basado en
772 conceptos como "cambios de ABI" o "provocaba un error". Los mejores
773 patrones de IO que se han presentado debido al cambio únicamente han
775 comportamiento de ese viejo error.
778 patrones de IO una vez hayamos decidido cómo gestionar el hecho de
780 gente dependía de ese comportamiento previo. Es únicamente que
781 tenemos que ver cómo gestionamos y cómo lo hacemos (no hay menos de
782 tres parches diferentes de tres desarrolladores distintos que estamos
784 revertido lo que exponía el problema a los usuarios de esta release,
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
790 de kernel-espacio-de-usuario ABI, o la corrección de un error, o si
792 Es sobre si algo rompe el actual flujo de trabajo del usuario.
795 tema de la regresión. Ya que es la "primera regla de la programación
796 del kernel", me ha parecido que quizás es bueno mencionarlo de