Documentation/translations/sp_SP/process/handling-regressions.rst
Source file repositories/reference/linux-study-clean/Documentation/translations/sp_SP/process/handling-regressions.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/translations/sp_SP/process/handling-regressions.rst- Extension
.rst- Size
- 38259 bytes
- Lines
- 798
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. include:: ../disclaimer-sp.rst
:Translator: Sergio González Collado <sergio.collado@gmail.com>
.. _sp_handling_regressions:
Gestión de regresiones
++++++++++++++++++++++
*No causamos regresiones* -- este documento describe la que es la "primera
regla del desarrollo del kernel de Linux" y que implica en la práctica para
los desarrolladores. Y complementa la documentación:
Documentation/admin-guide/reporting-regressions.rst, que cubre el tema
desde el punto de vista de un usuario; si nunca ha leído ese texto, realice
al menos una lectura rápida del mismo antes de continuar.
Las partes importantes (el "TL;DR")
===================================
#. Asegúrese de que los suscriptores a la lista `regression mailing list
<https://lore.kernel.org/regressions/>`_ (regressions@lists.linux.dev)
son conocedores con rapidez de cualquier nuevo informe de regresión:
* Cuando se reciba un correo que no incluyó a la lista, inclúyalo en la
conversación de los correos, mandando un breve "Reply-all" con la
lista en CCed.
* Mande o redirija cualquier informe originado en los gestores de bugs
a la lista.
#. Haga que el bot del kernel de Linux "regzbot" realice el seguimiento del
incidente (esto es opcional, pero recomendado).
* Para reportes enviados por correo, verificar si contiene alguna línea
como ``#regzbot introduced v5.13..v5.14-rc1``. Si no, mandar una
respuesta (con la lista de regresiones en CC) que contenga un párrafo
como el siguiente, lo que le indica a regzbot cuando empezó a suceder
el incidente::
#regzbot ^introduced 1f2e3d4c5b6a
* Cuando se mandan informes desde un gestor de incidentes a la lista de
regresiones(ver más arriba), incluir un párrafo como el siguiente::
#regzbot introduced: v5.13..v5.14-rc1
#regzbot from: Some N. Ice Human <some.human@example.com>
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
#. Cuando se manden correcciones para las regresiones, añadir etiquetas
"Link:" a la descripción, apuntado a todos los sitios donde se informó
del incidente, como se indica en el documento:
Documentation/process/submitting-patches.rst y
:ref:`Documentation/process/5.Posting.rst <development_posting>`.
#. Intente arreglar las regresiones rápidamente una vez la causa haya sido
identificada; las correcciones para la mayor parte de las regresiones
deberían ser integradas en menos de dos semanas, pero algunas pueden
resolverse en dos o tres días.
Detalles importantes para desarrolladores en la regresiones de kernel de Linux
==============================================================================
Puntos básicos importantes más en detalle
-----------------------------------------
Qué hacer cuando se recibe un aviso de regresión.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Asegúrese de que el programa de gestión de regresiones del kernel de Linux
y los subscritos a la lista de correo `regression mailing list
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.