Re: Debian needs more buildds. It has offers. They aren't being accepted.
On Thu, Feb 12, 2004 at 03:08:35AM +0100, Goswin von Brederlow wrote:
> > 10 machines - one fail -> 10% of CPU time fails
> > 1 machine - one fail -> 100% of CPU time fails
> > 10 machines tend to have more failures by number, but that don't result in
> > bringing down the whole port. Well, you know that of course... nothing new
> > here... ;)
> Same goes for admins. 1 admin can be sick or busy working on
> security. With 10 admins most certainly one will allways have some
> spare time, not be sick, be in a good mood.
> Its not just hardware thats problematic, its people and spare time
> too.
Yeah, of course.
That's why I want to improve the mail handling for the logs as the hurd
people already doing in a similar way...
> [mips buildd offer]
> As far as I understood the mips buildd story the buildd was refused on
> grounds that were just poor excuses, unwillingness to cooperate or to
> give up solem control of the buildds for the arch. Not very nice if
> the project has to suffer because of that.
Yeah, ask three people and you'll 3 different reasons why it was rejected.
> > Erm, why can't a machine be used as a buildd *and* for DDs to port/debug
> > their packages? Crest does both, sometimes with 2-4 builds in parallel to
> > the buildd.
> If only it where big and fast enough. :) Crest is likely to timeout
> build due to its load. But hey, a mips system is faster by several
> magnitudes so that shouldn't be a problem.
Partly agreed. MIPS could be faster as it is now. One reason is that the L2
cache is not used, iirc, and the other reason is, that most MIPS systems act
as 32 bit, although the CPU is 64 bit (even the quite common R4x00 are 64
bit mostly, some are, some are not).
> And slower machines make less work so the admin would have more time
> to respond to requests to rebuild packages or to build packages in a
> hurry out of order.
> I've build ~170 packages successfull, ~40 failures, ~200 dep-wait and
> ~30 source fetch failures (no accepted/autobuild access) on those 2
> buildds manually since they have been configured and waiting for
> wanna-build access. Without that m68k would be around 300 packages
> need-build now.
Indeed... akire is building axiom atm. It's at 11 MB of 17 MB build log
now...
> I think it would be good (if we have room to breath with the new
> buildds) to stop the buildd on crest and make it exclusively a
> developer machine. Or limit the packages that crest builds to the
> smaller ones. Any D-I developer can log in there and build packages. A
> spare partition could be freed up for "make demo" d-i runs too. But
> thats off-topic, lets wait for the buildds to get w-b access and then
> talk on irc.
There were some thoughts to open up kullervo as well as a public machine
once there are enough other buildds and sarge has been released. Together
with shaihulud that would make 3 public machines. That should take off some
load from crest as well, I think. And there's still another 060 machine in
Nuremberg as a fallback (no, not akire, another one ;))
> admin doesn't have time (or will) to handle right now. Idealy every
> time the admin looks after his buildd all packages but the currently
> building one (actually 2-10 due to pre-caching) should be handled. The
Depends on the speed of the buildd. s390 surely can take 100 packages in one
go and finish them before the next dinstall run. ;))
> Too bad we don't have figures for the time between end of build and
> admin action. That would be a real measurement of the responsiveness.
That would be nice, but difficult to obtain... you'll need to follow each
package through the states of building...
--
Ciao... //
Ingo \X/
Reply to: