On 27 Jul 2017, at 17:00, Victor Toso <victortoso@xxxxxxxxxx> 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@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).
- 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 onwith questions about repository renames, you reply to a mailthat update a dependency version in a README file and at theend 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