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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
