On Mon, Jul 16, 2012 at 07:36:59AM +0930, Ron wrote: > Since you took the time to at least explain yourself this time,
FWIW, I had written an explanation the previous time too (at least in the form of a control comment), but bts doesn't seem to have sent it; perhaps I failed to escape the shell comment character. Sorry for the unintentionally explanation-free reopen the first time. > and seem > to have an actual rational inkling that this is a horrible no-win corner > that we've been painted into, I did actually just finish writing you a > similarly measured response, figuring we weren't that far from common > ground, and there were a few things you seem to have missed from the long > previous bug log. > > But since Chris has now been encouraged (presumably by the small mob > he tried to incite at a debconf talk) to go from "I won't open this again" > to "I'm going to play the cry to mom card" -- I don't see much point in > wasting even more people's time, by giving them even more to read now. > > I have other work to do, and there's an insane kid in the room now waving > torpedos around, who isn't going to listen to anything we say anyway. I'd still appreciate hearing your response, and I think you might find that Chris similarly would like to find a reasonable solution to this problem. Both of us (and others in this bug) just want to have a usable Mumble without having to install an older version and put it on hold. I think we're *all* not too far from common ground here. Also note that we don't need to actually call on the TC if we can sort this out ourselves; thus, I'd suggest that actually talking to each other seems like the best way to resolve this. A quick enumeration of possible solutions: - Leave mumble out of testing and wheezy, keep it in either unstable or experimental (as we would for any client-server software with an unstable protocol that we can't support for the lifetime of a stable release) with compatibility warnings in the description and NEWS.Debian. - Let mumble migrate to testing and release with wheezy, with similar compatibility warnings. Help upstream get a stable Opus-based version released ASAP for others to use, and ask the stable release managers very nicely about including that version in stable. In both cases, someone interested in having a CELT-based version available for compatibility could consider uploading one to a repository for others to use. If a DD is interested, they could potentially upload a mumble-celt to experimental. Either way, such a package should have giant warnings about security issues. The first approach has the advantage of not shipping an incompatible version of Mumble to stable/testing users, but the disadvantage of delaying the point at which stable users have a version with Opus support. The second approach lets stable users have an Opus-based version as soon as possible, but meanwhile users of stable and testing will have a version that won't actually communicate with anyone other than Debian users. Assuming that CELT 0.7.1 really does have unfixable security issues, it doesn't seem like a reasonable alternative to upload a version that re-enables it. On the other hand, not knowing the details of those issues, I don't see an obvious reason why the issues can't just be fixed as they arise. Any other alternatives, or are those the choices we're stuck with? - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
