Hi! One of the side effects of the freeze  of our upcoming stable release - squeeze - is that not all tasks get done as quickly as you might be used to in the past. For example, work on things that are not entirely release critical, like processing the NEW queue , are not the highest priority currently. One of the reasons is that NEW packages processed now won't end up in the release anyway, so there's no need to hurry. This of course frees up some time for other tasks. This also means that we might not notice a package fixing RC bugs in the NEW queue. So avoid that! It is *your* fault if you upload an RC bugfix to NEW  - and suddenly see your package removed from the release as it wasn't released from NEW in time. It never was and will not ever be a good idea to do this, *unless* the fix for the RC bug *is* the package split (which happens to be the case for about 1% of the RC fixes we saw pass through NEW). Remember, RC bugs have to be fixed as soon as possible, not lingering in whatever queue. And remember also that the release team favors small fixes for reviews, not large restructuring ones. KISS - Keep it simple... :) Now, should you have one of the rare uploads where the RC bugfix actually IS the split, so your package can not bypass NEW - as soon as you got the notification that your package is waiting to get processed in NEW, get in contact with us. Mail us at email@example.com, join our IRC channel (#debian-ftp on irc.debian.org), buy us a chocolate, whatever, but tell us and we can see to help the RC bug get through, making our next release better than ever. Should you have an RC fix in NEW without the good reason that its the only way - how about fixing a score of other RC bugfixes? The more you do for the release, the better for the release, the more you are loved, the better we listen despite the mistake of uploading non-RC critical package splits. :) Best regards, Alexander, on behalf of the ftp-team 1: http://www.debian.org/News/2010/20100806 2: http://ftp-master.debian.org/new.html 3: As a reminder: Packages will go through the NEW queue if they add new binary or source overrides. Ex: New binary packages split away, package renames, etc.
Description: Digital signature