So far, Canonical has followed a split kernel SRU cycle for Ubuntu, where regular fixes and security patches lived on separate tracks, with a full update every four weeks and a security-focused release at the two-week midpoint for urgent CVE fixes.If that concept is new to you, a Stable Release Update, or SRU, is how Canonical ships bug fixes and security patches to Ubuntu after a release is out. The kernel gets its own dedicated track for this.Canonical is replacing both tracks with a single 2-week cycle, and since each new cycle kicks off a week into the current one, this results in a kernel release landing every week.The new 2-week cycleSource: CanonicalEach cycle starts with a week of patch integration and prep work. The kernel team selects which fixes land on each kernel, builds the packages, and runs basic smoke tests to catch anything obviously wrong before the build moves on.Those builds get pushed into Ubuntu's -proposed pocket once the first week wraps up. That is where kernel release candidates live before they have been certified, accessible to those who know where to look but not yet out to general users.Week two is where Canonical runs the builds through its Ubuntu Certified hardware testing program, putting them through different machine types to make sure nothing breaks in the real world before the kernel ships.A fresh cycle starts every week regardless of where the current one stands, so there is always a kernel finishing its test run and rolling out. That is how a 2-week cycle ends up delivering a release every week.And, when something is not safe to ship, Canonical says that they will be clear about that and direct users toward general system hardening advice.For teams that cannot wait the full two weeks, Canonical is explicitly pointing to -proposed as a fast path. The idea is that you run your own acceptance tests on the build sitting there rather than waiting for certification to wrap up.Clankers made this inevitableThis change did not come from nowhere; they had to take such a sweeping decision due to clankers. Only last month, we saw how they were bleeding compute resources from git.kernel.org just by scraping it for training data.For Canonical, their decision was driven by LLMs and AI agents turning vulnerability hunting into something automated and relentless, finding kernel bugs at a scale and speed no individual human researcher could replicate.The goal is to have a workaround published within 24 to 48 hours of a CVE going public. Not the patch, but something that gets affected systems into a safer state while one is being built.What the Ubuntu maker is doing here is responding to a rapidly-evolving situation by shortening the window between a CVE going public and a patch landing.