[Spice-devel] [PATCH spice-server] README: Update required protocol version

[Christophe de Dinechin]

> On 27 Jul 2017, at 17:06, Christophe Fergeau <cfergeau at redhat.com> wrote:
> 
> On Thu, Jul 27, 2017 at 04:28:59PM +0200, Christophe de Dinechin wrote:
>> 
>>> On 27 Jul 2017, at 16:04, Christophe Fergeau <cfergeau at redhat.com> wrote:
>>> 
>>> On Thu, Jul 27, 2017 at 03:29:11PM +0200, Christophe de Dinechin wrote:
>>>> 
>>>>> On 27 Jul 2017, at 15:25, Frediano Ziglio <fziglio at redhat.com> wrote:
>>>>> 
>>>>> Signed-off-by: Frediano Ziglio <fziglio at redhat.com>
>>>>> ---
>>>>> README | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>> 
>>>>> diff --git a/README b/README
>>>>> index 45fbe89c..0fd6f071 100644
>>>>> --- a/README
>>>>> +++ b/README
>>>>> @@ -27,7 +27,7 @@ Or to install into a private user specific location
>>>>> The following mandatory dependencies are required in order to
>>>>> build SPICE
>>>>> 
>>>>> -    Spice protocol >= 0.9.0
>>>>> +    Spice protocol >= 0.12.13
>>>> 
>>>> What is the rationale for spice-protocol not being a submodule?
>>> 
>>> It's used by multiple modules (spice-server, spice-gtk, the agent, the
>>> QX driver, ..) and has a stable API.
>> 
>> And how does any of that not make it not a submodule?
>> 
>> - Used by multiple modules: yes, that’s precisely what submodules are
>> for (that’s also the case for spice-common).
> 
> That's also the use case for installed stuff that you look up through
> pkg-config. glib2 is used by multiple modules, but I see noone
> suggesting adding it a submodule.

Of course not, it’s an entirely different project, it’s not the core protocol used by all components!

> 
>> - Has a stable API: yes, but when we need to change it, it would be
>> nice to have that the change recorded in git history of the modules
>> using it.
> 
> We have a vague recording of that when you change the minimal required
> version of spice-protocol in configure.ac.

I love the “vague recording” ;-)

> 
>> 
>> For example, a lot of the streaming work requires a branched-off spice-protocol.
>> 
>> I was also wondering about protocol updates being easier to do in a
>> consistent way if spice-protocol was “above” spice-server and
>> spice-gtk. Which could be solved by having a submodule structure like:
>> 
>> 	spice
>> 		spice-protocol
>> 		spice-common
>> 		spice-server
>> 		spice-gtk
> 
> I'm not sure generating spice-gtk and spice-server tarballs from such a layout
> would be easy (?)

Are you saying that it’s logical to include spice-common in the tarball, but not spice-protocol?

> 
> For what it's worth, I find submodules quite cumbersome to work with,
> they get in the way more often than not when you start making changes in
> one, when you start applying patches inside a submodule, rebasing, …

So you think that if / when Frediano rebases the stream branch in git://people.freedesktop.org/~fziglio/spice-protocol, I won’t have these problems? Of course I will. The only difference is that *git will not tell me*.

>> 
>> instead of the current:
>> 
>> 	(nothing)
> 
> Which is bad because?
> 
> I believe what you are trying to improve is the case when an invasive
> change is being made in both spice-gtk and spice-server, with required
> changes in spice-protocol?

Yes, which is precisely what is happening with streaming, https://github.com/SPICE/spice-protocol/compare/master...c3d:stream.
Where the “canonical” source is, as far as I know, git://people.freedesktop.org/~fziglio/spice-protocol.

> If yes, I don't think anything would force people to have the
> over-arching spice/ module up to date, they could just work only in
> spice/spice-gtk, or in spice/spice-server,

And working in these submodules without updating the top-level is perfectly find, as long as you work in only one.


> and you'd have the same issue
> as you currently are having, no?

I don’t think I would, because my problem is with branches I’m currently working on where multiple components are impacted at once:

- The streaming work.
- The flight recorder work, which led me to these questions (should ‘recorder’ follow the spice-common or spice-protocol model?)
- My investigation on sending feedback to the server from bogged down clients


> 
> Christophe
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel