[Spice-devel] [PATCH 0/2] Make plugin version checking more robust

[Lukáš Hrázký]

FWIW, personal opinions below :)

On Tue, 2018-03-27 at 10:56 +0200, Christophe Fergeau wrote:
> On Tue, Mar 27, 2018 at 10:28:24AM +0200, Christophe de Dinechin wrote:
> > 
> > 
> > > On 27 Mar 2018, at 10:12, Christophe Fergeau <cfergeau at redhat.com> wrote:
> > > 
> > > With the right patch attached this time.. ;) I've only compile-tested
> > > this as this really is just a proof of concept at this point.
> > 
> > If I understand correctly, you break the ABI twice,
> 
> Ah, could be, minimizing ABI breaks was not really a goal in that split.
> What matters in my opinion is that we decide to break it, once we've
> made that decision, the number of commits which are going to make ABI
> breaking changes is less important.

Agreed, I wouldn't try to minimize the number of commits in which we
break the ABI once we have to do it. Especially if the commits are
going to be pushed together, practically making it a single breakage
for anyone that pulls it (unless he goes messing with the commits).

We certainly aren't going to squash unrelated changes because of this,
so I don't think we need to take this into regard...

> > and you rely on a “side effect” of changing the variable name to avoid
> > conflicts that would otherwise arise with the version number alone?
> > 
> > It makes the history fo the code harder to track, and the changes more
> > “subtle". At the very least, I would add a commit log explaining that
> > since you can’t rely on version numbers alone since the version
> > numbering scheme changes, you renamed the variable used to track
> > version numbering.
> 
> I don't understand this part :) 
> 
> > Also, that means you need to follow the same patterns in locksteps for
> > the plugins, so you are not just making the history of the agent
> > complicated, but also the history of the plugins.
> 
> Hmm how do we cope with ABI breakage with respect to plugins is an
> interesting question. When the ABI is in flux in git, it's not going to
> be easy to link an arbitrary plugin commit to the agent commit(s) which
> have the ABI the plugin expect anyway, so I would say that we want git
> master of the agent to work with git master of the plugins. I would not
> require plugins to have at least one commit working with each commit of
> the agent.
> On that note, we should strive to never break plugin ABI, only extend
> it. The plugins are in their infancy at the moment, so we can do some
> breakage now while to put everything in place, but ideally we'd settle
> on something stable "soon"
> 
> > So overall, a lot of additional complication. What is the benefit?
> 
> The benefit is that we don't have unrelated changes grouped together in
> a big commit.

... However, I do find this request a bit unnecessary, the versioning
mechanism changes seem fine to me in a single commit. I think it just
adds work to c3d and makes several people spend time discussing it :)
with little benefit.

The changes certainly aren't unrelated :)

Just my $0.02...

Cheers,
Lukas

> Christophe
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel