On Tue, Mar 15, 2005 at 01:21:59AM -0800, Steve Langasek wrote: > On Mon, Mar 14, 2005 at 11:00:12AM +0100, Sven Luther wrote: > > > > There are a few problems with trying to run testing for architectures > > > that aren't being kept in sync. First, if they're not being kept in > > > sync, it increases the number of matching source packages that we need > > > to keep around (which, as has been discussed, is already a problem); > > > second, if you want to update using the testing scripts, you either have > > > to run a separate copy of britney for each arch (time consuming, > > > resource-intensive) or continue processing it as part of the main > > > britney run (we already tread the line in terms of how many archs > > > britney can handle, and using a single britney check for archs that > > > aren't keeping up doesn't give very good results); and third, if > > > failures on non-release archs are not release-critical bugs (which > > > they're not), you don't have any sane measure of bugginess for britney > > > to use in deciding which packages to keep out. > > > What about building the scc (or tier 2 as i would say) arches from testing > > and > > not unstable ? this way you would have the main benefit of testing (no RC > > bugs, no breakage of the day kind of problems). Obviously this means you > > would > > need some kind of override for per-arch fixes, but preferably these fixes > > will > > be applied twice, once to the per-arch repo, and then to a new unstable > > upload > > which fixes the problem. Uploading only to unstable may cause undue delays. > > Building against testing instead of against unstable also means you > don't have any of the controls testing is supposed to provide to protect > against uninstallable packages: as soon as you build a new library > package, everything that depends on it is uninstallable.
No, because each arch will have per-arch testing support. It is just a way for the arches to catch up with testing, and thus being in line for a release, as when testing gets frozen, those arches will naturally catch up to the frozen and then released stable version, and be ready for a point release later on. > This really makes unstable snapshotting, or building stable once it's > released as Anthony has also suggested in this thread, look like much > better options than trying to build out of testing. We all agree that random unstable snapshotting i no good idea, but i disagree with the stable snapshoting, since this means that the tier-2 arches will only be able to really start working once stable is released, while at the same time working for the next stable release, thus introducing a skew of effort. The proposal i have, altough maybe not perfect, will allow for the arches to continue working at mostly the same pace as the rest of the project, and thus not be excluded. > > > For these reasons, I think the snapshotting approach is a better option, > > > because it puts the package selection choices directly in the hands of > > > the porters rather than trying to munge the existing testing scripts > > > into something that will make reasonable package selections for you. > > > So, why don't you do snapshoting for testing ? Do you not think handling all > > those thousands of packages manually without the automated testing thinhy > > would be not an over-burden for those guys ? > > > You are really just saying that the testing scipts don't scale well, and > > instead of finding a solution to this, you say let's drop a bunch of > > architecture, > > and make it another-one's problem. > > I think we should discuss various solutions to address the needs of > porters involved in non-release archs. I think trying to run a full > testing infrastructure, or build against testing instead of unstable, is > unlikely to be a good solution for those porters in practice because of > some of the issues that I've pointed out. Could you be more clear about this ? which issues are those ? And how do you make sure those arches have a stable base to do their daily work on ? And if testing is not appropriate for them, why don't we drop testing altogether ? Again this smells at kicking them out and letting them in the cold, altough i doubt that was your intention. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
