[Spice-devel] spice-protocol "mess"
yhalperi at redhat.com
Sun Jan 15 00:13:47 PST 2012
On 01/13/2012 02:17 PM, Hans de Goede wrote:
> On 01/13/2012 12:17 PM, Alon Levy wrote:
>> On Thu, Jan 12, 2012 at 05:52:15PM +0100, Hans de Goede wrote:
>>> While looking at spice-protocol git, to see if we should
>>> do a spice-protocol-0.10.1 too, I noticed a few
>>> 1) the 0.10 branch has a commit from Alon called:
>>> "add opus playback and record cap", which is not on
>> I don't see anything wrong with adding this, since I'm sure we want to
>> have opus. That said, it shouldn't have been there and I think I pushed
>> it by accident, since I never completed the work on the server and
>> client, and so it's of no use right now. (that happened because opus
>> uses 48KHz and CELT uses 44.1KHz)
> Ok, then I suggest reverting that commit for now. I agree it does
> now harm, but it may confuse people into thinking that we do
> have opus support...
>>> 2) master has a commit titled:
>>> "Release 0.10.1", but no 0.10.1 tag, and AFAIK we don't
>>> have 0.10.1 tarbals yet...
>> This is the bump for the mini header support.
> I understand.
>> You call it adventurous,
> It feels adventurous to me I've not looked close enough at it to
> say it really is. I was using the term adventurous in an attemp to
> fish for other peoples opinion on this. But I guess I should be
> more direct. So:
> Alon, you think getting the mini header code into 0.10.1 (and thus into
> the next RHEL release) is a good idea?
> Yonit, do you feel that you're code is ready for this?
I think it is.
>> I think Yonit did all the tests with the new client and the old one,
>> knowing her, but I haven't myself.
> I'm sure she did and I wasn't implying the code is untested, just
> that it is rather new and as such has not seen testing by many
> people under different circumstances.
>>> So we need to sort this out, I suggest:
>>> 1) Adding the "add opus playback and record cap" to
>>> 2) Cherry picking the 3 commits in master but not in
>>> the 0.10 branch into the 0.10 branch
>>> 3) creating a 0.10.1 tag on the 0.10 branch
>>> I wonder though, are we sure there are no adverse
>>> effects of bumping SPICE_VERSION_MINOR to 2? This seems
>>> like a bit of a risky chance to make in a 0.10.x
>>> release. Are we sure all clients and server versions
>>> will grok connecting to / getting a connection from
>>> a server / client with a different minor then themselves?
Connection is refused only if the major is different. As I see it, the
minor is somewhat redundant and implicit way to define capabilities...
I did perform tests of the patches for old-client connecting to new
server, and new client (spicy) connecting to old server.
BTW, Yaniv, can you update the wireshark dissector to handle the new
>> I'm not sure. Someone needs to check.
> Right, which is why I called the code adventurous :)
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
More information about the Spice-devel