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

[Christophe de Dinechin]

> On 27 Jul 2017, at 17:00, Victor Toso <victortoso at redhat.com> wrote:
> 
> Hi,
> 
> 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).
>> - 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.
>> 
>> 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-serverr and
>> spice-gtk. Which could be solved by having a submodule structure like:
>> 
>> 	spice
>> 		spice-protocol
>> 		spice-common
>> 		spice-server
>> 		spice-gtk
>> 
>> instead of the current:
>> 
>> 	(nothing)
>> 		spice-protocol
>> 		spice (not called spice-server)
>> 			spice-common
>> 		spice-gtk
>> 			spice-common
>> 
>> Christophe
> 
> Another discussion about how things should be done?

Not how things should be done, more “why are they done like this”. Trying to understand if
it’s just “design by history and random evolution” or if there is an actual rationale behind it.

> 
> I don't see what you want to achieve here. Renaming? spice-protocol as
> submodule? Why do you think this is important?

As I wrote above, if only because spice-protocol is currently a branch for the streaming work.

If I want to share a series of patch that impact multiple components, say (at random) my
flight recorder work, I don’t see a good / consistent way to do it today.

- Should I make ‘recorder’ an independent module like spice-protocol? But if so, how do I sync it with the code using it?
- Should I make it a submodule like spice-common? But then, isn’t it annoying to have that in half a dozen projects?

What do you think is the correct way?


Christophe

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