El proceso de revisión: iterar con paciencia hasta la v-final

Pulsaste enviar y tu parche ya está en el archivo público, visible para siempre. Ahora empieza lo que de verdad define al kernel: la revisión. Alguien —quizá el mantenedor, quizá un desconocido que pasaba por la lista— responderá citando tu diff línea a línea y señalando lo que no le convence. Casi nunca aceptan la v1. La revisión no es un trámite ni un rechazo: es el mecanismo por el que un código escrito por un extraño se vuelve digno de correr en miles de millones de máquinas. Tu trabajo ahora es iterar, agradecer y tener paciencia, mucha paciencia.

Iterar: v2, v3 y el changelog

Cuando un revisor pide cambios, no discutes en abstracto: corriges el código y reenvías una versión nueva. El versionado es explícito y lo gestiona format-patch:

git format-patch -v2 -1               # asunto: [PATCH v2] ...
git format-patch -v3 --cover-letter v6.12

La sutileza está en dónde va el registro de cambios. Todo lo que escribas bajo la línea de tijeras --- y encima del diffstat viaja en el correo pero no entra en el commit: es el lugar exacto para el changelog de la versión.

Subject: [PATCH v2] misc: midriver: arregla la fuga en la ruta de error

Cuerpo del mensaje que SÍ queda en el commit para siempre.

Signed-off-by: Nombre Apellido <tu@correo.org>
Reviewed-by: John Reviewer <john@example.org>
---
v2:
  - uso devm_kzalloc en lugar de kzalloc, como sugirió John
  - corrijo el orden de liberación en la etiqueta de error
v1: https://lore.kernel.org/all/20260714-midriver-fix@correo.org

 drivers/misc/midriver.c | 8 +++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Para una serie, el changelog va en la carta de presentación (el parche 0000), no en cada parche. Y siempre enlaza la versión anterior en lore.kernel.org: da contexto a quien llega tarde.

Las etiquetas de confianza

La revisión produce trailers que otros te regalan y que tú acumulas en el mensaje de commit de la siguiente versión. Son la moneda de reputación del kernel:

La regla de honor: solo arrastras a la v3 los Reviewed-by de la v2 si el código no cambió materialmente desde que te los dieron. Si reescribes la parte que alguien revisó, su etiqueta caduca y debes retirarla; conservarla sería atribuirle una revisión que no hizo.

# b4 lee el hilo en lore y aplica los trailers nuevos a tus commits
b4 trailers -u

Esta orden de b4 es la forma moderna de recoger etiquetas: descarga del archivo público todos los Reviewed-by, Tested-by y Acked-by que te dieron y los inserta en el sitio correcto, sin copiar y pegar a mano.

flowchart TD
V1[PATCH v1 a la lista] --> R[Revision inline en el hilo]
R -->|comentarios| FIX[Corriges el codigo]
FIX --> V2[PATCH v2 con changelog bajo la linea de tijeras]
V2 --> R2[Nueva revision del hilo]
R2 -->|Reviewed-by Acked-by Tested-by| APLICA[El maintainer aplica a su arbol]
R2 -->|mas comentarios| FIX

Responder: la etiqueta de la lista

Cómo respondes importa tanto como qué corriges. La cultura del correo del kernel tiene reglas estrictas y no negociables:

• Responde interleaved: cita el trozo concreto del revisor y escribe tu respuesta debajo de cada punto. Nunca hagas top-posting (todo tu texto encima del correo citado): en la lista se considera de mala educación y dificulta seguir el hilo.
• Recorta la cita: deja solo las líneas a las que respondes, borra el resto.
• Texto plano, sin HTML, sin firmas corporativas ni avisos legales.
• Contesta a cada comentario: o lo aplicas, o explicas con argumentos por qué no. Ignorar una objeción es la vía rápida al silencio.
• No reenvíes la v2 a los diez minutos. Deja reposar al menos un día para que otros comenten, y si el hilo enmudece, un ping educado a las dos semanas es lo correcto, no antes.

Qué le pasa al parche cuando lo aceptan

Un “Applied, thanks” no es el final del viaje, es el comienzo de otro. El mantenedor no mete tu parche en el árbol de Linus: lo aplica a su árbol de subsistema, que cada noche se integra en linux-next, la rama donde el kernel del día siguiente se prueba en conjunto. Ahí tu cambio convive semanas con los de los demás mientras la CI (nivel 48) lo martillea en decenas de arquitecturas.

# ¿ya está tu parche en la cola del subsistema o en -next?
git log --oneline linux-next/master | grep -i midriver

# compara lo que enviaste con lo que el mantenedor aplicó de verdad
b4 diff 20260714-midriver-fix@correo.org

Solo cuando se abre la ventana de fusión —las dos semanas tras cada versión en que Linus acepta cambios nuevos— el mantenedor le envía a Linus un pull request con tu parche dentro, y este entra en el árbol principal. Unas semanas más tarde sale la versión estable y tu código empieza a ejecutarse en el mundo real. Si además llevaba Cc: stable (nivel 56.4), el equipo estable lo retroporta a las ramas de mantenimiento y llega incluso a distribuciones que congelaron su kernel hace años. Vigila b4 diff: a veces el mantenedor retoca tu parche al aplicarlo, y debes saber qué quedó grabado con tu nombre.