On Wed, Jun 27, 2012 at 12:34:36PM +0800, Liang Guo wrote: > On Mon, Jun 25, 2012 at 05:29:09PM +0300, Michael Tokarev wrote: > > > > Why do you say the package is in "bad shape" ? Please explain. > > > > Current version in experimental, if not counting the removal of > > celt, should be quite good, no? > > IMO, spice 0.10.1-3~nocelt in experimental is in good shape, spice > 0.10.1-2 with celt embedded in sid is not.
Then you have nothing to lose by pushing the experimental version to unstable as soon as possible - but this must be done today or tomorrow or you will miss the freeze window and your options will be very much reduced. > > Now, I think the best course to take is: > > > > 1) push current experimental, celt-less version to unstable, > > after some basic verifications of audio. > > 2) maybe update to 0.11, to at least fix known bugs. > > It is unclear whenever upstream will support 0.10 "stable" version, but > > it is more > > "no" than "yes", or else the 32bit bug should have been fixed long ago. > > 3) depending on the result (if it "works at all" or not ;), either keep it > > this way or drop it from wheezy entirely. > > How can we test spice with celt removed to make sure it works fine? if we > can and we do the test. I think it's OK to ship spice without celt to wheezy, > and no technical committee decision is needed. > > Consider another situation, we can do some simple test aganst spice with > our patch that removes celt support, spice client {with, without} celt can > connect to spice server {with, without} celt, and audio works, but we cannot > test spice without celt with older spice used by other platform, should > we include our spice without celt to wheezy or remove it? This is what > I want technical committee to help us to decide. It will take the tech-ctte a considerable amount of time and work to be in a position to judge this better than you and Michael can. This is a job for the normal package maintainers to do. If you say the current package in unstable is in 'bad shape', then if you miss the freeze for uploading the experimental one, your only option will be to remove it. If you put the version in experimental into unstable, then you still have the option to remove it later if problems are reported that become showstoppers. (since they would become release critical bugs that 'automatically' get it removed if they can't be reasonably fixed) > > Sure thing the best will be to have opus support in spice in wheezy. And > > this is the most close variant I can think of. > > I think opus should be added upstream first, then backported to debian or wait > upstream release a version with opus support. If we add opus support ourself, > upstream may add opus support with a way that may not compatible with us, then > we will be in a passive position. Nobody is proposing that *we* do this. It has been discussed with upstream and they are working on it. When they have something to test, then you can begin testing it. So far as I can see, you Michael and I all agree that the experimental package is the only viable candidate for Wheezy. But you will lose that option if you do not upload it very, very soon. The freeze happens in the next few days. Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org