Warning
Si tiene alguna duda sobre la exactitud del contenido de esta traducción, la única referencia válida es la documentación oficial en inglés. Además, por defecto, los enlaces a documentos redirigen a la documentación en inglés, incluso si existe una versión traducida. Consulte el índice para más información.
- Original:
Documentation/process/6.Followthrough.rst
- Translator:
Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com>
6. 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.
6.1. 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.
6.2. ¿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.
6.3. 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ó.