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 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120720231110.gt18...@audi.shelbyville.oz