Tu primer parche: por dónde empezar y qué no hacer

Sabes preparar un parche, encontrar a quién enviarlo, sobrevivir a la revisión y firmar las etiquetas. Solo falta lo más difícil de todo: empezar. El primer parche no es un problema técnico —para eso ya estás sobradamente preparado— sino un problema de coraje y de criterio. ¿Qué arreglo es lo bastante pequeño para no ahogarte y lo bastante real para merecer el tiempo de un mantenedor? ¿Cómo evitas los errores que marcan al novato antes de que lea tu código? Esta lección es el mapa desde el borde del agua hasta tu nombre en git log.

Por dónde empezar de verdad

El mejor primer parche resuelve un problema real, aunque sea diminuto: una fuga en una ruta de error poco transitada, un valor de retorno mal comprobado, un aviso de sparse o smatch (nivel 9.2). Esos cambios enseñan el proceso completo sin exponerte a una revisión brutal, y aportan valor de verdad. Las herramientas mismas te dan la lista de tareas:

# el modo estricto encuentra más de lo que exige el mínimo
scripts/checkpatch.pl --strict --file drivers/staging/*/*.c

# los analizadores señalan bugs reales por arreglar
make C=1 drivers/misc/          # sparse
make CHECK=smatch C=1 drivers/misc/

# busca patrones a corregir con coccinelle
make coccicheck MODE=report

El punto de entrada canónico es el proyecto kernelnewbies.org y su tutorial First Kernel Patch, que te lleva paso a paso desde clonar el árbol hasta enviar. Su lista de correo existe para preguntas de principiante sin miedo al ridículo. Y en 2026 hay caminos con mentor y a veces con estipendio:

Dónde encontrar tu tarea

Saber que debes empezar pequeño no te dice dónde mirar. El kernel deja pistas de trabajo pendiente por todas partes; basta con aprender a leerlas:

# comentarios que confiesan deuda técnica
git grep -n -E 'FIXME|TODO|XXX' drivers/misc/

# los avisos de las herramientas son bugs esperando dueño
scripts/checkpatch.pl --strict --file drivers/misc/midriver.c
make coccicheck MODE=report M=drivers/misc/

Más allá del árbol, tres fuentes alimentan a los recién llegados. El panel de syzbot (syzkaller.appspot.com) publica miles de fallos reproducibles hallados por fuzzing, muchos sencillos y sin dueño. El Bugzilla del kernel (bugzilla.kernel.org) recoge reportes de usuarios reales. Y la lista de kernelnewbies mantiene tareas marcadas para principiantes. Elige un bug con reproductor, entiéndelo a fondo, y ya tienes tu primer parche con un Reported-by y un Closes: listos para el pie del commit (nivel 56.4).

Qué NO hacer

Casi todos los primeros parches se rechazan por errores de forma, no de código. Evítalos y ya estarás por delante de la mayoría:

• No mandes ruido puro. Un parche que solo corrige espacios en blanco o reordena líneas en código central rompe el git blame, genera churn y no aporta valor. Corrige estilo solo cuando ya tocas ese código por otro motivo real.
• No envíes parches de un LLM que no entiendes. En 2026 los mantenedores reciben una avalancha de slop generado por modelos: parches plausibles, a menudo sutilmente rotos, de alguien que no sabe defender ni una línea. Varios subsistemas los rechazan de plano. Usa las herramientas que quieras para aprender, pero entiende cada línea que firmas: tu Signed-off-by afirma que respondes por ese código.
• No mezcles asuntos en un commit ni envíes una serie de veinte parches como primer contacto.
• No hagas top-posting, ni HTML, ni adjuntos (niveles 56.2 y 56.3).
• No envíes solo a Linus ni a la lista equivocada: corre get_maintainer.pl.
• No discutas a la defensiva ni reenvíes cada media hora. Paciencia.

Un recorrido de punta a punta

Todo el nivel 56 cabe en una secuencia que ejecutarás la primera vez con el corazón acelerado:

git switch -c primer-parche v6.12
$EDITOR drivers/misc/midriver.c          # el arreglo, pequeño y real
git add -p && git commit -s              # commit atómico y firmado (56.1)
scripts/checkpatch.pl --strict $(git format-patch -1)   # limpio (9.2)
scripts/get_maintainer.pl 0001-*.patch   # a quién enviar (56.2)
git send-email --to=... --cc=... 0001-*.patch
# ... llega el feedback: iteras a v2, v3 (56.3), recoges Reviewed-by ...
# ... y un día en la bandeja: "Applied, thanks" ...

No hay atajo que salte pasos, porque cada uno protege al siguiente: un commit sucio muere en checkpatch, el destinatario equivocado muere en el silencio, una respuesta soberbia muere en la indiferencia del mantenedor. Haz los cinco con humildad y paciencia y el sistema —diseñado para filtrar exactamente lo contrario— te dejará pasar.