(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 follows:
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 release. 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. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
