A proposal for an always-releasable Debian [LWN.net]

A proposal for an always-releasable Debian

Posted May 10, 2013 17:44 UTC (Fri) by Richard_J_Neill (subscriber, #23093)
Parent article: A proposal for an always-releasable Debian

There is a *huge* potential win for bug-fixing here.

At the moment, most expert users can't meaningfully contribute to bug fixing across the ecosystem. This is demoralising, wasteful of resources, and reduces the quality of the system as a whole.

Either:
- we waste our time spotting/diagnosing/reporting bugs in our current system, only to discover that it is already fixed upstream (and we just can't have the fix for 6 months)
- or we report a genuinely new bug, and it gets fixed upstream, but it takes a year before the fixed package makes it into a release that we can use.

We need a system such that the lifecycle of a bug is short, ideally a week rather than at least a year. To give an example, I might install the current stable release of Ubuntu Raring. If I find a bug, it should get fixed upstream, fixed for me, and fixed for all other users of the same distribution within a week.
Currently, it takes at least till the next release-cycle, which means hundreds of other people suffer the problem, and the bug-reporter isn't rewarded for his time with a fix.

to post comments

A proposal for an always-releasable Debian

Posted May 12, 2013 9:36 UTC (Sun) by k3ninho (subscriber, #50375) [Link]

Can I speak about this in conventional software development terms? Lars has said that the waterfall has to stop. At the moment the full release process is a complex system integrator taking tools for independent teams who work to their own time schedules. What matters is the packagers being able to accurately estimate the time it will take to update to and test a new upstream revision of their package - which feeds in to allow the release team to predict better when the release comes out. More importantly, it allows people to ask for help when they're suddenly swamped with a busy other life, or simply have taken on too much.

Change the conversation so that package teams tell the release team that (i) they're updating to upstream version X+1; (ii) they expect it will take so many weeks to migrate, so many weeks to build and so many weeks to test; (iii) add an estimate for the time taken to get feedback from Debian users once it's in the archive, which you could easily use popcon data and size of the change to estimate how quickly the obscure bug gets noticed and filed.

Within that, cutting down the bug filed -> fix applied -> fix tested time is essential, and having a framework to replicate an end-user's issue, as well as to verify it's not regressed in the future, would be a hge step forward. I'd suggest that second in importance is improving the information about how long it takes to update to the latest upstream packages.

(I've just noticed Conway's law lurking in the corner: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations", not completely sure how it applies to the design and release system in Debian.)

K3n.