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

.. 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
que el revisor está tratando de decir. Si es posible, arregle las cosas que
el revisor le está pidiendo que corrija. Y responda al revisor:
agradézcales y describa cómo responderá a sus preguntas.

Tenga en cuenta que no tiene que estar de acuerdo con cada cambio sugerido
por los revisores. Si cree que el revisor ha malinterpretado su código,
explique lo que realmente está sucediendo. Si tiene una objeción técnica a
un cambio sugerido, descríbalo y justifique su solución al problema. Si sus
explicaciones tienen sentido, el revisor las aceptará. Sin embargo, si su
explicación no resulta persuasiva, especialmente si otros comienzan a estar
de acuerdo con el revisor, tómese un tiempo para reflexionar nuevamente
sobre las cosas. Puede ser fácil quedar cegado por su propia solución a un
problema hasta el punto de no darse cuenta de que algo está
fundamentalmente mal o, quizás, ni siquiera está resolviendo el problema
correcto.

Andrew Morton ha sugerido que cada comentario de revisión que no resulte en
un cambio de código debería resultar en un comentario adicional en el
código; eso puede ayudar a los revisores futuros a evitar las preguntas que
surgieron la primera vez.

Un error fatal es ignorar los comentarios de revisión con la esperanza de
que desaparezcan. No desaparecerán. Si vuelve a publicar código sin haber
respondido a los comentarios que recibió la vez anterior, es probable que
descubra que sus parches no van a ninguna parte.

Hablando de volver a publicar código: tenga en cuenta que los revisores no
recordarán todos los detalles del código que publicó la vez anterior. Así
que siempre es una buena idea recordarles sobre problemas planteados
anteriormente y cómo los manejó; el registro de cambios del parche es un
buen lugar para este tipo de información. Los revisores no deberían tener
que buscar en los archivos de la lista para familiarizarse con lo que se
dijo la última vez; si les ayuda a tener un buen comienzo, estarán de mejor
humor cuando revisiten su código.

¿Qué sucede si ha intentado hacer todo bien y las cosas aún no van a
ninguna parte? La mayoría de los desacuerdos técnicos pueden resolverse
mediante discusión, pero hay momentos en los que alguien simplemente tiene
que tomar una decisión. Si realmente cree que esta decisión está en su
contra de manera incorrecta, siempre puede intentar apelar a una autoridad
superior. En el momento de escribir esto, esa autoridad superior tiende a
ser Andrew Morton. Andrew tiene un gran respeto en la comunidad de
desarrollo del kernel; a menudo puede desbloquear una situación que parece
estar irremediablemente bloqueada. Sin embargo, apelar a Andrew no debe
hacerse a la ligera, y no antes de que se hayan explorado todas las demás
alternativas. Y tenga en cuenta, por supuesto, que él puede no estar de
acuerdo con usted tampoco.

¿Qué pasa después?
--------------------

Si un parche se considera algo bueno para agregar al kernel, y una vez que
se hayan resuelto la mayoría de los problemas de revisión, el siguiente
paso suele ser la entrada en el árbol del mantenedor de un subsistema. Cómo
funciona eso varía de un subsistema a otro; cada mantenedor tiene su propia
forma de hacer las cosas. En particular, puede haber más de un árbol, uno,
quizás, dedicado a los parches planificados para la próxima ventana de
fusión y otro para trabajos a más largo plazo.

Para los parches que se aplican a áreas para las que no hay un árbol de
subsistema obvio (parches de gestión de memoria, por ejemplo), el árbol
predeterminado suele ser -mm. Los parches que afectan a múltiples
subsistemas también pueden terminar pasando por el árbol -mm.

La inclusión en un árbol de subsistema puede dar mayor visibilidad a un
parche. Ahora, otros desarrolladores que trabajan con ese árbol recibirán
el parche por defecto. Los árboles de subsistemas típicamente alimentan
linux-next también, haciendo que su contenido sea visible para la comunidad
de desarrollo en su conjunto. En este punto, hay una buena probabilidad de
que reciba más comentarios de un nuevo conjunto de revisores; estos
comentarios necesitan ser respondidos como en la ronda anterior.

Lo que también puede suceder en este punto, dependiendo de la naturaleza de
su parche, es que aparezcan conflictos con el trabajo que están realizando
otros. En el peor de los casos, conflictos pesados de parches pueden
resultar en que algunos trabajos se pongan en espera para que los parches
restantes puedan ser ajustados y fusionados. Otras veces, la resolución de
conflictos involucrará trabajar con otros desarrolladores y, posiblemente,
mover algunos parches entre árboles para asegurarse de que todo se aplique
sin problemas. Este trabajo puede ser un dolor, pero cuente sus
bendiciones: antes de la llegada del árbol linux-next, estos conflictos a
menudo solo surgían durante la ventana de fusión y tenían que ser abordados
de prisa. Ahora pueden resolverse con calma, antes de que se abra la
ventana de fusión (merge window).

