[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#602143: ITP: spice -- a remote display system for virtualized machine and desktop



Hi Marc-André,

On Thu, Nov 04, 2010 at 04:10:03PM +0100, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Nov 2, 2010 at 1:46 PM, Ron <ron@debian.org> wrote:
> > On Tue, Nov 02, 2010 at 08:15:42PM +0800, Liang Guo wrote:
> >> Great, if SPICE can be ported to the latest celt, we need not keep two
> >> different version of celt in debian. Ron, the maintainer of celt in
> >> Debian, prefer this methord.
> >
> > Indeed, since we'll be targeting a debian release that is some 2 years
> > away from the present, it is quite likely that celt will in fact be
> > bitstream frozen by then too (or replaced by a derivative that is).
> >
> > Adjusting to the newer API should be trivial, the main catch is the
> > bitstream compatibility.  I don't think we should be looking at
> > packaging celt 0.5 retroactively though, we should be looking ahead.
> >
> 
> You can find a untested patch I wrote to support celt latest in
> addition to celt 0.5 here:
> http://gitorious.org/spice/elmarco-spice/commit/e310493a3e5a28f4b41dbc13cfaad7f982bca651
> 
> However, this patch is not suitable for upstream, because it obviously
> breaks compatibility between various version of client/server.

Well I wouldn't say "unsuitable" for upstream, but indeed it only solves
a part of the problem which they need to address still.  CELT is an
experimental codec, so the bitstream is still in flux, and this was known
when a snapshot was picked by spice.  It's time to activate the contingency
plan that was created for exactly this situation when they made that choice.

They did think this through already, right?

Somebody just needs to implement the content negotiation, or whatever they
have decided for it.  It was a redhat project, so they did what worked for
them to get a trial version out.  If people are going to pick this up for
other distros now, that's one of the things they'll need to get right.
celt-0.5 is dead.  Someone just needs to tell spice that.  With flowers
and stuff.  And then we can all move on.


> Imho, we should consider celt 0.5 as being the current "frozen" bitstream

Except unfortunately, your ho was out of the loop when this decision was
made, and you're late :(  We already had this discussion, between the
interested maintainers of packages and upstream celt folk.  It seemed
important to know the answer to that _before_ squeeze froze.

And so we consider 0.7.1 to be the "current" stable snapshot bitstream,
and that's the one we hope people will settle on for a while.  We made
sure this went out with ubuntu, it's what we stopped at for squeeze,
and it's what we're encouraging everyone else to play along with until
the next one (which might hopefully be the last, but might not be 'celt'
anymore per se).  We even have some coordination on this with other
legacy OS vendors I believe.


> (there has been already maintenance release of this version).

There were a couple of small brown-paper-bag tweaks in the first month
after that snapshot was made.  It's not maintained by the upstream celt
author, responsibility for it rests with redhat.  It hasn't been touched
since early May 2009 ...

> We need to package it for Debian instead of pushing for an
> unstable version of celt in spice.

Spice already has an unstable version of celt.  They knew that when they
picked it.  If spice is going to be suitable for debian and other distros
this is a problem they'll have to solve, because it's going to happen
eventually, even to redhat.

Squeeze should be rolling out soon, so you've got 18 months to figure out
how this should work in a way that is suitable for the next release.
The answer to that isn't dredging up the corpses of long expired snapshots
of experimental libraries.  They need a transition plan.  And you'll have
a testbed to try it out on - and at least a year to get it right.


Since there are clearly people interested in this, and able to write some
code, I'd suggest talking to spice upstream, and maintainers of the other
apps, and bringing more of them into the loop _before_ we have to make this
decision again next.  Even if the one after this does freeze the bitstream
permanently, there's still going to need to be a transition for spice.
If there has to be more than one, it will be better if all the app authors
can agree on that together.  It's good that there are early adopters, but
we can't just package a separate version of celt for every app that paints
itself into a corner with experimental code.  The old snapshots do have a
use-by date, just like the draft RFCs that define them.

Sorry.  This does seem like a cool thing to get into the distro, but you've
got time, so let's do it properly and solve it for everyone.

Cheers,
Ron





Reply to: