[Spice-devel] [PATCH spice-gtk] RFC: Use spice protocol as a submodule

[Alon Levy]

On Tue, Apr 10, 2012 at 11:40:32AM +0200, Christophe Fergeau wrote:
> On Tue, Apr 10, 2012 at 11:28:34AM +0200, Marc-André Lureau wrote:
> > On Tue, Apr 10, 2012 at 11:09 AM, Christophe Fergeau
> > <cfergeau at redhat.com> wrote:
> > > For what it's worth, one scenario where it's easier to go wrong than before
> > > is when distro patches have to be added to the protocol headers (for
> > > example enum values which are used in messages sent over the wire). This
> > > happens when distros decide to backport useful features. Before,
> > > all that was needed was patching one place (spice-protocol), now the header
> > > needs to be patches N times, and it's not even a straight cherry-pick from
> > > git, so I can imagine things going wrong there.
> > 
> > If the project you build includes the protocol feature you wanted,
> > then the result is correct. Before that, you had to recompile all the
> > projects depending on spice-protocol, to make you sure didn't break
> > any.
> 
> For protocol additions, you didn't really need to rebuild projects not
> using what was added.
> The case I have in mind is for example someone backporting support for
> controller message B in spice-xpi, and someone else backporting support for
> controller message A to spice-gtk, and one of the 2 not paying attention
> there are 2 different new messages. I agree this is a bit of a corner case,
> but imo this is a drawback compared to how it used to work....
> 

So the golden rule should be to not backport spice-protocol but use a
version from upstream, not neccessarily the latest. Backporters beware.

> Christophe



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