Lines Matching refs:para
11 regla del desarrollo del kernel de Linux" y que implica en la práctica para
49 #. Cuando se manden correcciones para las regresiones, añadir etiquetas
56 identificada; las correcciones para la mayor parte de las regresiones
60 Detalles importantes para desarrolladores en la regresiones de kernel de Linux
104 respondido) como el informeinicial para la regresión que quiere ser
122 No se necesita hacer nada especial cuando se mandan las correcciones para
134 * Añada la etiqueta "Fixes:" para indicar el commit causante de la
138 marque explícitamente el fix para retro-importarlo usando la etiqueta
142 etiquetas son de gran valor para todos (incluido usted) que pueda estar
144 también cruciales para las herramientas y scripts usados por otros
147 para asociar los informes por regresiones con los cambios que las
154 Al final, los desarrolladores deberían hacer lo posible para evitar a los
184 pudiera ser demasiado arriesgada para aplicarla días antes de una
216 adicionales son aceptables para regresiones de rendimiento y otros
226 Nota: Los intervalos de tiempo mencionados anteriormente para la resolución
237 linux-next. Especialmente para las correcciones en las ramas de los kernels
252 afectados para evaluar o incluso testear el cambio propuesto; si
254 para todos.
299 que esto es verdad también para el kernel de Linux. Esto es por lo que
300 Thorsten Leemhuis se ofreció como voluntario para dar una solución a esto,
308 Thorsten desarrollo regbot para facilitar el trabajo, con el objetivo a
310 posible para cualquiera que estuviese involucrado.
322 posible tanto para la gente que lo reporta, como para los desarrolladores.
323 De hecho, solo los informantes son requeridos para una tarea adicional:
338 como Linus Torvalds dependen parcialmente en regzbot para seguir su trabajo
341 corregir; para esto, es conocido que Linux mira los informes semanales que
359 para ver la última información; o `busque el último informe de regresiones
375 no involucre a regzbot para incidencias normales. Pero es correcto para
417 Monitorizar solamente funciona para lore.kernel.org y bugzilla.kernel.org;
492 el kernel si actualiza otro programa". Si el kernel trabaja para tí,
493 la regla es que continúe trabajando para tí.
496 generalmente tienen una razón fundamental para haber sucedido, que era
512 el código que se usaba para parsear esos campos todavía existe. El
534 romper ese caso de uso para poder hacer progresos" o "estabas basandote
571 entonces la regla es que realmente no hay otras opciones para que
575 se ha roto, o si hay formas adecuadas para sortear la rotura que
576 no causen muchos problemas para los usuarios (por ejemplo: "hay un
578 kernel para evitarlos"; ese tipo de casos), en esos casos se ha sido
612 La regla para regresiones para el kernel es para cuando se
629 El punto de "no hacemos regresiones" es para que la gente pueda
646 Así que los bugs no son realmente relevantes para la discusión. Estos
656 erróneo - funcionaba para él/ella.
660 no importa. Funcionaba para el usuario.
672 Seriamente. Esto es *porque* la regla #1 para el desarrollo del
706 Y si los binarios no usan el interfaz para parsear el formato
714 No entiendo porqué esta simple lógica es tan difícil para algunos
767 actualización del kernel fallara para el usuario. Así que ha sido