Ser mantenedor: revisar, aplicar y enviar hacia arriba

El kernel tiene más de cuarenta millones de líneas y ninguna persona que las entienda todas. Ni Linus. Y sin embargo el conjunto avanza, no se contradice y no se desintegra. El mecanismo que lo hace posible no es técnico sino humano: una red de mantenedores, cada uno soberano sobre un subsistema, que revisan lo que llega, lo firman con su nombre y lo pasan hacia arriba a alguien que confía en su juicio sin repetirlo. Entender ese rol es entender cómo se gobierna, de verdad, la pieza de software más crítica de la civilización.

El mantenedor: un cuello de botella por diseño

Un mantenedor no es un cargo, es una responsabilidad: es la persona que dice sí a un parche para su subsistema. Linus Torvalds no lee la inmensa mayoría de los cambios que entran en el kernel; los recibe ya digeridos de un puñado de tenientes de confianza. Esos tenientes —el árbol de red, el árbol de gestión de memoria de Andrew Morton, el árbol tip que gobierna x86, planificador y locking, los árboles de Greg Kroah-Hartman para driver-core y USB— tampoco leen todo: reciben a su vez de mantenedores más específicos. La autoridad se ramifica hacia abajo hasta el driver de un solo chip, y la confianza fluye hacia arriba.

Esta jerarquía es una red de confianza, no un organigrama. Nadie comprende el todo; cada nodo comprende su territorio y confía en el juicio de sus vecinos. El mantenedor es, deliberadamente, un cuello de botella: el kernel es lento en aceptar código a propósito, porque la lentitud es el precio del juicio. Un parche que nadie mira es un parche que no entra.

Las tres tareas: revisar, aplicar, enviar

El trabajo diario de un mantenedor se reduce a tres verbos.

Revisar. Leer el parche en la lista de correo, entenderlo, señalar problemas de diseño, de estilo, de seguridad o de concurrencia, y —cuando está bien— bendecirlo con una etiqueta. Reviewed-by dice “lo he leído a fondo y respondo por su corrección”. Acked-by dice “no es mi área pero lo apruebo”. Tested-by dice “lo he probado y funciona”. Estas etiquetas se acumulan en el mensaje y son el rastro auditable de quién avaló qué.

Aplicar. Cuando el parche convence, el mantenedor lo integra en su árbol con git am, añadiendo su propio Signed-off-by al final de la cadena. Esa firma no certifica que el código sea perfecto: certifica el Developer’s Certificate of Origin, la declaración legal de que quien firma tiene derecho a aportar ese código bajo la licencia del kernel. La cadena crece a medida que el parche sube:

Signed-off-by: Ada Programadora <ada@ejemplo.org>
Reviewed-by: Rita Revisora <rita@ejemplo.org>
Signed-off-by: Marta Mantenedora <marta@subsistema.org>

Enviar hacia arriba. Una vez por ciclo, en la merge window, el mantenedor no manda parches sueltos: manda una pull request. Prepara una etiqueta firmada en su árbol, genera el resumen con git request-pull y pide al mantenedor de arriba que haga git pull. El código viaja como un bloque de commits ya revisados, con la firma de quien responde por ellos.

El archivo MAINTAINERS y get_maintainer.pl

¿Cómo sabe un contribuyente a quién enviar su parche? El kernel guarda la respuesta en un único archivo en la raíz del árbol, MAINTAINERS: un mapa legible por máquina de quién responde por cada fichero. Cada entrada es un bloque de campos etiquetados:

BTRFS FILE SYSTEM
M:	David Sterba <dsterba@suse.com>
R:	Josef Bacik <josef@toxicpanda.com>
L:	linux-btrfs@vger.kernel.org
S:	Maintained
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git
F:	fs/btrfs/
F:	Documentation/filesystems/btrfs.rst

M: es el mantenedor, R: un revisor designado, L: la lista de correo del subsistema, S: el estado —de Supported (alguien cobra por mantenerlo) a Orphan (huérfano, no lo cuida nadie)—, T: el árbol git y F: los patrones de ficheros que cubre. No lees este archivo a mano: lo consulta por ti el script que traduce un cambio en una lista de destinatarios.

# a quien envio este parche, segun los ficheros que toca
scripts/get_maintainer.pl 0001-mi-correccion.patch

# o directamente sobre un directorio del arbol
scripts/get_maintainer.pl -f fs/btrfs/

El script recorre las entradas, cruza los patrones F: con los ficheros modificados y devuelve mantenedores, revisores y listas a los que poner en copia. Enviar un parche sin pasar por aquí es el error de novato número uno: acaba en un buzón que nadie mira.

El árbol propio y linux-next

Cada subsistema tiene su árbol git publicado en git.kernel.org, y dentro de él ramas con roles distintos. Una rama de correcciones (a menudo -fixes) recoge lo urgente para el ciclo -rc en curso. Una rama -next acumula todo lo que aspira a entrar en la próxima merge window: es donde el mantenedor deja madurar el material durante semanas antes de enviarlo hacia arriba.

Pero si doscientos árboles -next avanzan en paralelo, ¿cómo se descubren los conflictos entre ellos antes de que exploten en el árbol de Linus? Ahí entra linux-next, el árbol de integración que Stephen Rothwell ensambla cada día laborable fusionando alrededor de doscientos árboles de subsistema en uno solo. Cuando dos subsistemas se pisan, el conflicto aparece en linux-next semanas antes de la merge window, y se resuelve en calma. De ahí el mantra que gobierna todo el proceso: si no está en linux-next, no está listo para entrar. linux-next no es una base sobre la que construir —se rehace entero cada día—: es un banco de pruebas, el kernel de mañana montado hoy para ver qué se rompe.

flowchart LR
DEV[Contribuyente] -->|parche a la lista| LISTA[Lista del subsistema]
LISTA -->|revision y etiquetas| MANT[Mantenedor de subsistema]
MANT -->|git am a su rama next| ARBOL[Arbol del subsistema]
ARBOL -->|fusion diaria| NEXT[linux-next: integracion]
ARBOL -->|pull request en la merge window| LINUS[Arbol de Linus: mainline]
NEXT -.detecta conflictos antes.-> LINUS