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. 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). > 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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature