On Tue, 22 Mar 2005 14:15:13 +0100, Wouter Verhelst <[EMAIL PROTECTED]> wrote: [snip] > Except that arm doesn't *have* a large number of slow autobuilders, > working in parallel. They have four, and are having problems keeping up > right now.
Precisely. And four is already pushing the point of diminishing returns, unless you have a good mechanism for enforcing rules like "builds against existing packages derived from gnome-vfs2 will be no good; don't schedule uim until libpanel-applet2-dev, etc. have actually made it into unstable where buildds can get at them." Otherwise you get this kind of race condition. Maybe someone already experienced in wanna-build hacking could implement a sort of "write barrier" field in changelog entries, perhaps as "urgency: flush". This would force all packages that build-depend on foo-dev (built from foo) to wait until foo/foo-dev makes it to unstable for $arch before they can be scheduled on an $arch buildd. It would also notify appropriate humans that everything that build-depends on foo-dev needs to be rebuilt, and facilitate scheduling of these builds ahead of their reverse build dependencies. And so forth. This would help reduce pointless FTBFS like this uim run. But the bottom line is that some rebuild sequences are intrinsically sequential, and late in a release cycle is when they hit the hardest, because issues like the howl license finally get forced. Cheers, 0 Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]