Rethinking debian-release
0 likes252 views
This document proposes rethinking Debian's release process to address issues with the current model where packages can remain old and untested for long periods in stable releases. It suggests implementing a "fresh" rolling release distribution between unstable and stable to pull packages through more frequent automated testing. This new "fresh" model could shorten the migration cycle from over two years to just two weeks, improving quality, increasing users and testers, and allowing for more predictable, incremental updates.
Rethinking debian-release
- 1. Rethinking Debian release 18th November 2017 Hideki Yamane <henrich@debian.org>
- 2. Why rethink release? ● “Debian is old” ● “Debian (stable) is old” ● “Debian (stable) is old (for our usage)” ● “Some packages are still old and buggy, but no update”
- 3. Current Release Migration ● Unstable → Testing – Based on urgency (high,medium,low) ● Blocked by Release Critical bug ● Testing → Stable – (Looong) Freeze and release unstable Testing (staging) Urgency- based migration (automated) stable Freeze & release management
- 4. Stable release management = many-legged-race ● Push release management causes “many-legged-race” http://web-japan.org/kidsweb/archives/life/action/06-02/act0602.html 60,000-70,000 Packages
- 5. Its result... ● Like this... https://www.youtube.com/watch?v=Rwqvx99Gz2U
- 6. Another Problem: Is that package tested, really? ● Who tests it? – Sometimes "Passive test" doesn't work well ● Code never matures – Code != Wine / Whiskey – But time makes features to rot...
- 7. Worst scenario ● Upload to unstable no one cares it→ no bugs filed→ migrate to testing→ release stable→ found bugs in stable, but leave it...→ (since put not tiny changes to stable is not easy task…) bad user experience→ bad reputation→ less user→ less developer...→
- 8. Answer (1): + “Active” migration ● Same as other distros – Gentoo: mask (package flag) – Fedora: bohdi (voting system) – openSUSE: openQA (automated test) ● "pull" migration system via vote by users & maintainers ● “Package quality” is guaranteed by safety harness (pipeline) ● It ensure "it works" by someone, at least
- 9. Pull is better than push “Push” Testing to stable migration – Thousands changes in one time – Handled by few release managers = capacity overflow burnout...→ “Pull” migration – Several changes in one time – Handled by hundreds advanced users & maintainers vs
- 11. Why we need "new distribution"? ● Average users never use unstable or testing, they use "released" one (= stable) ● “Innovators theory” (by Everett M. Rogers) – Innovators ： 2.5 ％ (unstable) – Early Adopters： 13.5 ％ (testing) – Early Majority ： 34.0 ％ – Late Majority ： 34.0 ％ (stable) – Laggards ： 16.0 % (oldstable)
- 12. “Fresh” distribution Innovators ： 2.5 ％ (unstable) Early Adopters： 13.5 ％ (testing) Early Majority ： 34.0 ％ “ Fresh” Late Majority ： 34.0 ％ (stable) Laggards ： 16.0 % (oldstable) We can get more users! (100 / 66 = 150%)
- 13. Positioning openSUSE factory openSUSE LEAP openSUSE tumbleweed SLES Fedora (rawhide?) RHEL (CentOS)Ubuntu unstable testing fresh stable oldstable 25.15 cm N E W O L D
- 14. Fresh? ● Borrow name from LibO :) ● Target: Average users (Early Majority) ● Release every one or two week – Rolling release – Predictable scheduled release ● Pull change sets – Sustainable deploy – Ensure changes, not break anything
- 15. Not push changes into stable directly ● Why new “fresh” distribution? – Users expect stable as stable ( not changed so much)≒ – We afraid to break stable release
- 16. Migration cycle time Traditional migration unstable Testing (staging) Urgency- based migration (automated) stable 5days 730days push Freeze & release management
- 17. Migration cycle time Add “Fresh” distribution unstable Testing (staging) fresh pull Urgency- based migration (automated) pull-changes migration (by hand) stable pull pull-changes migration (by hand) Point releaseEvery week 5days 7days 60days 735days → 12days (5+7) = 60times faster!
- 18. Shorten cycle time ● Before : 730 days (minimum 180days) ● After : 12 days 15-60 times faster delivery! ● Maximize added-value
- 19. Change the rule! ● There was a reason to make rules – Unstable – Testing – Stable – Long freeze term and release ● But situation has changed, then rules should be changed, too. Because its rule becomes bottleneck
- 20. Faster release introduce more bugs? ● Q: It may introduce more bugs! – A: “test early and fail fast” on fresh stage, but less bugs in stable since more test users watch it. – Testers ● Previous : 2.5 + 13.5 = 16.0 ● Fresh : 2.5 + 13.5 + 34.0 = 50.0 → 300%
- 21. “Fresh”: Pros & Cons ● Pros) – 150% users, 300% testers – 60 times faster release – Same cadence, its release date & changes are predictable – Changes in each release are small, users can bite it (No Big Bang release) ● Less freeze term for next release ● Not need to hassle to make huge release note ● Moe "real acceptance test" by real users for next stable release ● Cons) – It just costs ● Infrastructure change ● Docs & website update ● More release manager & publicity work ● Prepare security fix (but delta with unstable is small, right?) – maybe it reduce backport effort in stable
- 22. Metrics? ● More testers – BTS number – RC in stable / bugs in stable ● More users – Download number