[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] (no subject)



George Dunlap writes ("Re:"):
> On 07/07/16 12:03, Dario Faggioli wrote:
> > So, you're saying I should change both Xen, xentrace_format and
> > xenalyze.c all at once, in the same patch, right?
...
> I think it often does make sense to check things out by component.  And
> of course before xenalyze was in tree, it doesn't matter when the change
> was done.  I suppose I've always been prejudiced against
> xentrace_format, which is why I'd never thought about regressions in it
> (although I probably should have).
> 
> But now that xenalyze is in-tree, I think we want to avoid situations
> where the in-tree xenalyze is broken, even just for one changeset, if we
> can avoid it.

This kind of situation is not that uncommon.  For any part of our
system where we don't offer a stable API, or at least one-way
intercompatibility, it is necessary to make incompatible changes both
in the producer and in all consumers.

(Sometimes this can mean a patch to xen.git needs to be combined with
a QEMU_TAG update for qemu-trad, too; in theory trying to decouple the
Xen API for qemu upstream.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.