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

[Christophe Fergeau]

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.

> - 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.

> 
> 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 (?)

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, ...

> 
> 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?
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 you'd have the same issue
as you currently are having, no?

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20170727/ed85cec3/attachment.sig>