Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Sat, Jul 21, 2012 at 03:46:34PM -0400, Chris Knadle wrote:
> The issue I have now is that The Plan that Ron and Thorvald have come up with
> Will Not Work, depending what the _goal_ is. If the goal is to be able to
> interoperate with the existing *server* base [which was exactly why this came
> to the TC in the first place], that won't be possible -- because the Speex
> codec up to this point is not part of the selection process in the existing
> servers.
I am 110% certain that Thorvald is not going to accept any solution that he
thinks can't be made to work for the vast majority of users. That was the
crux of our conversation last week, and something which he has always been
unwavering about. We have had many such conversations in the past, trying to
reconcile the, uh, idiosyncrasies, of gamers with best practice for Debian.
What you seem to have failed to note, or that Nicos has failed to tell you,
is that Speex is not included in the server side negotiation because it is
assumed axiomatically that *every* client has speex decoding ability. So
it does not need to be negotiated. You can send it at any time, and it will
work, without needing to be announced in advance, or the server needing to
do anything.
That point is currently still true. Every existing client has the ability
to *decode* speex if speex packets arrive.
The only thing removed from recent clients was the ability to encode them.
This is what we need to restore.
> [Special thanks goes to Nicos for watching our backs here.]
Just to be clear here, because at some point Ian described Nicos as being
"a mumble developer", and you have now declared him a "sage" ...
$ git log master | wc -l
30363
$ git log master | grep Nicos | wc -l
12
And all of those commits afaics relate to GUI overlay stuff for games,
nothing at all to do with the protocol negotiation we are talking about
here ... So I think I'd still rather put my trust in the the opinion
of Thorvald about what can be made to work, than in someone who has said
repeatedly, "Debian should just remove this, nobody cares because nobody
uses Debian anyhow". Which is also clearly quite incorrect, or we wouldn't
be having this discussion at all.
The current facts are:
- The server is currently 100% broken in testing, and will remain so
for our users for as long as this is blocked here.
- Thorvald has a plan that nobody here had thought of or considered
previously. We can't assess that until he gets back and implements
it - but second guessing him here in the meantime is only going to
waste his time with more mail to read before he gets to doing that.
And his time is already very limited.
- If that plan doesn't work, we have other plans we can weigh up
falling back to.
- If we have to fall back to those plans, and -ctte wants to assert
that it would rather Debian ship an unmaintained codec, which nobody
has spent more than a couple of hours quickly auditing for obvious
problems, but which does have a real suspicion of deep problems ...
Then provided we have a clear public record of the people wanting
that putting *their* own heads on the block, and taking the full
responsibility for any fall out or required remedy -- then I have
clean hands, and someone to point at who is completely to blame for
an action I advised against in the event it goes Horribly wrong.
If the people wanting that can get the consensus of the TC (and
I would much rather see this as an even informal consensus than
than as a formal but narrowly won vote), then I'll set my own
objection aside and we'll let history and fate be the judge.
Worrying about things that we aren't precluding as fallback options
before we've confirmed we do need to fall back to them doesn't seem
particularly productive to me though. I think Steve pretty accurately
spotted there are _no_ ideal solutions here. Hopefully mumble will
improve on these things too and this will be less of a problem for
Wheezy+1, but in the meantime I think we need to balance the amount
of inconvenience some users might experience (which seems unavoidable
whatever we do) against the amount of risk we are prepared to expose
them to (which seems quite avoidable).
The weekend here is nearly over, and I can't keep stealing time from
my Work customers to keep discussing this in circles next week (and
I'm sure many others here are in the same position).
The longer we draw this out, the less testing any of it is going to
have, the less time is going to be available to fix any shortcomings
that we haven't so far seen, and the poorer the result that we are
ultimately going to end up with.
Ron
Reply to: