Aurelien Jarno wrote: > I know that it is to late for etch, but that could apply for etch + 1. > What do you think? I think this is the wrong way to go.
The major problem which has caused major clogs in 'testing' is that different transitions have been getting tied up with each other. This has also been the main cause of important packages being kicked out of 'testing' -- breaking transition linkages. Packages with no dependencies on transitioning libraries have moved to 'testing' like clockwork. The enormous ABI transitions have been particularly hard, of course. If we can avoid ABI-breaking transitions in the future it would help. :-) I think we have a poor image of the effectiveness of 'testing' because *both* of the last two releases have had one of these monster ABI transitions. And droppping 'testing' before a giant ABI transition may, indeed, be a good idea. But I think it's a bad idea the rest of the time. I think making a queue for transitions, so that they're basically one at a time, would solve most remaining problems. Particularly with packages like 'arts' which build a bunch of binaries against different libraries, apparently unrelated library transitions get knotted together quite easily. If (for example) the JACK transition had finished before the C++ transition started, or vice versa, there would be either an ARTS-with-old-ABI-and-new-JACK, or an ARTS-with-new-ABI-and-old-JACK, in 'testing' right now, and things would look much smoother. The CVS-like solution, of course, would be a 'branch' distribution for each transition, each of which merges when ready (so both of those hypothetical ARTS packages would have been ready to go in), but the infrastructure isn't anywhere near set up for it, as it would certainly require branch-and-merge-ready version numbers. But since that's not plausible right now, running all transitions in an orderly queue is the way to go. That does mean that unstable will be 'semi-frozen' nearly all the time for one transition or another. Barring giant mega-transitions like the C++ ABI transition, however, only a relatively small subset of packages should be frozen at a given time (the ones involved in a particular shlibs or other major dependency change), and they should generally be only semi-frozen (not allowed to undergo shlibs or other major dependency changes). -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
