Re: How to show $arch releaseability (was: Re: How to define a release architecture)
On Tue, 22 Mar 2005 14:15:13 +0100, Wouter Verhelst <wouter@debian.org> 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
Reply to: