Torvalds frena parches RISC-V por «basura» en Linux 6.17
El cierre de la ventana de fusión de Linux 6.17 ha dejado un episodio agitado: un paquete de cambios para RISC-V fue rechazado por Linus Torvalds al considerar que incluía modificaciones improcedentes en cabeceras genéricas y que, además, fue remitido fuera de tiempo.
El envío, realizado por Palmer Dabbelt (equipo de Android en Google), llegó prácticamente al límite y tocaba áreas comunes del kernel con lo que Torvalds definió como «basura», lo que motivó un veto inmediato y la petición de volver a intentarlo en la siguiente ventana de integración. Más sobre las advertencias de Torvalds a los usuarios
Qué ha pasado
El lote de cambios se envió poco antes de que se publicara la primera release candidate de Linux 6.17, un momento en el que las integraciones de nuevas características ya no encajan con el calendario del proyecto. Para entender mejor las actualizaciones de Linux 6.17, puedes revisar las novedades principales de Linux 6.16.
Torvalds identificó dos problemas principales: por un lado, la llegada tardía del pull request, en contra de las pautas comunicadas a los mantenedores; por otro, la inclusión de ajustes en cabeceras compartidas que no eran estrictamente necesarios para RISC-V. ¿Quieres seguir las políticas de integración del proyecto? Revisa las declaraciones de Torvalds sobre la disciplina en el kernel.
Uno de los puntos más señalados fue la introducción de un ayudante de macros, make_u32_from_two_u16(), que a juicio del líder del proyecto reducía la legibilidad del código y añadía ambigüedad respecto al orden de los argumentos. Para profundizar en las mejoras de la versión, visita todo sobre Linux 6.17 y sus parches.
En la cultura del kernel, los cambios específicos de una arquitectura deben permanecer dentro del árbol de esa arquitectura salvo casos justificados y consensuados; tocar cabeceras comunes implica efectos colaterales para todo el ecosistema.
Quién ha estado implicado y por qué molestó
El envío lo firmó Palmer Dabbelt, ingeniero del equipo de Android, con cambios orientados a RISC-V pero que extendían su alcance a cabeceras transversales del kernel, lo cual disparó las alarmas de revisión. Para entender cómo afecta esto a proyectos específicos, consulta las mejoras en Linux 6.16.
Días antes, Torvalds había solicitado adelantar las peticiones de fusión por motivos de agenda, por lo que la llegada al límite fue interpretada como una ruptura de las reglas del proceso. Para más detalles, revisa las novedades de Linux 6.13.
El mensaje fue claro: no habrá más pull requests fuera de plazo ni modificaciones que ensucien zonas comunes sin necesidad. La invitación quedó sobre la mesa para reintentar en la 6.18, dentro de la ventana adecuada y con un alcance más acotado.
Reacciones y contexto
Por su parte, Dabbelt respondió en tono conciliador, comprometiéndose a respetar los tiempos y a limitar los cambios a las áreas de RISC-V para no afectar a cabeceras compartidas. Para entender mejor la importancia del control de calidad, mira las mejoras en Linux 6.10.
El episodio reavivó el debate sobre cómo equilibrar la apertura del desarrollo con la disciplina técnica. En Linux, la inclusividad no implica aceptar cualquier cambio: exige consistencia, claridad y calidad. Más sobre la disciplina en los proyectos Open Source en sistemas ARM y Linux.
La reacción encaja con decisiones recientes de Torvalds para proteger la estabilidad del árbol, recordando que el calendario y las normas de integración no son decorativas, sino herramientas para evitar regresiones y deuda técnica. Para entender la importancia del calendario en el desarrollo, lee las novedades de Linux 5.19.
Mirando a corto plazo, Linux 6.17 seguirá su curso sin estos parches, mientras que el trabajo para RISC-V podrá proponerse de nuevo en la 6.18 si se ajusta a las directrices marcadas y se aparcan los cambios cosméticos que entorpecen la lectura.
La combinación de un envío al filo del cierre, modificaciones a cabeceras genéricas y un helper controvertido ha servido de recordatorio: en el kernel, los cambios deben llegar a tiempo, ser necesarios y mejorar la claridad, no al revés.
