On Fri, Apr 23, 2010 at 01:48:01PM +0200, Reinhard Tartler wrote:
On Wed, Apr 21, 2010 at 13:30:55 (CEST), Jonas Smedegaard wrote:I don't understand the libjack-0.116.0 thing. Is that going to be the package name? If so, that sounds like we would be repeating the libjack0.100.0 mistake.It is more like an add-on tag, indicating the library ABI.I deduce from this that you don't want to adjust the shlibs file of libjack package to make application package generate dependencies on libjack-0.116.0 then?No, I want to adjust shlibs file later on, but not required for step 1.I don't see a reason to delay this. Details follow.
Understood (although I do not agree). Sorry for too simplified summary of options - that was not intentional.
Generally speaking [...], I see 3 possible ways forward: * conservative: Stay with jackd1, ignoring jackd2 and tchack. * stubborn: Switch to jackd2, abandoning jackd1 and ignoring tchack. * bold: switch to supporting multiple implementations.You seem to want the stubborn path, because a cross-distro wave have set off.I think adi should decide on this. And AFAIUI, adi has already decided to go with jackd2. He visited me a few weeks ago at my workplace here (he happened to be around for a workshop at my university) and we discussed the pro and cons for the various jack implementations. His arguments were pretty convincing that jackd2 was the best implementation for squeeze.NB: I don't use jack myself, so I don't consider myself qualified to actually backup such a decision. I just point out the results of the previous discussions on this topic.
Regarding earlier decision:I believe previous discussions could be summarized as this list of choices:
a) Release Squeeze only with jackd1 b) Release Squeeze only with jackd2, replacing jackd1I got the impression that even if an option of shipping with both was discussed briefly, it died due to a general assumption that jackd2 was the natural successor of jackd1 and thus keeping both around would only be for the sake of slower transistion (i.e. irrelevant if a faster switch was deemed realistic).
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.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 jackd1I 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).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.
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.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.
I sincerely want jackd2 as default in a multi-implementation scenario. I just feel that we are too close to release to make multiple risky steps.
You (or adi?) want this: 1) replace jackd1 with jackd2 2) readd jackd1 differently named as optional alternativeBoth 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. The second might cause problems in designing package interrelations correctly, and (depending on degree of offered replacements) linking and compiling issues as well.
I want this instead: 1) keep jackd1 as is at first 2) add jackd2 as optional alternative 3) switch around to have jackd2 as defaultAt 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 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!
We as a distribution can (and I think also should) fulfill the following goals:- decide on a default implementation - allow users to switch and use a non-default implementation
Yes. I wholeheartedly agree. But find it insane to set such high goal for the release of Squeeze.
We _might_ reach that noble goal in time. But if we only get half way there, we should have something sane, not something with too high risk of being broken.
Ok, I'll stop now. I keep repeating myself. :-/ - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
