Re: Bits (Nybbles?) from the Vancouver release team meeting

[Thiemo Seufer <ths@networkno.de>]

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