Regarding shortening the release cycle, one way to shorten the time to freeze would be to threaten to freeze early and often (so people get new packages in and don't wait for the last minute).
Another technique is to publically set critical bug counts or other objective metrics for freezing, i.e., "We shall freeze when the release critical bug count goes below 50, and when we have a new alpha version of the boot-floppies". Of course, we wouldn't have to strictly follow these guidelines, but it would throw developer's attention to the right place. I think we could give a more professional approach to the freeze itself too. The last two freezes (hamm and slink) did *not* occur when they were supposed to, and no updates were sent out on what the delay was nor how long it was expected to last. -- .....Adam Di [EMAIL PROTECTED]<URL:http://www.onShore.com/>
