Documentation/translations/sp_SP/process/6.Followthrough.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/sp_SP/process/6.Followthrough.rst

File Facts

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

.. _sp_development_followthrough:

Seguimiento
===========

Llegados a este punto, ha seguido las directrices dadas hasta ahora, lo que
sumado a sus propias habilidades de ingeniería, ha resultado en una serie
de parches perfectos. Uno de los mayores errores que incluso los
desarrolladores de kernel experimentados pueden cometer es concluir que su
trabajo ya está hecho. En verdad, publicar parches indica una transición a
la siguiente etapa del proceso, con, posiblemente, bastante trabajo aún por
hacer.

Es raro un parche que sea tan bueno en su primera publicación que no haya
espacio para la mejora. El proceso de desarrollo del kernel reconoce este
hecho y, como resultado, está muy orientado hacia la mejora del código
publicado. Y usted, como autor de ese código, se espera que trabaje con la
comunidad del kernel para asegurarse de que su código esté a la altura de
los estándares de calidad del kernel. No participar en este proceso es muy
probable que impida la inclusión de sus parches en la línea principal.

Trabajando con revisores
------------------------

Un parche de cualquier importancia resultará en una serie de comentarios de
otros desarrolladores a medida que revisan el código. Trabajar con los
revisores puede ser, para muchos desarrolladores, la parte más intimidante
del proceso de desarrollo del kernel. Sin embargo, la vida puede ser mucho
más fácil si tiene en cuenta algunas cosas:

- Si ha explicado bien su parche, los revisores entenderán su valor y por
  qué se tomó la molestia de escribirlo. Pero ese valor no les impedirá
  hacer una pregunta fundamental: ¿cómo será mantener un kernel con este
  código en él cinco o diez años después? Muchos de los cambios que se le
  pueden pedir que haga, desde ajustes de estilo de codificación hasta
  reescrituras sustanciales, provienen de la comprensión de que Linux
  seguirá existiendo y en desarrollo dentro de una década.

- La revisión de código es un trabajo arduo y es una ocupación
  relativamente ingrata; la gente recuerda quién escribió el código del
  kernel, pero hay poca fama duradera para aquellos que lo revisaron. Así
  que los revisores pueden ponerse de mal humor, especialmente cuando ven
  los mismos errores repetirse una y otra vez. Si recibe una revisión que
  parece enojada, insultante o abiertamente ofensiva, resista el impulso de
  responder de la misma manera. La revisión de código se trata del código,
  no de las personas, y los revisores de código no lo están atacando
  personalmente.

- De manera similar, los revisores de código no están tratando de promover
  las agendas de sus empleadores a expensas de la suya. Los desarrolladores
  del kernel a menudo esperan estar trabajando en el kernel dentro de
  varios años, pero entienden que su empleador podría cambiar.
  Verdaderamente, casi sin excepción, están trabajando hacia la creación
  del mejor kernel posible; no están tratando de causar incomodidad a los
  competidores de sus empleadores.

- Esté preparado para solicitudes aparentemente ridículas de cambios en el
  estilo de codificación y solicitudes para factorizar parte de su código
  en partes compartidas del kernel. Una de las tareas que realizan los
  maintainers es mantener las cosas con una apariencia uniforme. A veces, esto significa que el truco ingenioso en su driver para sortear un problema necesita convertirse en una característica generalizada del kernel lista para la próxima vez.

En resumen, cuando los revisores le envían comentarios, necesita prestar
atención a las observaciones técnicas que están haciendo. No permita que su
forma de expresarse o su propio orgullo le impidan hacerlo. Cuando reciba
comentarios de revisión sobre un parche, tómese el tiempo para entender lo

Annotation

Implementation Notes