Los tags obligatorios: Signed-off-by, Fixes y Cc stable

Bajo el cuerpo de cada mensaje de commit del kernel vive una zona de etiquetas —los trailers— que parece burocracia y es en realidad la infraestructura legal y técnica que sostiene el proyecto. Una de ellas, Signed-off-by, no es una firma cortés: es una declaración jurada sobre la procedencia del código, la respuesta que el kernel dio a un pleito que amenazó su existencia. Otras dicen qué bug arreglas y a qué ramas debe llegar. Omitir la que toca es motivo de rechazo inmediato. Entender estas etiquetas es entender cómo un proyecto sin contratos de cesión de derechos de autor se protege legalmente a la escala de miles de millones de dispositivos.

Signed-off-by y el Developer Certificate of Origin

git commit -s añade una línea al pie:

Signed-off-by: Nombre Apellido <tu@correo.org>

No es decorativa. Al ponerla certificas el Developer Certificate of Origin, un texto corto —vive en Documentation/process/submitting-patches.rst— cuyas cláusulas afirmas bajo tu responsabilidad:

• (a) creaste el cambio y tienes derecho a enviarlo bajo la licencia del archivo; o
• (b) se basa en trabajo previo con una licencia compatible que te permite reenviarlo; o
• (c) te lo pasó alguien que ya certificó (a), (b) o (c) y no lo has modificado; y
• (d) entiendes que la contribución es pública y que quedará registrada indefinidamente, con tu nombre y correo, y podrá redistribuirse.

Debes firmar con tu nombre legal real, no con un seudónimo: es una atestación jurídica. Y cuando un parche sube por la jerarquía, cada persona que lo maneja añade su propio Signed-off-by en orden cronológico, formando una cadena de custodia verificable desde el autor hasta Linus. Esa cadena es legible en cualquier commit del árbol:

git show -s --format='%(trailers)' HEAD    # el pie completo de trailers
git log --format='%an %ae' -1 HEAD         # autor frente a firmante

flowchart LR
A[Autor Signed-off-by] --> B[Mantenedor del subsistema Signed-off-by]
B --> C[Linus aplica al arbol principal]
C --> D[Cadena de custodia inmutable en git]

Fixes: el linaje del bug

Si tu parche corrige un error, debes decir qué commit lo introdujo. La etiqueta Fixes: tiene un formato canónico rígido: doce dígitos del hash seguidos del asunto original entre paréntesis y comillas.

# configura la abreviatura a 12 y genera la etiqueta exacta
git config --global core.abbrev 12
git show -s --format='Fixes: %h ("%s")' abc123def456
# -> Fixes: abc123def456 ("misc: midriver: registra el dispositivo")

# muchos lo guardan como alias reutilizable de por vida
git config --global alias.fixline "show -s --abbrev=12 --format='Fixes: %h (\"%s\")'"
git fixline abc123def456

Pégala en la zona de trailers, junto al Signed-off-by:

Signed-off-by: Nombre Apellido <tu@correo.org>
Fixes: abc123def456 ("misc: midriver: registra el dispositivo")
Reported-by: Bot de Pruebas <syzbot+deadbeef@syzkaller.appspotmail.com>
Closes: https://lore.kernel.org/all/000000@google.com

Fixes: no es cosmética: los equipos de las ramas estables escanean automáticamente esa etiqueta para decidir qué backportear. Un Fixes: bien puesto puede llevar tu arreglo a decenas de versiones de mantenimiento sin que hagas nada más. Y si un Reported-by acompaña, el kernel exige hoy un Closes: con el enlace al informe original.

Cc stable: pedir el backport

El Cc: stable es especial: es una etiqueta que va dentro del mensaje de commit, no una simple cabecera de correo, y por eso queda en la historia de git para siempre. Le dice al equipo estable “esto merece llegar a las ramas de mantenimiento”:

Cc: stable@vger.kernel.org
Cc: stable@vger.kernel.org # 6.6.x
Cc: stable@vger.kernel.org # 6.1+

Las reglas viven en Documentation/process/stable-kernel-rules.rst: solo para arreglos reales de bugs, nada de funcionalidades nuevas, cambios pequeños y contenidos. El sufijo tras la almohadilla acota a qué versiones aplica. Ponerlo cuando no corresponde molesta al equipo estable; omitirlo cuando un usuario en producción sufre el bug deja a medio mundo sin el arreglo.

Otras etiquetas del linaje

El pie del commit registra a todos los que dejaron huella en él, y cada atribución tiene su regla precisa:

Reported-by: Ana García <ana@example.org>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217654
Suggested-by: Li Wei <li@example.org>
Co-developed-by: Otra Persona <otra@example.org>
Signed-off-by: Otra Persona <otra@example.org>
Signed-off-by: Nombre Apellido <tu@correo.org>
Link: https://lore.kernel.org/all/20260714-midriver-fix@correo.org

Reported-by acredita a quien encontró el fallo y hoy va siempre acompañado de un Closes: con el enlace al informe. Suggested-by da crédito a quien propuso la idea. Co-developed-by marca la coautoría real del código y arrastra una regla estricta: debe ir inmediatamente seguido del Signed-off-by de esa misma persona, porque cada coautor certifica su propio DCO. El Link: apunta al hilo de la lista, cerrando el círculo entre el commit y la conversación que lo engendró. Y la ley que las gobierna a todas: nunca inventes una etiqueta ni pongas el nombre de nadie sin su permiso, porque cada una es una atribución jurídica con consecuencias reales.