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

Frediano Ziglio fziglio at redhat.com
Thu Jul 27 15:35:56 UTC 2017


> 
> 
> > 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 :-)

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

Not clear how your recorder interact with git.

Frediano


More information about the Spice-devel mailing list