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

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



On Fri, Jul 20, 2012 at 08:49:54AM -0400, Chris Knadle wrote:
> On Friday, July 20, 2012 08:32:01, Ron wrote:
> > On Fri, Jul 20, 2012 at 08:14:48AM -0400, Chris Knadle wrote:
> > > On Friday, July 20, 2012 07:54:21, Ian Jackson wrote:
> […] 
> > > > How will this interact with mumble in other distros, who are
> > > > presumably following mumble upstream's advice to use celt 0.7.1 as a
> > > > baseline ?
> > > 
> > > According to Nicos in his last email, not well.  The problem with the
> > > idea is that Speex is not part of the codec selection mechanism in
> > > existing clients, and will thus cause similar issues.
> > 
> > Nicos hasn't talked to Thorvald yet.  The solution to that problem is what
> > Thorvald will be implementing when he gets back, and he thinks he can do it
> > in a way that will be backward compatible for all clients.
> 
> Okay.
> 
> In his previous email, Nicos pointed me to two functions,
> 
> * Server::msgAuthenticate()
> * Server::recheckCodecVersions()
> 
> Which I'm studying to see if I can figure out what Thorvald might have in 
> mind.

Yes, this is why I noted previously that the absence of Thorvald due to
his other commitments was a major concern that led me to believe we may
be better off with this in bpo, where slow but regular fixes could
continue to trickle in as needed over the life of the release.

It took him about 10 minutes to see a solution that all the other people
currently committing changes upstream couldn't or didn't want to see
over the last few months of discussing this with them.


Anyhow, what are we going to do here now?  The package currently in
testing is 100% unusable for anyone with a server, and Ian is asserting
that he'd rather it stay that way until this yak is fully shaved ...

But I don't see any hair left on it.  We have plan, that seems acceptable
to everyone, and that doesn't actually block any of the Worse Plans from
being dusted off again later if something Really Unexpected again foils
us from the end goal.

What's left to stop us from moving forward with this again now?

 Ron



Reply to: