> On 27 Jul 2017, at 17:06, Christophe Fergeau <cfergeau@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> wrote: >>>>> >>>>> Signed-off-by: Frediano Ziglio <fziglio@xxxxxxxxxx> >>>>> --- >>>>> 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel