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

Re: Bug#682010: re celt and mumble referred to the TC

On Thursday, July 19, 2012 14:23:31, Ron wrote:
> On Thu, Jul 19, 2012 at 12:55:59PM +0100, Ian Jackson wrote:
> > Ron writes ("Re: #682010 re celt and mumble referred to the TC"):

> > > 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 mean mumble embeds something like seven mutually incompatible versions
> of celt, all of which it provides as private implementation libraries
> on every platform except Debian - because nobody else provides the version
> that we do.  And we only provide that version because upstream tagged the
> current head on a random day when Thorvald and I said, "if we're going to
> do this, we need it today".
> The idea was, he was going to try to get everyone else to use it too.
> But that failed completely, so all we have now is this random Debian-
> specific snapshot, that nothing and nobody else uses or interoperates
> with, and which mumble has to embed anyway for every other user.

When I test the version in Wheezy that uses celt I'm able to interoperate with 
any public server, whether it be a Debian platform, Gentoo, Fedora, Windows, 
FreeBSD, but I often cannot with the version in Sid.  :-/

> It really is time to just admit that was a mistake, and correct it.

However as I said I also don't disagree with this.

An alternative I've been thinking about would be an additional text file in 
the Mumble package (FAQ.txt, PROBLEMS.txt -- whatever filename seems logical) 
which could contain information concerning removal of the CELT codec and the 
reasons why -- dead upstream, security concerns, etc.  Enough information 
(such as that you've already provided) that's easy enough to find so that 
there's at least a chance for users to find it, or something to point them to 
if they open a bug report ... and then we suffer for a bit until Opus support 
gets more widespread.

What I'm really looking to try avoid are repeat events of someone installing 
Mumble, finding or opening a bug report, and receiving back [this is not an 
accusation] "this isn't a bug <closed>" because the users lack the 
information, and it being too exasperating for any maintainer to give the long 
explanation repeatedly.

This is why I've been asking whether an entry in NEWS.Debian makes sense.  Or 
perhaps both makes sense: a NEWS.Debian entry for "please read FAQ.txt in 
/usr/share/docs/mumble relating to why some audio connections fail currently" 
or something to that effect.

Not optimal of course, but no solution to bug ever will be.

  -- Chris

Chris Knadle

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: