Documentation/translations/sp_SP/process/5.Posting.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/sp_SP/process/5.Posting.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/sp_SP/process/5.Posting.rst
Extension
.rst
Size
20019 bytes
Lines
392
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/5.Posting.rst
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com>

.. _sp_development_posting:

Publicación de parches
======================

Tarde o temprano, llega el momento en que su trabajo esté listo para ser
presentado a la comunidad para su revisión y, eventualmente, su inclusión
en el kernel mainline. Como era de esperar, la comunidad de desarrollo del
kernel ha desarrollado un conjunto de convenciones y procedimientos que se
utilizan en la publicación de parches; seguirlos hará la vida mucho más
fácil para todos los involucrados. Este documento intentará cubrir estas
expectativas con un detalle razonable; también se puede encontrar más
información en los archivos.
:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`
and :ref:`Documentation/translations/sp_SP/process/submit-checklist.rst <sp_submitchecklist>`

Cuando publicar
---------------

Hay una tentación constante de evitar publicar parches antes de que
estén completamente “listos”. Para parches simples, eso no es un
problema. Sin embargo, si el trabajo que se está realizando es complejo,
hay mucho que ganar al obtener comentarios de la comunidad antes de que
se complete el trabajo. Por lo tanto, se debería considerar publicar
trabajo en progreso, o incluso poner a disposición un árbol de git para
que los desarrolladores interesados puedan ponerse al día con su trabajo
en cualquier momento.

Al publicar código que aún no se considera listo para su inclusión, es
una buena idea decirlo en la propia publicación. Además, mencione
cualquier trabajo importante que aún falte por hacer y cualquier problema
conocido. Menos personas mirarán los parches que se sabe que están a
medias, pero aquellos que lo hagan vendrán con la idea de que pueden
ayudarlo a llevar el trabajo en la dirección correcta.

Antes de crear parches
----------------------

Se deben hacer varias cosas antes de considerar enviar parches a la
comunidad de desarrollo. Estas incluyen:

 - Pruebe el código en la medida de lo posible. Utilice las herramientas
   de depuración del kernel, asegúrese de que el kernel se compilará con
   todas las combinaciones razonables de opciones de configuración, use
   compiladores cruzados para compilar para diferentes arquitecturas, etc.

 - Asegúrese de que su código cumpla con las directrices de estilo de
   codificación del kernel.

 - ¿Su cambio tiene implicaciones de rendimiento? Si es así, debe ejecutar
   puntos de referencia que muestren cuál es el impacto (o beneficio) de
   su cambio; se debe incluir un resumen de los resultados con el parche.

 - Asegúrese de que tiene derecho a publicar el código. Si este trabajo
   se realizó para un empleador, es probable que el empleador tenga
   derecho al trabajo y debe estar de acuerdo con su lanzamiento bajo la
   GPL.

Como regla general, pensar un poco más antes de publicar el código casi
siempre compensa el esfuerzo en poco tiempo.

Preparación del parche
----------------------

La preparación de parches para su publicación puede ser una cantidad

Annotation

Implementation Notes