On Saturday, July 21, 2012 02:42:43, Steve Langasek wrote: > 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). > > From the BTS, it doesn't look to me like this summary has taken? > > > 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. > > If the original petitioner is satisfied with the solution and no longer > feels the need to involve the TC, I don't see any reason for the TC to > remain involved. Certainly historically, we have considered our job done > once there's no longer a dispute that someone wants escalated to the > committee. It's not at all our charter to fix all the bad bugs, only to > adjudicate when consensus can't be reached on its own. If Chris and Ron > *are* working together now towards an agreed solution, I'd much prefer that > we let them get on with it. 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. [1] [Special thanks goes to Nicos for watching our backs here.] In terms of existing servers, this would in effect be equal to the "only use Opus" option that currently exists in Sid right now, which is unable to interoperate _at all_ with every available version of the client on at least one platform. I'm pretty sure it's not a viable option. So while I was initially enamored with The Plan, I'm now back to being concerned after looking at the code Nicos pointed me to. [2] I think it's clear now that we need to explicitly check with him on the proposed solutions, because he's consistently given sage technical advice in this matter. So I wish we were done with the TC, but I don't think we are -- this is a really tough problem. Right now I think if we want to be fully interoperable, we're going to require embedded celt -- I don't like this alternative either, but AFAIK it's what the other distros are doing, and the alternative of continuing to use the celt 0.7.1 library is likely to be deemed just too heinous and evil because we really need to stop proliferating it if at all possible. Nicos -- let me know what you think. > It may be that it's Ian's intention to take up this issue in Chris's stead > because he himself thinks there's a problem that he wants to put before the > TC. That's fine too, but I think in that case, Ian, you should state this > explicitly (and, logically, recuse yourself from voting on it under 6.1.2, > 6.1.3, or 6.1.4 since you're then a party to the disagreement). I think Ian saw that I was too enthralled and that I jumped to conclusions, and put things on hold to give time for a sanity check. I commend him for doing that as I think that's generally wise, especially where the author for the solution was going to be away for a week. Additionally as Ian took the lead on this problem, I really don't want to commit to go off and take action without his input -- that definitely wouldn't seem right to me. > > 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. > > > > 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? > > From what I've read here, I don't think there are *any* ideal solutions. > We cannot retroactively cause all deployed clients on other OSes (or on > other versions of our own OS) be willing to negotiate a codec they don't > already negotiate; all clients on a given server must use the same codec > to talk to each other; and the set of codecs supported by all clients > appears to be the empty set, unless we want to all agree to use an > obsolete experimental codec which suffers from serious non-theoretical > security issues. > > So I'm really not sure why it's useful for the TC to be debating which of > the bad options we consider least bad. There isn't much choice, as lack of interoperability was why the matter was brought to the TC, and the action chosen directly affects interoperability. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#114 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#42 -- Chris -- Chris Knadle Chris.Knadle@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74
Attachment:
signature.asc
Description: This is a digitally signed message part.