Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Fri, Jul 20, 2012 at 02:48:07PM -0700, Don Armstrong wrote:
> I've updated the summary with the suggested changes (at the end).
>
> On Sat, 21 Jul 2012, Ron wrote:
> > I think that's roughly right. If there's anything more people need
> > clarified or answered, just ask.
>
> [...]
>
> > And I'm still not quite clear what his objection was, because the
> > response I got was:
> >
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#124
>
> The objection is that the issue has been raised before the CTTE, so it
> needs to be resolved first before action is taken.
That part I understand. It was the what still needs to be resolved if
all the parties agreed on a solution part that I was still in the dark
about mostly ...
> From what I
> understand now, while we could fix up some of the RC issues with the
> client/server in testing and unstable, we'd need yet another upload of
> mumble to unstable with propagation to testing in order to actually
> fix the client inter-operation bug.
Yes, that's correct. Whatever Thorvald comes up with will require
another upload.
> From what I can tell now, the ideal solution is to wait until Thorvald
> has a chance to enable speex for all bandwidths. If that is
> impractical/impossible then we get to choose between a convenience
> copy of celt, not releasing mumble, or releasing with opus. Is that
> the understanding of everyone else?
Yes, that's pretty much how I see what our choices are, unless Thorvald
thinks of something entirely different again when he looks into the
first option. We only got to talk through this very briefly before he
had to leave, but he was fairly confident, and he's on the short list
of people whose ability and confidence I've found tend to be fairly
reliably well correlated, so we'll see ...
Which really only leaves me with the question of what do we do today.
Right now the server in testing is completely broken if we don't let
the unstable version which fixes that migrate. If that stays blocked
until we have Thorvald's fix, we're looking at it being broken for
a week until he gets back, a few days to a week until he has a patch
he's happy with, 10 days before it's eligible to transition, and a
bigger patch for -release to review before they consider unblocking it.
So it will be broken for somewhere from a couple of weeks to a month,
depending on who works how fast and whether -release would be willing
to age it in faster.
If we let the current unstable version transition today, we mitigate
those two things, and it doesn't change anything about our ability
to fall back to the plan B set, if that turns out to be needed.
I'm not too fussed either way to be honest. It's extra work and
inconvenience for people _other_ than me if it isn't allowed to
migrate now. But whether it can is out of my hands at present,
since TC put a block on the RMs unblocking it, and I haven't asked
the RMs for their preference yet because of the TC stop work order.
I'm fine with this issue being left open with the TC until its
final resolution independently of that though. I don't see these
things as being tightly order dependent. Either way there is work
and uploads to be done before we have our final answers for Wheezy.
One very last thing then, before I hopefully stop bothering you
for a while (:
> ** Use speex instead
> + Clients cannot currently report speex version during codec selection process
I don't understand where that issue came from?
Speex has been API and bitstream compatible since, like 2006, or maybe before.
Maybe I totally misunderstand what that's saying, but anything relying on
a "speex version" is almost surely Doing It Wrong.
It's probably not important, I'm just not sure who is actually confused there.
Thanks Much!
Ron
Reply to: