A proposal for an always-releasable Debian

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.