David Paleino wrote: > On Tue, 24 Aug 2010 22:53:28 +0800, Paul Wise wrote: > > Since we are now in a freeze period, splitting the package up is > > not appropriate, nor is a new upstream version that is > > not-preapproved by the release team. > > Why? > Testing is the one frozen, not unstable.
The way I understand it: when during the freeze updates to packages flow in the usual way (unstable -> tesing), much more testing occurs. (IOW: t-p-u is a final resort.) The release team can also set age-days for a particular package to a higher value than the default implied by the urgency, precisely to enforce a longer testing period for a change that (in their opinion) requires more testing. If you upload to t-p-u, and sid has diverged enough compared to the frozen testing, you are basically shooting in the dark. It means almost zero testing, AFAICT. And it surely means you have to test your changes in a squeeze environment; that's the minumum required. When too much packages are uploaded to sid, the release can easilty become unmanageable. This was evidenced by the Woody and (if I'm not wrong, Sarge) freezes which took so long. You're right that only testing is frozen, but unstable is the testbed for testing. If you can't manage to keep your testbed clean and actually using it is a "testbed", this could possibly decrease the quality of the final bed, which is, after all, the end product delivered to all users. > And testing-proposed-updates is there for a specific reason, if > needed :) Yes, for cases when you'd really regret that you uploaded new stuff to sid during the freeze :-) The existence of t-p-u allows you to circumvent the *usual* testing procedure, uploading a fixed package targeting the next stable release. Still, uploading to t-p-u is not something you could take for granted, it still requires an explicit ACK from the release team. IMO they're more likely to unblock a package which was exposed to more users in sid. > (i.e. I'm all for continuing development in sid during the freeze) Long freezes can be frustrating, indeed, but it's best to examine a few problematic packages and eventually fix a bug here and there, thus shortening the freeze period. Personally, I'll try to do that (after fixing my bugs), I think it's a better contribution than continuing development in sid. But that's just me, everyone else can have their own priorities, naturally. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/874oejbx7s.gnus_not_unix!%[email protected]
