packaging jack - cross-distro coordination

[Reinhard Tartler]

On Fri, Apr 23, 2010 at 22:11:15 (CEST), Jonas Smedegaard wrote:
>
> Regarding options:
>
> Let me try summarize anew, given my new understanding (dropping
> potentially provocative names):
>
>   a) Stay with jackd1, ignoring jackd2 and tchack.
>   b) Switch to jackd2, abandoning jackd1 and ignoring tchack.
>   c) switch to supporting multiple implementations.
>
Is, I think these are our options at this point.

> Let me try summarize anew, given my new understanding (dropping
> potentially provocative names):
>
>   a) Release Squeeze only with jackd1
>   b) Release Squeeze only with jackd2, replacing jackd1
>   c) Release Squeeze with jackd1 as default, and optionally jackd2
>   d) Release Squeeze with jackd2 as default, and optionally jackd1
>
> I agree that adi already decided on b).  But at a time when jackd1
> seemed dying and jackd2 its natural replacement - just a question of
> when to switch.  Options like c) and d) was only considered as a more
> gentle transition method, which was later deemed unnecessary.
>
> In other words, it is not my impression that adi already decided on d).

If you put it this way, indeed. the options c) and d) came up after
torben asked us support multiple implementations.

> I do not want jackd1 as default due to being best, but due to being most
> tested.  We are close to release, so any radical is risky.

AFAIUI jackd2 is tested well enough, generally speaking, you are of
course right.

> Switching from jackd1 to jackd2 as default (or only) library and daemon
> is a radical change, which we agreed to do anyway.
>
> Implementing support for multiple implementations of the JACK interfaces
> is yet another radical change.
>
> Two radical changes is one too many IMHO.

Well, given the circumstances, I would still consider this option.

> Replacing jackd1 because we consider it obsolete seemed a valid argument
> for me to take the risk.  But doing it not because we consider it
> obsolete but because we consider it still valid just less interesting is
> too weak argument for a too big risk this late in the game IMO.

sure, you're call. It seems I have a different opinion about the risks
of our options, though.

> You (or adi?) want this:
>
>   1) replace jackd1 with jackd2
>   2) readd jackd1 differently named as optional alternative
>
> Both of those are risky: The first might reveal problems when
> recompiling against claimed compatible but potentially not in reality
> compatible library API and daemon runtime ABI. 

Well, upstream claims that this has been tested in depth. I'm inclined
to trust upstream here.

> The second might cause problems in designing package interrelations
> correctly, and (depending on degree of offered replacements) linking
> and compiling issues as well.

indeed.

> I want this instead:
>
>   1) keep jackd1 as is at first
>   2) add jackd2 as optional alternative
>   3) switch around to have jackd2 as default
>
> At each step we may run out of time and ship that with Squeeze.  It
> makes better sense for me to risk shipping only something too boring for
> professionals to use but not broken, rather than something maybe broken
> and not discovered as such in time because we were busy complicating
> things even furthere.

I see.

>>> I wanted to push jackd2 back when it was seen as the only future,
>>> only a question on when to make the switch.  But when it turns out
>>> jackd1 is intended to be kept alive or and tchack exist as a third
>>> possible future, I find it wrong to pick a single future immaturely.
>>
>> The future in the short term seems to including competing yet binary
>> compatible implementations of jack.
>
> I do not expect us to reach to goal of properly handling multiple
> competing JACK implementations in time for the freeze of Squeeze!

Well, okay, but missing this would be a real shame :-(

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4