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

[Sven Luther <sven.luther@wanadoo.fr>]

On Sat, Mar 19, 2005 at 11:24:14AM +1000, Anthony Towns wrote:
> beyond "unstable + snapshotting facility", and why? Debian developers 
> manage to develop on unstable fairly well, eg, why isn't that enough? Is 
> this just a PR issue, in that "unstable" and "snapshot" aren't something 
> you can put on a brochure or brag about on slashdot?

I wanted to do a test-install on powerpc using sid yesterday (or was it
friday) using the desktop task, in order to test that the new udev/makedev
combo did indeed fix the RC bug (300166/300170). But for some obscure reason,
tasksel failed to install the the desktop task, didn't even provide a log or
something for the reason.

This exactly is why we need testing, because unstable can get hit by random
breakage, and using whatever snapshoting of unstable for those minority
arches, means the porters will get hit by any number of random problems, not
even arch specific, and thus in addition of doing their porters work, need to
do all the work done by the testing scripts and the release team right now.

Which is why i proposed a build-from-testing method instead, which has the
problem of porters needing to upload twice, once to unstable to fix the issue,
and once to arch-unstable if the upload to unstable fails to reach testing for
whatever issue.

So, could you, as the testing script master-mind :), give us some hints as of
a per-arch sub-testing script would be possible ? 

I mean, we have unstable where everyone uploads their packages, and then we
have testing which gets filled from unstable by the testing-scripts for the
tier1 arches.

The idea would be to have for each tier2 arch a separate testing script,
running on scc or whatever hardware, and filling a per-arch testing from
unstable, but with the added limitation that the package needs to be in
testing to go to the per-arch testing, and individual hinted overrides would
be possible for arch-specific problems, which could also be uploaded through
testing-proposed-updates.

This way, tier1 testing doesn't need to wait for tier2 arches at all, but
tier2 arches can still get the benefit of testing at a lesser cost.

I would look at the code, and implement this myself, but i don't speak python,
so i am utherly useless for this kind of things.

Friendly,

Sven Luther