A quién enviar y cómo: get_maintainer.pl y git send-email

Tienes el parche listo, firmado y limpio. ¿Ahora dónde va? En GitHub abrirías un pull request y esperarías. En el kernel eso no existe: hay más de mil mantenedores, decenas de árboles de subsistema y ninguna autoridad central que reciba tu código. El parche viaja como un correo de texto plano a las personas y a las listas correctas, y descubrir quiénes son es un problema con solución mecánica. Este es el rito de paso más intimidante para el recién llegado y, una vez entendido, el más liberador: no dependes de la web de nadie.

get_maintainer.pl: a quién le importa tu código

El árbol trae un script que, dado tu parche o un archivo, te dice a quién enviar y a qué lista. Lee MAINTAINERS y el historial de git para deducir los interesados:

# a partir del parche ya generado (lo más fiable)
scripts/get_maintainer.pl v1-0001-fix.patch

# o a partir de un archivo o directorio
scripts/get_maintainer.pl -f drivers/misc/midriver.c

La salida clasifica a cada destinatario por su rol, y esa clasificación decide dónde lo pones:

Jane Maintainer <jane@example.org> (maintainer:MISC DRIVERS)
John Reviewer <john@example.org> (reviewer:MISC DRIVERS)
linux-misc@vger.kernel.org (open list:MISC DRIVERS)
linux-kernel@vger.kernel.org (open list)

La convención es clara: los mantenedores y revisores van en To: porque son quienes deciden; las listas van en Cc: porque son el archivo público donde la comunidad ve y comenta. Nunca envíes solo a Linus: él no aplica parches de subsistemas ajenos, y hacerlo te marca como novato que no leyó el proceso.

Configurar git send-email

git send-email habla directamente con tu servidor SMTP y manda cada .patch como un correo perfectamente formado. Se configura una sola vez:

git config --global sendemail.smtpServer smtp.example.org
git config --global sendemail.smtpUser tu@correo.org
git config --global sendemail.smtpEncryption tls
git config --global sendemail.smtpServerPort 587
git config --global sendemail.confirm auto

Con eso, enviar es una orden:

git send-email \
  --to="Jane Maintainer <jane@example.org>" \
  --cc="linux-misc@vger.kernel.org" \
  --cc="linux-kernel@vger.kernel.org" \
  v1-0001-fix.patch

Y hay un atajo elegante: dejar que el propio get_maintainer.pl rellene el Cc: por ti, de modo que nunca olvides una lista:

git send-email --to="jane@example.org" \
  --cc-cmd='scripts/get_maintainer.pl --nogit-fallback' \
  out/*.patch

flowchart TD
A[git format-patch] --> B[get_maintainer.pl]
B --> C[To maintainers y reviewers]
B --> D[Cc listas del subsistema]
C --> E[git send-email o b4 send]
D --> E
E --> F[lore.kernel.org archiva el hilo publico]
F --> G[Cualquiera revisa responde y aplica]

b4: el flujo moderno de 2026

Konstantin Ryabitsev, que administra kernel.org, escribió b4 para modernizar todo esto sin abandonar el correo. En 2026 es la herramienta recomendada tanto para enviar como para seguir series. Gestiona ramas temáticas, la carta de presentación, el versionado y el envío:

pip install b4

b4 prep -n midriver-fix -f v6.12   # rama temática nueva
# ... haces tus commits firmados ...
b4 prep --edit-cover                # editas la carta de presentación
b4 prep --auto-to-cc                # rellena To/Cc con get_maintainer
b4 send                             # envía la serie completa, bien formada

Del lado del mantenedor, b4 shazam https://lore.kernel.org/... descarga una serie entera desde el archivo público y la aplica con todos sus trailers. El correo sigue siendo el transporte; b4 es la ergonomía moderna encima.

Seguir las listas sin ahogarte

Antes de enviar nada, conviene leer la lista a la que vas a escribir: aprendes su ritmo, su tono y qué se acepta. En 2026 no hace falta suscribirse y sepultar tu bandeja: lore.kernel.org archiva casi todas las listas en formato public-inbox, navegable por web y clonable como repositorio de git.

# leer un hilo concreto por su Message-Id
b4 mbox 20260714-midriver-fix@correo.org

# lei: buscar y seguir temas sin suscribirte a la lista entera
lei q -I https://lore.kernel.org/all/ -o ~/mail/uaf \
  --threads 'dfn:drivers/misc/ AND s:leak'
lei up ~/mail/uaf          # actualiza esa consulta guardada

lei (Local Email Interface) es el compañero de public-inbox: convierte las listas en consultas a la carta que descargas a un buzón local y lees en mutt, neomutt o aerc desde el terminal. Así sigues solo los hilos de tu subsistema —los parches, las regresiones, las decisiones— sin el diluvio de LKML entera, que mueve cientos de correos al día.