Lines Matching full:en
11 regla del desarrollo del kernel de Linux" y que implica en la práctica para
24 * Cuando se reciba un correo que no incluyó a la lista, inclúyalo en la
26 lista en CCed.
28 * Mande o redirija cualquier informe originado en los gestores de bugs
36 respuesta (con la lista de regresiones en CC) que contenga un párrafo
51 del incidente, como se indica en el documento:
57 deberían ser integradas en menos de dos semanas, pero algunas pueden
58 resolverse en dos o tres días.
60 Detalles importantes para desarrolladores en la regresiones de kernel de Linux
63 Puntos básicos importantes más en detalle
74 * Cuando se recibe un informe por email que no tiene en CC la lista,
75 inmediatamente meterla en el la cadena de emails mandado al menos un
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
83 anteriormente, como se indica en:
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":
123 las regresiones únicamente recordar lo que se explica en los documentos:
137 * Si el culpable ha sido "mergeado" en un ciclo de desarrollo anterior,
141 Todo esto se espera y es importante en una regresión, ya que estas
143 mirando en ese incidente semanas, meses o años después. Estas etiquetas son
151 Priorización del trabajo en arreglar regresiones
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
172 seguridad, o cause errores en los que haya pérdida o daño de datos.
178 * Los desarrolladores deberían gestionar la regresión en todos los kernels
180 permanente el incidente no hubiese ocurrido en la línea principal.
182 * Intente resolver cualquier regresión que apareciera en el ciclo de
191 * Gestione las regresiones en la rama estable, de largo término, o la
193 regresiones en las preliberaciones. Esto cambia después de la liberación
197 libere la nueva versión en la rama principal.
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
207 En el último caso (por ejemplo v5.14), intentar gestionar las
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
218 Linux (a menos que se un incidente en el ciclo de desarrollo actual, en
223 necesario si la regresión está presente en la segunda versión más nueva
228 en la rama principal, idealmente con la corrección incluida en la rama
230 tienen tener en cuenta.
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
236 arreglo, podría incluso ser aceptable saltarse la verificación en
237 linux-next. Especialmente para las correcciones en las ramas de los kernels
239 correcciones necesitan ser incluidas en la rama principal antes de que
250 una búsqueda en las distribuciones de linux y en Git forges. Considere
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.
270 esta cubre otros aspectos a tener a en cuenta y conocer:
288 gestionarlo en privado, puede omitirse la lista.
338 como Linus Torvalds dependen parcialmente en regzbot para seguir su trabajo
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
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;
386 Así, por favor no involucre a regzbot en regresiones teóricas que
387 difícilmente pudieran manifestarse en un uso real.
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
394 párrafo (debe estar separado del resto del texto usando líneas en blanco):
403 comandos regzbot en respuestas directas o indirectas al informe. Puede
404 escribirlos debajo de uno de los comandos anteriormente usados o en las
405 respuestas al correo en el que se uso como respuesta a ese correo:
418 regzbot considerará todos los mensajes en ese hilo o el tiquet como
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
447 regresiones del kernel de Linux en: `project page <https://gitlab.com/knurd42/regzbot>`_,
477 arreglamos, en vez de echar la culpa al espacio de usuario.
508 funcionalidades más. Hay un número de campos en /proc/<pid>/stat que
509 se imprimen como ceros, simplemente porque ni siquiera existen ya en
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
530 Y sí, me doy cuenta que el kernel es "especial" en este respecto. Y
535 en comportamientos no documentados, debe ser duro ser tú" o "hay una
539 saben a lo que se han apuntado. El kernel no ha estado en esta
540 situación en las dos últimas décadas.
558 Las reglas sobre regresiones son siempre sobre "roturas en el
574 Y obviamente, si los usuarios tardan años en darse cuenta que algo
578 kernel para evitarlos"; ese tipo de casos), en esos casos se ha sido
582 el código estaba en preparación o porque el manual dice otra cosa) eso
607 tests en el directorio de kselftest.
613 rompe algo en el espacio de usuario. No en algún test. No en
624 Y la razón que apuntas en tú opinión es exactamente *PORQUÉ* estás
658 Quizás funcionaba *porque* el usuario había tenido el bug en cuenta,
678 programa en absoluto. Y esto es absolutamente necesario, porque
698 Sí, "no funciona" puede ser seguro. Pero en este caso es totalmente
719 descripción del interface, entonces estaḿos atascados en el interface.
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
759 no relacionado en absoluto.
765 no cambiaba ninguna API, y no introducía ningún error nuevo en el código.
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
779 que hay una interacción incorrecta con un interfaz en el que la
791 el código antiguo "en primer lugar nunca debería haber estado ahí".
794 De todas formas, esto era mi pequeña aclaración en todo este
797 vez en cuando.