[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

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|

Reply to: