Lines Matching refs:que
10 *No causamos regresiones* -- este documento describe la que es la "primera
11 regla del desarrollo del kernel de Linux" y que implica en la práctica para
13 Documentation/admin-guide/reporting-regressions.rst, que cubre el tema
20 #. Asegúrese de que los suscriptores a la lista `regression mailing list
24 * Cuando se reciba un correo que no incluyó a la lista, inclúyalo en la
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
37 como el siguiente, lo que le indica a regzbot cuando empezó a suceder
69 Asegúrese de que el programa de gestión de regresiones del kernel de Linux
74 * Cuando se recibe un informe por email que no tiene en CC la lista,
76 breve "Reply-all" con la lista en CC; Intentar asegurar que la lista es
77 añadida en CC de nuevo en caso de que alguna respuesta la omita de la
82 la lista de antemano, si la persona que lo ha informado, lo ha enviado
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":
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
105 seguida. Esto es importante, ya que regzbot buscará más tarde parches
106 con etiquetas "Link:" que apunten al al informe de losarchivos de
116 Regzbot asociará automáticamente parches con el informe que contengan
123 las regresiones únicamente recordar lo que se explica en los documentos:
141 Todo esto se espera y es importante en una regresión, ya que estas
142 etiquetas son de gran valor para todos (incluido usted) que pueda estar
147 para asociar los informes por regresiones con los cambios que las
157 * Ejecutar el kernel con una regresión que afecta seriamente al uso.
160 soportada del kernel que no tenga las funcionalidades requeridas.
163 kernel por más de dos semanas después de que el causante de una regresión
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.
175 después, junto con las correcciones necesarias, ya que esto puede la
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
192 propia rama principal de las versiones, con más urgencia que la
195 vuelve más importante, asegurar que todas las mejoras y correcciones son
196 idealmente testeados juntos por al menos una semana antes de que Linux
200 que se ha identificado el responsable, si el incidente fue introducido
215 después de que el culpable haya sido identificado. Dos o tres semanas
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
229 "linux-next" al menos brevemente. Esto conllevará retrasos que también se
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
239 correcciones necesitan ser incluidas en la rama principal antes de que
243 Más aspectos sobre regresiones que los desarrolladores deben saber
246 Cómo tratar con cambios donde se sabe que hay riesgo de regresión
251 también preguntar a otros desarrolladores o proyectos que pudieran ser
258 involucradas del posible riesgo. Por tanto, asegúrese de que la descripción
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
263 del riesgo, quizás se quiera preguntar al mantenedor del subsistema, que
266 ¿Qué más hay que saber sobre regresiones?
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
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,
310 posible para cualquiera que estuviese involucrado.
317 que hagan referencia a esos informes con la etiqueta: "Link:"; respuestas a
322 posible tanto para la gente que lo reporta, como para los desarrolladores.
328 Para los desarrolladores normalmente no hay un trabajo adicional que
329 realizar, únicamente necesitan asegurarse una cosa, que ya se hacía mucho
330 antes de que regzbot apareciera: añadir las etiquetas "Link:" a la
334 ¿Tengo que usar regzbot?
340 desarrollo. Para esto necesitan conocer todas las regresiones que están sin
341 corregir; para esto, es conocido que Linux mira los informes semanales que
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
352 los mandamos al árbol de desarrollo en el que se integran habitualmente a
362 noche (UTC), lo cual es unas horas antes de que Linus normalmente anuncie
386 Así, por favor no involucre a regzbot en regresiones teóricas que
396 Por ejemplo ``#regzbot introduced <version or commit>``, que hace que regzbot
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:
413 comentando -- por ejemplo presentar un parche que corrige la regresión::
422 lista de correo o un tiquet en un gestor de incidencias que pueden estar
427 * Identificar una regresión como corregida por un commit que se ha mandado
433 * Identificar una regresión como un duplicado de otra que ya es seguida
443 ¿Algo más que decir sobre regzbot y sus comandos?
450 Ambos contienen más detalles que las secciones anteriores.
457 Linus Torvalds espera que se gestionen las regresiones:
476 y el corolario es que cuando una regresión pasa, lo admitimos y lo
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
493 la regla es que continúe trabajando para tí.
496 generalmente tienen una razón fundamental para haber sucedido, que era
498 medios. Quizás no podamos mantener el hardware más, después de que han
502 fundamental, que tenga que tener una _flag_ y por razones internas y
505 Y nótese que esto trata sobre *romper* los entornos de la gente.
508 funcionalidades más. Hay un número de campos en /proc/<pid>/stat que
511 información). Pero los números se sustituyeron por ceros, así que
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
516 (o que no es ya importante).
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
525 Y yo seriamente me negaré a coger código de gente que no entiende y
530 Y sí, me doy cuenta que el kernel es "especial" en este respecto. Y
533 Y he visto, y puedo señalar, muchos proyectos que dicen "Tenemos que
536 forma mejor de hacer lo que quieres hacer, y tienes que cambiar a esa
537 nueva forma", y yo simplemente no pienso que eso sea aceptable fuera
538 de una fase alfa muy temprana que tenga usuarios experimentales que
539 saben a lo que se han apuntado. El kernel no ha estado en esta
545 gente que hace esto entonces tendrá obviamente que arreglar todos
547 la API que usas, y ahora tú necesitas arreglarlo". Quién rompa algo,
561 Los usuarios son literalmente la _única_ cosa que importa.
564 comportamiento es indefinido, es su culpa que su aplicación no
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
571 entonces la regla es que realmente no hay otras opciones para que
574 Y obviamente, si los usuarios tardan años en darse cuenta que algo
575 se ha roto, o si hay formas adecuadas para sortear la rotura que
581 Pero no, "eso que está documentado que está roto" (si es dado a que
583 es irrelevante. Si preparar el código es tan útil que la gente,
584 acaba usando, esto implica que básicamente es código del kernel con
587 El otro lado de la moneda es que la gente que habla sobre "estabilidad
589 Se puede hacer cualquier cambio que se quiera a una API ... siempre y
595 Únicamente trata sobre "hemos causado problemas al espacio de usuario que
602 no cambia". Eso podría significar que nunca podríamos hacer ningún
609 Así que claramente cambia el comportamiento todo el tiempo y
624 Y la razón que apuntas en tú opinión es exactamente *PORQUÉ* estás
629 El punto de "no hacemos regresiones" es para que la gente pueda
630 actualizar el kernel y nunca tengan que preocuparse por ello.
632 > El kernel tiene un bug que ha de ser arreglado
640 Los errores pasan. Eso es un hecho de la vida. Discutir que
641 "tenemos que romper algo porque estábamos arreglando un error" es
642 una locura. Arreglamos decenas de errores cada dia, pensando que
643 "arreglando un bug" significa que podemos romper otra cosa es algo
644 que simplemente NO ES VERDAD.
646 Así que los bugs no son realmente relevantes para la discusión. Estos
647 suceden y se detectan, se arreglan, y no tienen nada que ver con
650 Porque la única cosa que importa ES EL USUARIO.
654 Cualquier persona que use "pero no funcionaba correctamente" es
663 PEOR razón que se pueda usar.
665 Es básicamente decir "He cogido algo que funcionaba, y lo he roto,
666 pero ahora es mejor". ¿No ves que un argumento como este es j*didamente
670 código sin finalidad que puedes perfectamente tirar a la basura.
682 kernel no actualizo al azar otras herramientas que ni siquiera me
683 importan como desarrollador del kernel, y yo quiero que mis usuarios
686 Así que no. Tu regla está COMPLETAMENTE equivocada. Si no puedes
695 Honestamente, la gente de seguridad necesita entender que "no funciona"
710 Y las regresiones se revierten, a menos que haya problemas de
711 seguridad o similares que nos hagan decir "Dios mío, realmente
712 tenemos que romper las cosas".
718 Si se crea un interface que puede usarse sin parsear la
734 Tenemos programas que usan esa ABI y si eso se rompe eso es una
754 Lo que es instructivo sobre esto es que he revertido un commit que no
755 tenía ningún error. De hecho, hacía exactamente lo que pretendía, y lo
756 hacía muy bien. De hecho lo hacía _tan_ bien que los muy mejorados
757 patrones de IO que causaba han acabado revelando una regresión observable
762 razón por la que señalo esto como instructivo. Es más que es un ejemplo
763 ilustrativo sobre lo que cuenta como una regresión, y lo que conlleva
764 la regla del kernel de "no regresiones". El commit que ha sido revertido
766 Pero acabó exponiendo otro problema, y como eso causaba que la
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
773 patrones de IO que se han presentado debido al cambio únicamente han
777 Y que no haya miedo, reintroduciremos el arreglo que mejoraba los
779 que hay una interacción incorrecta con un interfaz en el que la
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,
785 incluso cuando espero que el fix será reintroducido (quizás insertado
789 Lo que hay que recordar de todo el asunto no es sobre si el cambio
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