Lines Matching refs:se
24 * Cuando se reciba un correo que no incluyó a la lista, inclúyalo en la
42 * Cuando se mandan informes desde un gestor de incidentes a la lista de
49 #. Cuando se manden correcciones para las regresiones, añadir etiquetas
50 "Link:" a la descripción, apuntado a todos los sitios donde se informó
51 del incidente, como se indica en el documento:
66 Qué hacer cuando se recibe un aviso de regresión.
74 * Cuando se recibe un informe por email que no tiene en CC la lista,
83 anteriormente, como se indica en:
86 Cuando se realice cualquiera de las acciones anteriores, considere
90 * Para los informes enviados por email, verificar si se ha incluido un
119 Qué es importante cuando se corrigen regresiones
122 No se necesita hacer nada especial cuando se mandan las correcciones para
123 las regresiones únicamente recordar lo que se explica en los documentos:
128 * Apunte a todos los lugares donde el incidente se reportó usando la
141 Todo esto se espera y es importante en una regresión, ya que estas
166 Cómo se ejecuta esto depende mucho de la situación. A continuación se
183 desarrollo antes de que este acabe. Si se teme que una corrección
194 de la quinta pre-liberación, aka "-rc5": la rama principal entonces se
200 que se ha identificado el responsable, si el incidente fue introducido
209 ha de ser abandonada pronto o ya se ha etiquetado como de final de vida
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).
222 unos pocos usuarios; también está bien si se usa tanto tiempo como fuera
229 "linux-next" al menos brevemente. Esto conllevará retrasos que también se
246 Cómo tratar con cambios donde se sabe que hay riesgo de regresión
253 apareciesen problemas, quizás se pudiera encontrar una solución aceptable
259 del parche, se hace explícito este hecho. Una vez el cambio ha sido
263 del riesgo, quizás se quiera preguntar al mantenedor del subsistema, que
274 * qué incidencias no se califican como regresión
282 A quién preguntar por consejo cuando se trata de regresiones
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
298 modo se romperían accidentalmente o a propósito. La historia ha mostrado
300 Thorsten Leemhuis se ofreció como voluntario para dar una solución a esto,
301 con el gestor de regresiones del kernel de Linux. A nadie se le paga por
306 que es una tarea extenuante y frustrante, y por esa razón se dejaron de
316 identificadas. Adicionalmente mira si se han publicado o enviado parches
318 esos parches también se siguen. Combinando esta información, también
329 realizar, únicamente necesitan asegurarse una cosa, que ya se hacía mucho
352 los mandamos al árbol de desarrollo en el que se integran habitualmente a
397 considere el correo como un informe de regressión que se ha de añadir al
398 seguimiento, como se ha descrito anteriormente; ``#regzbot ^introduced <version or commit>``
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
405 respuestas al correo en el que se uso como respuesta a ese correo:
412 aspectos adicionales del incidente o de la corrección se están
427 * Identificar una regresión como corregida por un commit que se ha mandado
428 aguas arriba o se ha publicado::
456 A continuación se encuentran unos ejemplos reales (traducidos) de como
457 Linus Torvalds espera que se gestionen las regresiones:
479 El hecho de que aparentemente se haya negado la regresión durante
481 de apparmor hasta que la gente involucrada entienda como se hace
507 Cambios de comportamiento pasan, y quizás no se mantengan algunas
509 se imprimen como ceros, simplemente porque ni siquiera existen ya en
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
515 _funcionan_, incluso si no se puede mostrar información sensible
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
533 Y he visto, y puedo señalar, muchos proyectos que dicen "Tenemos que
539 saben a lo que se han apuntado. El kernel no ha estado en esta
575 se ha roto, o si hay formas adecuadas para sortear la rotura que
578 kernel para evitarlos"; ese tipo de casos), en esos casos se ha sido
585 una señal diciendo "por favor limpiar esto".
589 Se puede hacer cualquier cambio que se quiera a una API ... siempre y
590 cuando nadie se de cuenta.
610 nosotros no consideramos eso una regresión per se.
612 La regla para regresiones para el kernel es para cuando se
647 suceden y se detectan, se arreglan, y no tienen nada que ver con
663 PEOR razón que se pueda usar.
684 se sientan a salvo haciendo lo mismo.
710 Y las regresiones se revierten, a menos que haya problemas de
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
762 razón por la que señalo esto como instructivo. Es más que es un ejemplo
773 patrones de IO que se han presentado debido al cambio únicamente han
787 acuerdo sobre cómo se ha de exponer el error.