Bug#678679: Spice, current status and the fueture in Debian
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
Reply to: