A Rolling Stable Kernel Model
summary
Proposes a rolling stable/LTS model that presents a single updatable branch per track so users follow the latest stable or LTS without switching git branches, implemented by a git-merge trick that preserves tags and SHAs; schedule stays the same with a 10-week release cadence and yearly LTS cut, moves between stable snapshots happen ~2–3 weeks after release; claims no new guarantees but easier uptake, notes commits in late RCs have ~3x regression risk so testing remains necessary.
AI-written summary · about
chapters (13)
- 0:00Intro
- 0:234 Major Schemes
- 1:191.0 - 2.6: Users show up
- 4:502.6: How we shot our foot
- 6:343.0-now: Fingers & toes
- 9:12Schedule based releases
- 10:35Death of an LTS
- 13:38Where do we go from here?
- 15:17Rolling kernel
- 17:52How does it look like?
- 19:22What does it mean
- 20:57Common concerns
- 25:57Radical change?
related talks
39mUsing Long Term Stable Kernel for the Embedded Products
50mMaintaining a Real Time Stable Kernel
34mDelivering Security Fixes Continuously Into Your Embedded Linux
49mLong-Term Maintenance, or How to (Mis-)Manage Embedded Systems for 10+ Years
39mTowards Sustainable Systems with the Civil Infrastructure Platform
50mThe ultimate guide to software updates on embedded Linux devices
55mThe Embedded Linux Problem
39mImplementing Power-Safe Atomic Over the Air Updates