On 13/02/2008, Charles Plessy wrote: > 1h05 on sparc, > 37 min on mipsel, > 39 min on mips, > 37 min on powerpc, > 19 min on hppa, > 6 min on amd64… What about *relative* numbers, e.g. what % of the time is spent in the build itself (gcc and friends), and what % of the time is spent in the testsuite? Anyway, (almost) less than 1 hour everywhere isn't what I call time-consuming from a buildd point of view. > Not a big deal, except of course if everybody makes test like this. More tests, less bugs. > In popcon, there are 26 mips users, and primer3 is used by 0.1 % of > the Debian users. Popcon is no absolute knowledge. Anyway, 25+ users is far from negligible AFAICT. Remember popcon can be disabled for various reasons (e.g. privacy). I also seem to recall having heard of mips (but I might be mistaken) clusters being used for specialized research in related areas (but I'm not used to this domain, just reading the description of the package). > I still think that it is useless to wait for mips users to have > primer3 build before letting bug fixes to primer3 migrate to > testing, but as you noted, that it is a different story. Indeed, that's nothing related here, and you've been already heavily discussing the buildd redundancy matter elsewhere… > If the persons who care about the Debian ports do not mind my > package eating their CPUs, I'll happily re-enable the tests > everywhere. Less than 3/4 hour isn't what I call eating CPU. Go and see how many *hours* are spent in some packages. Again, I'd rather see buildd being used as much as possible to catch problems at build time than letting bugs pass through and bite users at runtime, which is always a PITA to debug. YMMV. -- Cyril Brulebois
Attachment:
pgp2Cl0sLlC22.pgp
Description: PGP signature