Re: How to show $arch releaseability (was: Re: How to define a release architecture)
On Tue, Mar 22, 2005 at 12:45:56PM +0000, Michael K. Edwards wrote:
> On Tue, 22 Mar 2005 11:02:47 +0100, David Schmitt
> <david@schmitt.edv-bus.at> wrote:
> [snip]
> > As Steve mentioned in another mail[1], one of the points where arches offload
> > work onto the release team is
> >
> > "3) chasing down, or just waiting on (which means, taking time to poll the
> > package's status to find out why a bug tagged 'testing' is still open),
> > missing builds or fixes for build failures on individual architectures that
> > are blocking RC bugfixes from reaching testing"
>
> And it's not just the number of arches. Slow arches really do make
> more work, and it's not just about migrations to testing. There's a
> concrete example right now that shows why a large number of slow
> autobuilders, working in parallel, isn't a great solution. (Although
> distcc is another story, if its results are truly reproducible.)
>
> The latest uim FTBFS twice on ARM because of the removal of howl
> dependencies from gnome packages.
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.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Reply to: