On Sat, 23 Oct 2004 06:36:26 +0200, Jérôme Marant <[EMAIL PROTECTED]> said:
> Colin Watson <[EMAIL PROTECTED]> writes: >> On Fri, Oct 22, 2004 at 02:48:01PM +0200, Jérôme Marant wrote: >>> Joey Hess <[EMAIL PROTECTED]> writes: >>> > When we used to freeze unstable before a release, one of the >>> > problems was that many updates were blocked by that, and once >>> > the freeze was over, unstable tended to become _very_ unstable, >>> > and took months to get back into shape. >>> >>> What do you think we'd get by combining both (testing + unstable >>> freeze)? >> >> My guess is that the release team would go insane having to approve >> every upload to unstable. > I don't think so. Dinstall would reject any new upstream release. > Approvals would only apply to t-p-u just like it is done currently. Umm. So no new debian native packages? Even though those are the ones we can best control? Also, this is a half-hearted solution. There is often a poor correlation between bugs and new upstream releases (in other words, I have screwed up packages in the past with my debian revision uploads far worse than any new upstream version). I still think you should look into testing-frozen and candidate distributions, locking down testing-frozen, and working towards improving candidate -- and that way, it is less intrusive, we'll not have to scrap the current mechanism, and we can compare both methods all at the same time. But that involves getting down, rolling up your sleeves, and doing _work_ -- rather than convincing other people to do it your way. The former is more likely to succeed. manoj -- Do students of Zen Buddhism do Om-work? Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C