Re: test suites
Finn Thain dixit:
>looks at the results. But if m68k build logs were (once again) made
>available at <http://buildd.debian.org/> then there would be an argument
>for enabling tests. (Though perhaps it is best if some build machines skip
Yes, but they are put there by a buildd, and the buildds can’t work
at the moment. I suppose some should definitively skip checks. Let’s
just say: not right now, but definitively later.
(I think my priority is to get things _available_ and _installable_;
when (not if) they have bugs, these can always be fixed later.)
>I imagine that pressure for faster turn-around might cause a release
>architecture (like hppa) to disable them, but this would not apply to us(?)
It does: the longer we take to keep up with building the archive, the
more manual effort is necessary to make dependencies available, fix
stuff, etc. That’s why I’m under a bit of pressure to get this working
before gcc-defaults switches to gcc-4.5 and during a time eglibc and
linux-2.6 can be built with what we have (I’m concentrating on gcc-4.4
exclusively for that at the moment). I think we are in even greater
need of fast turn-arounds right now, or at least once I uploaded the
set of packages to debian-ports.org… (by the way, hppa isn’t a release
architecture for squeeze).
Once the archive is in relatively good a state, and the buildds have a
chance to keep up, testsuites ought to be run of course.
It’s a bit sad. I agree with you, but pragmatism tells me to skip them.
//mirabilos
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt
Reply to: