Ah, yes. I misinterpreted your message. I thought you meant that the package would spend more than the testing transition delay actually compiling, which is not reasonable. I see others reasons to mention slow arches:On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote: > > That probably won't make much time difference on "fast" archs (i386, > > amd64 etc), but on slower ones like mips, mipsel etc (those sometimes > > hold up testing transition :().> A missing build will only slow testing migration if the package wasn't > built when the unstable testing delay is over. Since almost all uploads > to NEW are low urgency, the build would need to take over 10 days to > affect the time to testing migration.pokerth 0.6-1-2 needed 13 days (uploaded on 28.01, built [but not yet uploaded] today), so it *can* make a difference (not a really big one though in this case)
1. Builds tend to take more time to be signed 2. Builds tend to fail more often 3. Slow arches are more often unable to keep upYour suggestion could help with 1 and 2, but not really with 3. If the NEW package gets earlier in the queue, it's built more quickly, but packages that come later are built more slowly. And 3 must be the main reason for the delay in this case, presumably more than 90% of the delay.
> To speed up testing migration due > to missing builds, it would be much more efficient to work on buildd > redundancy (or other improvements to the buildd network).I didn't mean this one shouldn't be done. I just meant that if it should, it's a low priority one.More/faster buildds, nicer dependencies etc, sure. But why not this one too? ;)