Re: #682010 re celt and mumble referred to the TC
Ron writes ("Re: #682010 re celt and mumble referred to the TC"):
> You understand this is a fairly arbitrary 'daily' snapshot of an
> experimental research codec, from ~2.5 years ago, that nobody has
> looked at since that day, that nobody has committed to maintaining,
> that its author has explicitly said he has no interest in maintaining,
> that has had large parts completely rewritten since for all manner of
> reasons, and is bitstream incompatible with every other snapshot that
> was ever released, right?
However, it appears that some other distros have chosen to ship this
particular version. For example at least Ubuntu are still
distributing it.
> > - This is a serious problem for mumble at least and is arguably RC.
>
> Yes, mumble has a serious problem, that is arguably RC.
> In fact it has several of them aside from this corner that people
> have painted themselves into with it ...
>
> - Its primary author, who is also a DD and comaint of the package,
> is currently MIA with a new job that has consumed pretty much
> every minute of his time for the last 2 years or so now.
>
> The people who remain that are hacking on it, can't even do a
> formal new release at present, because he is the only one with
> access to the systems they need to do that, and is not available
> to do so.
I'm not convinced by this complaint. The whole point of free software
is that it is possible to carry on without needing the cooperation or
involvement of one's upstreams.
Also, are you saying you think mumble should be removed ? Now is a
bit late to be deciding this.
> If I'd known that Thorvald was not going to be here to manage this
> transition for Wheezy, I'd have never agreed to shipping libcelt in
> the Squeeze release either, and would have instead kept it in sid
> only. If I'd known that his plan to have all other distros ship
> the 0.7.1 release as a temporary interoperability snapshot would
> fail as dismally as it did (no other distro shipped this version
> except debian derivatives who took it from us), I'd have similarly
> vetoed the idea of shipping this as a public library in the last
> stable release too.
I think interoperability with the ecosystem of our derivatives is
sufficiently important that it's worth preserving.
> Mumble already ships this as an embedded private library on every
> system other than direct Debian derivatives.
I'm not sure exactly what you mean. Do you mean they support some
other version of the celt codec ? Or are you just talking about how
they manage the packaging ?
I certainly think it's better to have the celt codec, even if it's an
unreleased and now-unmaintained-upstream snapshot, in a separate
package, than in an embedded library.
> I see that this proposal has already resulted in Chris skating down
> the slippery slope of "let's re-enable it for everything else too".
> And we'll get people with no experience or prior involvement to
> maintain it, and we'll enable multi-arch too, and ...
Your message has too much personal animosity in it.
> So I really hope that it's actually clear to the people presiding
> over the tech-ctte, that the *whole point* of a codec is that it
> lets you *interoperate* with others. Which this snapshot does not.
It lets you interoperate with Ubuntu, and with users running squeeze.
> If people really want to do this for mumble, then it really ought
> to be done as a private implementation detail, like it is for every
> other platform - not by setting traps in public for the unsuspecting
> and otherwise uninformed. If we ship celt publicly, we are sending
> the message that people should use it. That's the wrong message
> for an obsolete, unmaintained codec, and there is no reason to tie
> 'being pragmatic' about the mumble screwup to making an even bigger
> mistake. That's not 'avoiding risk', it's "not avoiding risk".
> And one that is really, really trivial to avoid.
Just to be clear, you seem to be suggesting that while reintroducing
libcelt as a package is a bad thing, it would be fine to reintroduce
it as an embedded library in mumble ?
> My general feeling is that mumble is currently in an awkward state
> which really doesn't make it a good release candidate for Wheezy,
> and we'd probably be best served by simply dropping it from testing,
> fixing this in sid as the fixes come or are needed, and then pushing
> snapshots to bpo as we have reasonable candidates for that.
I don't think this is a good approach. But I'm pleased to see that
you agree that this is probably an RC problem.
Ian.
Reply to: