Re: so what? Re: Debian development modem
(I'm going to repeat here some things I said in Cologne ...)
I agree that we have a serious problem. My proposed solution is as
We should abandon attempts at `social engineering' through release
management. So, `we must do X before we release' or `you must fix bug
Y or we should remove the package' (for non-critical Y), have to stop.
This is a volunteer organisation and trying to coerce people into
doing work by threatening to burn the house down just leaves you
standing over undone work, holding a match, wondering whether to carry
out your threat.
We must decouple our development tracks much more. I propose that we
resolve never again to plan a release with is not fully backward
compatible with the current stable version.
We should abandon the idea of `release goals'. Instead, if someone
thinks a thing definitely needs doing by the time of a release, they
do it. If it doesn't get done then we release anyway.
So, in detail:
Every three months (fixed date) we copy the current `unstable' into
`frozen'. At this point `stable', `frozen' and `unstable' should all
stay interoperable both in source and binary form.
Bugfixes must be applied to frozen, and important ones to stable too.
After one or two months of beta frozen should be stable enough to
The need to retain complete compatibility will make it harder work to
make big changes - they have to be phased in. However, it will result
in a situation where we can safely release _halfway through_ such a
big change. For example, I hope that the next time the libc is
changed incompatibly we will release a distribution that's half new
libc and half old libc. Probably our libc7 distribution will still
have libc5 programs in it - but that's fine !
If it's not fine with you then let's not hold up the releases -
instead, go and fix those packages.
We also need to make automatic building a real possibility.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org