Documentation/translations/sp_SP/process/submit-checklist.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/sp_SP/process/submit-checklist.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/sp_SP/process/submit-checklist.rst
Extension
.rst
Size
6059 bytes
Lines
135
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.

Dependency Surface

Detected Declarations

Annotated Snippet

.. include:: ../disclaimer-sp.rst

:Original: Documentation/process/submit-checklist.rst
:Translator: Avadhut Naik <avadhut.naik@amd.com>

.. _sp_submitchecklist:

Lista de comprobación para enviar parches del kernel de Linux
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Aquí hay algunas cosas básicas que los desarrolladores deben hacer si
quieren que sus envíos de parches del kernel sean aceptados más
rápidamente.

Todo esto está más allá de la documentación que se proporciona en
:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`
y en otros lugares con respecto al envío de parches del kernel de Linux.

1) Si utiliza una funcionalidad, #include el archivo que define/declara
   esa funcionalidad. No dependa de otros archivos de encabezado que
   extraigan los que utiliza.

2) Compile limpiamente:

  a) Con las opciones ``CONFIG`` aplicables o modificadas ``=y``, ``=m``,
     y ``=n``. Sin advertencias/errores del compilador ``gcc``, ni
     advertencias/errores del linker.

  b) Aprobar ``allnoconfig``, ``allmodconfig``

  c) Compila correctamente cuando se usa ``O=builddir``

  d) Cualquier documentación o cambios se compilan correctamente sin
     nuevas advertencias/errores. Utilice ``make htmldocs`` o
     ``make pdfdocs`` para comprobar la compilación y corregir cualquier
     problema.

3) Se compila en varias arquitecturas de CPU mediante herramientas de
   compilación cruzada locales o alguna otra granja de compilación.

4) ppc64 es una buena arquitectura para verificar la compilación cruzada
   por que tiende a usar ``unsigned long`` para cantidades de 64-bits.

5) Verifique su parche para el estilo general según se detalla en
   :ref:`Documentation/translations/sp_SP/process/coding-style.rst <sp_codingstyle>`.
   Verifique las infracciones triviales con el verificador de estilo de
   parches antes de la entrega (``scripts/checkpatch.pl``).
   Debería ser capaz de justificar todas las infracciones que permanezcan
   en su parche.

6) Cualquier opción ``CONFIG`` nueva o modificada no altera el menú de
   configuración y se desactiva por defecto, a menos que cumpla con los
   criterios de excepción documentados en
   ``Documentation/kbuild/kconfig-language.rst`` Atributos del menú: valor por defecto.

7) Todas las nuevas opciones de ``Kconfig`` tienen texto de ayuda.

8) Ha sido revisado cuidadosamente con respecto a las combinaciones
   relevantes de ``Kconfig``. Esto es muy difícil de hacer correctamente
   con las pruebas -- la concentración mental da resultados aquí.

9) Verifique limpiamente con sparse.

10) Use ``make checkstack`` y solucione cualquier problema que encuentre.

    .. note::

       ``checkstack`` no señala los problemas explícitamente, pero
       cualquier función que use más de 512 bytes en la pila es
       candidata para el cambio.

Annotation

Implementation Notes