Debian etch: how to scratch the itch
Why we have not yet released and what you can do about it
Martin F. Krafft <madduck@debian.org>
- Developer with the Debian, Zope, and Plone projects
- Author of the book The Debian System — Concepts and Techniques
- Ph.D. student, Lero, CSIS, University of Limerick, Ireland
Overview
- Debian and its release cycle
- Release blockers
- What you can do
- What you'll get
Overview
- Debian and its release cycle
- Release blockers
- What you can do
- What you'll get
Debian: the hard facts
- (second-)oldest GNU/Linux distribution: 14 years
- among the largest OSS projects:
- 1,050 developers + 2,500 contributors
- 19,000 packages, 11 architectures
- over 100 derivatives
- conservative: prefer solid solutions to quick 'n' dirty ones
- robust, secure, stable
- 100% Free
- volunteers, flat hierarchy, meritocratic
Debian releases
- Current release: Debian 3.1r5 "sarge"
released 6 June 2005, revised 17 February 2007 - Named after toy story characters
- In preparation: Debian 4.0 "etch" (originally planned for 4 Dec 2006)
Debian stable
- Debian "stable" is known to be rock-solid …
"Look, this is Debian. They don't release things until you have to fire rockets at the thing to stop it from working." (Slashdot quote)
… and outdated:
"Debian releases are out of date the minute they are published" (common prejudice)
Release process
- unstable - testing - stable
- Current stable: "sarge", current testing: "etch", unstable: "sid"
- Next stable: "etch", next testing: "lenny", unstable: "sid"
- Automatic transition from unstable to testing.
- Manual tagging of a frozen testing as stable.
Package cycle
Freeze process
- Long freeze process due to complexity
- five categories: essential, required, standard, optional, extra
- frozen one after the other, then stabilisation period
- "etch" has been frozen since 11 December 2006.
- Implications:
- no automatic migrations to testing: extra work for RMs
- no new upstream version in unstable: losing the cutting edge
RC bugs
- Release-critical bugs (RC bugs) prevent a package from entering stable
- This is what makes Debian be Debian
- Packages with RC bugs are either fixed or removed
- Exceptions are possible on a case-by-case basis (etch-ignore)
Current status
From: http://bugs.debian.org/release-critical/
(Not entirely accurate because does not respect version tracking)
Overview
- Debian and its release cycle
- Release blockers
- What you can do
- What you'll get
So why haven't we released yet?
Reason #17: because Martin is off writing talks about why etch hasn't been released, instead of fixing RC bugs. ;)
—Steve Langasek,
release manager
No really, why haven't we released yet?
Because we aren't ready yet.
(I know you didn't want to hear that)
Poll: should Debian:
- release every X months?
- aim for a release every X months, but give priority to QA?
- not release at all?
Release blockers: the technical reasons
- Still over 100 RC bugs and stagnating tendency
- No usable kernel (which accounts for about 30% of RC bugs)
- debian-installer stalled by kernel
Good news: kernel frozen as of 9 Feb 2007.
Management reasons
- Kernel team currently lacks release management
- Ambitious/unrealistic release date
- Schedule by RC bug count, but kernel much bigger blocker
- Ignore RC bug trends during previous releases
- Bug count monitoring confusing, three sources
- Too early freeze (116 RC bugs), major slowdown
- Unrealistic assumptions about freeze cycle length
Dunc-tank
- attempt to speed up release by paying RMs through donations
- outside of the project, but involving prominent DDs, including DPL
- very controversial, caused a lot of discussion and flames
- Demotivation/reprioritisation of/by DDs (DWN, …)
Dunc-bank
The Dunc-Bank is an experiment to see how aggressive bug reporting can delay the release of Debian Etch. […] We think that overall quality is more important than keeping release promises others did for us.
Assessing the effects
- Dunc-bank had good QA effects, latent RC bugs
- Dunc-tank-paid RMs caused sharp decline in RC bug count
- But unable to isolate/quantify effects by dunc-tank/-bank.
- Delay because of the debate? Not sure …
- Those flaming would have flamed elsewhere
Steve's midterm report: http://web.dodds.net/~vorlon/wiki/blog/midterm_report.html
Overview
- Debian and its release cycle
- Release blockers
- What you can do
- What you'll get
What you can do
- Fix bugs
- Try to reproduce bugs, research the problems
- Fix kernel bugs
- Tend to the documentation/website, release notes, translations
- Coordinate complex teams, such as the kernel team (delicate task)
Let's fix a bug
- Use http://bts.turmzimmer.net/details.php to select a bug to fix
- pick a bug older than 7 days
- watch out for comments and claims
- contact the maintainer
- fix the bug, making only relevant changes, and keeping the diff small
- test (!)
- prepare an NMU (non-maintainer upload)
- upload or seek sponsorship
- lather, rinse, repeat
I tried …
Original plan: fix #410946 during talk
No consensus in four days of discussion, thus cannot upload
If I were you, I wouldn't make such an unnecessary change in an NMU. Oh, no, if I were you, I wouldn't consider an NMU here at all.
…
Frankly, I'm somewhat pissed that I've spent a couple of minutes on writing this message, instead of working on the bug itself.
I gave up.
Overview
- Debian and its release cycle
- Release blockers
- What you can do
- What you'll get
New in etch
- SecureAPT
- Graphical installer, incl. dm-crypt and complex languages
- UTF-8 (on new installs)
- udev by default (on new installs)
- Xen/Vserver, Sun Java, Tomcat, LTSP
- Firefox vs. Iceweasel
- debtags
- dbconfig-common
For the complete list: http://wiki.debian.org/NewInEtch
Hot air?
Just remember the Irish way
We'll release when it's ready. (I don't think this will ever change.)
(Logo by Neil McGovern)
Come to debconf7!
- 16 June (Saturday) 2007 : Debian Day ("for the masses")
- 17 — 23 June: talks, workshops, development, social activities
- In Edinburgh, Scotland
- Attendance is free, but registration is required.
More info: http://debconf7.debconf.org
My Ph.D. research
Method diffusion in large open source projects
- Debian processes somewhat antiquated, compare with the agility of e.g. Plone
- Volunteers don't like to be told what to do
- Methods exist to improve asynchronous global collaboration
- How do you make sure people adopt these?
Thank you
Martin F. Krafft <madduck@debian.org>
I received valuable input for this talk from: Steve Langasek, Sam Hocevar, Frans Pop, Brian May, Anthony Towns, Theodore Ts'o, Thomas Viehmann, and the other folks of #debian-devel. Thank you all!
Licence
These slides, their design, and the content are © Martin F. Krafft and released under the terms of the CC by-nc-sa 2.5 licence.
reStructuredText sources: slides.rst and ui/debian/*.
Slides based on the S5 presentation system.
Social reasons