Algún día, si todo va bien, iniciará sesión y verá que su parche ha sido
incluido en el kernel principal. ¡Felicidades! Una vez que la celebración
termine (y se hayas agregado al archivo MAINTAINERS), vale la pena
recordar un pequeño hecho importante: el trabajo aún no está hecho. La
inclusión trae sus propios desafíos.

Para empezar, la visibilidad de su parche ha aumentado una vez más. Puede
haber una nueva ronda de comentarios de desarrolladores que no estaban al
tanto del parche antes. Puede ser tentador ignorarlos, ya que ya no hay
cuestión de que su código sea fusionado. Sin embargo, resista esa
tentación; aún necesita ser receptivo a los desarrolladores que tienen
preguntas o sugerencias.

Más importante aún, la inclusión en la línea principal pone su código en
manos de un grupo mucho más grande de probadores. Incluso si ha contribuido
un driver para hardware que aún no está disponible, se sorprenderá de
cuántas personas construirán su código en sus kernels. Y, por supuesto,
donde hay probadores, habrá informes de errores.

El peor tipo de informes de errores son las regresiones. Si su parche causa
una regresión, encontrará un número incómodo de ojos sobre usted; las
regresiones pueden dar lugar a mucho malestar en la comunidad y pueden
hacer que algunos desarrolladores comiencen a preguntarse si su parche
realmente debería haber sido fusionado en primer lugar. Así que esté atento
a los comentarios sobre problemas y, si es posible, corrija los errores de
inmediato.

Después de haber abordado cualquier regresión, puede haber otros errores
ordinarios que resolver. El período de estabilización es su mejor
oportunidad para corregir estos errores y garantizar que el debut de su
código en una versión del kernel principal sea lo más sólido posible. Así
que, por favor, responda a los informes de errores y solucione los
problemas si es posible. Para eso es el período de estabilización; puede
comenzar a crear parches nuevos y geniales una vez que se hayan resuelto
los problemas de los antiguos.

Y no olvide que hay otros hitos que también pueden generar informes de
errores: la próxima versión estable del kernel principal, cuando
distribuidores prominentes adopten una versión del kernel que contenga su
parche, etc. Continuar respondiendo a estos informes es una cuestión de
orgullo básico en su trabajo. Sin embargo, si eso no es suficiente
motivación, también vale la pena considerar que la comunidad de desarrollo
recuerda a los desarrolladores que pierden interés en su código después de
que se fusiona. La próxima vez que publique un parche, lo evaluarán con la
suposición de que no estará disponible para mantenerlo después.

Otras cosas que pueden suceder
-------------------------------

Un día, puede que abra su cliente de correo y vea que alguien le ha enviado
un parche para su código. Esa es una de las ventajas de tener su código
disponible públicamente, después de todo. Si está de acuerdo con el parche, puede reenviarlo al maintainer del subsistema (asegúrese de incluir una
línea From: adecuada para que la atribución sea correcta, y añada su propia
firma), o enviar una respuesta Acked-by: y dejar que el autor original lo
envíe hacia arriba.

Si no está de acuerdo con el parche, envíe una respuesta educada explicando
por qué. Si es posible, dígale al autor qué cambios deben hacerse para que
considere el parche aceptable. Existe una cierta resistencia a incluir
parches que son rechazados por el autor y el maintainer del código, pero
esto tiene un límite. Si se interpreta que bloque buen trabajo, esos
parches eventualmente lo eludirán y se incorporarán al kernel de todos
modos. En el kernel de Linux, nadie tiene poder de veto absoluto sobre
ningún código. Excepto quizás Linus.

En muy raras ocasiones, puede encontrar algo completamente diferente: otro
desarrollador publica una solución distinta a su problema. En ese punto, es
probable que uno de los dos parches no se incluya, y "el mío fue el
primero" no se considera un argumento técnico convincente. Si el parche de
otra persona desplaza al suyo y se incorpora al kernel, realmente solo hay
una manera de responder: alegrarse de que su problema se haya resuelto y
continuar con su trabajo. Que su trabajo sea desplazado de esta manera
puede ser doloroso y desalentador, pero la comunidad recordará su reacción
mucho después de que hayan olvidado de quién era el parche que realmente se
incluyó.