Hi. I apologize in advance for the somewhat negative tone of my reply. I think that Ian's proposal is unrealistic, and does not address our current problems at all.
Ian Jackson wrote: > 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. I don't see any way we could have preserved compatibility more than we did, with the hamm release. The entire altdev scheme was devised for it. What more could have been done? > 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. "They do it" is easily said, but it runs counter to the principle of letting maintainers have the final word on their packages. That principle is the main reason why absentee maintainers are such a problem. Do you propose to drop it? > 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. This is still a major operation at every freeze time. I like the "stable pool" approach much better. That way we are ready to release *at any time*, modulo newly discovered bugs in the stable packages that have to be fixed. (How much a problem such bugs are probably depends on how well we automate the process of getting bugfixes into the stable pool.) > 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. What happens if the bugs don't get fixed? Release buggy packages? Deciding not to release a package that has grave bugs is entirely different from threatening to burn the house down. > [...] 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. It's not fine with me if hamm is released with "crafty" in main, because crafty is not DFSG-free. How do I fix that? (I'm taking examples here for the sake of specificness, I don't mean to pick on them.) It's also not fine with me if hamm is released with a non-working p2c. (The package is currently orphaned). That doesn't mean I want to fix it, since I have no interest in p2c. Unless someone cares enough to maintain it, it should be dropped from the distribution. How do I "fix" that? > We also need to make automatic building a real possibility. Now this I agree with. It is already happening. Witness netgod's recent efforts at getting the sparc tree up to date, he uploaded some 300 packages in one day. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
