Daniel Jacobowitz wrote:
[snip]
> > Okay, so we've got a new suite; is that global for all scc arches, or
> > separate, a la "subtesting-s390", say? The question there is "Will s390
> > have a different version of the package to m68k, if one or the other is
> > being more aggressively maintained?"
>
> I don't know. This depends mostly on the dynamics of the ports teams
> and on the amount of work it turns out to be. It may be that holding
> up for other architectures would be just as much a problem for the s390
> mantainers as it is for the core release managers; or it may be that
> the overhead is too high to justify doing it for less than the full
> set.
I think subtesting should be done per-arch (for mips{,el}: per two-arch :-)
because the focus is different. S390 probably wouldn't care much about
a broken libusb but regards PostgreSQL as important; while for arm it
would be inverse. "Broken" would mean in this context rc-s390,
"won't care" means to remove it from subtesting-s390.
[snip]
> Both of these are plausible; the difference is whether you autobuild
> from unstable or testing. I would prefer the former, which means your
> former case.
Autobuilding from testing won't work well AFAICS, as it introduces
another delay until rc-<arch> bugs are found. Building packages with
generic RC bugs and ignore them for subtesting seems to be the lesser
evil.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
