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

Fri Jul 28 07:50:00 UTC 2017

> On 27 Jul 2017, at 17:35, Frediano Ziglio <fziglio at redhat.com> wrote:
> 
>> 
>> 
>>> 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
>> 
> 
> So... you open a forum after we are discussing PRs and so on
> with questions about repository renames, you reply to a mail
> that update a dependency version in a README file and at the
> end you ask why you can't do with your `recorder`.
> Maybe it's just me but I'm a bit confused :-)

Believe me, I’m more confused than you are.

I should have made it clear since the start that all my questions stem from
the trouble I have finding the right way to do things on the various
topics I’m currently working on.

I decided to start replying in patch comments because the answer I was
getting each time I asked a question or raised an issue was “there is no problem”.
So I decided to no longer stay mum about the problems and questions I have,
and point them out in patches. Sorry if it started with yours ;-)

Right now, one of my problems is “why is the code organized this way”,
which derives from my desire to work on three topics that impact more than
one module, and “doing the right thing” for this work:

1. the work on streaming, where I had all the trouble in the world
figuring out where the “correct” source code was, and still have issues
sync’ing with the rest of the world (e.g. when I want to update with
‘master’, but your branch is not up to date)

2. the work on the flight recorder, where I know where the source code is,
but I don’t know how to share that in a way that would be convenient for others,

3. the discussion / investigation on how to send feedback about overloaded client,
which seems to imply some protocol change. I actually want to use the fllght
recorder for the investigation, but that’s still a separate topic, so I wish I could
easily switch branches between ‘recorder’, ‘stream’, ‘master’ and ‘overload’
for all 4 components that are impacted without having to do it manually.

> 
> Maybe the solution for multiple repository to update is using
> the same name for the branch.

That’s not really a solution, but that’s a good damage reduction measure.

> 
> Not clear how your recorder interact with git.

At the moment, it is a separate submodule. For server and gtk, I made it
a submodule of spice-common, and moved some of the log stuff there.
For the streaming agent, it’s just a regular submodule.

Thanks
Christophe
> 
> Frediano
> _______________________________________________
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20170728/be88d6dd/attachment.html>