Cada pocos meses, el kernel de Linux abre una puerta que solo deja pasar novedades durante dos semanas, y lo que no cruza ese umbral espera al ciclo siguiente. La puerta de la versión 7.4 se abrió el lunes 19 de octubre de 2026, un día después de la publicación del 7.3, y cuatro días más tarde ya se habían integrado 6.753 cambios sin contar los merges. Quedaba por delante la mayor parte del recorrido y el árbol principal seguía recibiendo ramas enteras de código.
Esa puerta es la merge window, el periodo en el que Linus Torvalds fusiona en el árbol principal los pull requests que cada subsistema ha preparado durante meses. Esta vez la rutina cambia por un motivo doméstico: Torvalds publicó el 7.3 el domingo 18 de octubre y avisó de que empezaba sus vacaciones familiares, con el lunes reservado para un barco y el buceo, y las fusiones desplazadas a las tardes.
El interés no está tanto en la cifra como en el ritmo. Quien empaqueta una distribución, quien mantiene un controlador fuera del árbol o quien planea una migración de servidores necesita saber cuándo se mueve el árbol principal, y una semana de diferencia descoloca esa cuenta. Torvalds dejó claro en el mismo mensaje que la prórroga es para él: lo que no esté listo antes de abrir la ventana se queda para el 7.5.
El calendario pesa más que el recuento
La ventana se abrió el lunes 19 y, con las dos semanas habituales, cerraría el domingo 1 de noviembre; con la semana extra se iría al 8. En ese plazo Torvalds no fusiona cualquier cosa: exige que lo enviado llegue probado y aceptado por el mantenedor del subsistema antes de que la puerta se abra.
El ciclo anterior sirve de escala. Su ventana cerró el 30 de agosto con la primera candidata del 7.3, y la versión final no apareció hasta el 18 de octubre, siete semanas más tarde. Una semana extra no altera ese orden de magnitud, aunque sí la fecha en que una distribución puede planear su próximo salto.
Cada subsistema acumula sus parches en un árbol propio y los manda en bloque cuando la fecha llega. De ahí que un retraso del que fusiona no frene a los mantenedores, sino que embote la cola de entrada: el trabajo está hecho y espera turno en una lista que solo avanza al ritmo de una persona.
Linus recuerda las reglas
Aquí conviene precisar qué significa la prórroga. El propio Torvalds escribió que la semana adicional no le hará aceptar pull requests llegados fuera del calendario, porque lo que se fusiona debe estar preparado antes de la apertura y no desarrollado durante ella. Su margen sirve para vaciar la cola que él mismo no pudo atender en las primeras jornadas.
Esa distinción importa más de lo que parece a primera vista: la ventana puede durar tres semanas para quien fusiona y seguir cerrada para quien llega tarde con un controlador a medio probar o con una serie sin revisar.
El efecto práctico se mide en la fecha del rc1, la primera candidata a la versión 7.4. Si el cierre se va al 8 de noviembre, todo el periodo de estabilización se desplaza una semana, y quien tenga una congelación a la vista tendrá que elegir entre esperar al 7.4 o integrar el 7.3, un kernel ya cerrado y publicado.
¿Qué ha entrado en los primeros días?
El recuento del viernes 23 cubre unos cuatro días y medio de fusiones, cerca de un tercio del calendario habitual. Para calibrarlo sirve el ciclo anterior: la ventana del 7.3 terminó con 15.267 cambios sin merges, el segundo rc1 con más commits de la historia del kernel después del 6.7, que arrastraba casi 3.000 del historial de bcachefs.
Ese total se completó por etapas. Unos 13.000 de aquellos 15.267 llegaron después del primer balance de la ventana, cuando los tirones grandes de cada subsistema entraron de golpe en el árbol principal. El balance de esta semana es un pago inicial, no el retrato final del ciclo.
Ninguno de esos 6.753 cambios está al alcance de un usuario todavía. El árbol principal no se empaqueta para producción y la primera versión que se puede probar en serio es el rc1, así que la cifra mide el ritmo de los mantenedores y no la calidad del resultado.
Más mejoras de para IA y servidores
Entre los tirones que ya están dentro, el del planificador llegó con una actualización de EEVDF firmada por Vincent Guittot, ingeniero de Linaro, que en las pruebas publicadas por Phoronix rebaja hasta un 55% la latencia de las tareas de franja corta, esas que ocupan la CPU durante menos tiempo. Es la misma familia de ajustes que el ingeniero ya había trabajado para el 7.3.
El mismo tirón incorpora un mecanismo que ajusta las vCPU al tiempo que el hipervisor sustrae a la máquina virtual, y una preferencia por los dos hilos que comparten núcleo en las CPU NVIDIA Vera, con ganancias de entre el 3% y el 6% en las pruebas del mismo medio. El peso de estas mejoras está en servidores y máquinas virtuales, no en el uso doméstico.
Los números del planificador vienen de un banco de pruebas concreto, no de una promesa general. El grueso de los 6.753 cambios son limpiezas, arreglos de errores y correcciones de seguridad que no alteran nada visible para quien usa el escritorio a diario.
Lo que cambia para quien mantiene una distro
Nadie que empaquete una distribución tiene que mirar el 7.4 esta semana. kernel.org sigue sirviendo parches para seis series longterm: el 6.18.58, el 6.12.114 y el 6.6.160 salieron el 21 de octubre, y el 6.1.190, el 5.15.223 y el 5.10.272 el 15. El 7.2.12 apareció el 21, tres días después del 7.3.
Las distribuciones de ciclo corto son las que sí vigilan el árbol principal, y su referencia ahora es el 7.3, que llegó con FailFS y mejoras de gaming con poca VRAM, no el 7.4. Ese kernel necesita varias semanas de pruebas antes de aterrizar en un repositorio estable, así que la prórroga de la ventana apenas altera su hoja de ruta para el próximo trimestre.
Las seis series longterm dibujan una escala que conviene tener presente. Van de la 5.10 a la 6.18, y cada una arrastra su propio calendario de revisiones, así que un administrador puede pasar años sin tocar la rama principal y seguir recibiendo correcciones de seguridad.
Apretando el calendario
Para quien mantiene un controlador fuera del árbol la fecha sí muerde. La tercera semana no abre una segunda oportunidad: si la serie no entró en las dos primeras, el trabajo espera al 7.5 y toca seguirla en linux-next, que el 23 de octubre publicó su instantánea next-20261023. Ahí se nota una ventana larga, en el desfase de un ciclo completo para el hardware nuevo.
Probar un kernel recién salido no se resuelve descargando el tarball y arrancando, porque cada distribución recompila sus módulos, firma el paquete y repite su batería de pruebas con el hardware que tiene a mano. Ese trabajo solo empieza cuando el kernel deja de moverse.
El empaquetado no vive solo del kernel. Rust 1.100 llegará el 12 de noviembre con una edad mínima de publicación en Cargo, un ajuste que permite rechazar versiones recién subidas al registro hasta que cumplan una antigüedad mínima. Ese tipo de calendarios también decide qué entra en una distribución y cuándo.
Una semana de margen que decide el resto del ciclo
Con la ventana a un tercio de su recorrido, el número que quedará para la historia es el del cierre, no el del viernes 23. Si la prórroga se confirma, comparar el total del 7.4 con los 15.267 que cerró el 7.3 será una trampa estadística: serían tres semanas de fusiones frente a dos, y el total diría más del calendario que del volumen real de trabajo.
Lo que sí está decidido es la siguiente cita. El 7.4-rc1 llegará el 1 o el 8 de noviembre, y esa fecha arrastra todo lo demás: la duración de la fase de pruebas, la ventana de estabilización de las distribuciones y el momento en que un controlador nuevo deja de depender de parches fuera del árbol. Hasta que Torvalds cierre la puerta, cualquier balance del 7.4 es provisional.
