[libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

[Jan Beulich]

>>> On 27.06.16 at 18:54, <ian.jackson at eu.citrix.com> wrote:
> Jim Fehlig writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver 
> breakage -- where to define LIBXL_API_VERSION?"):
>> On 06/27/2016 10:12 AM, Ian Jackson wrote:
>> > Does libvirt have stable release branches ?  One approach would be to
>> > have osstest track a suitable libvirt stable release branche for each
>> > Xen stable release branch.
>> 
>> I see Daniel already answered this question.
>> 
>> >
>> > That would involve setting up a push gate for each of the chosen
>> > libvirt stable branches.  That would be worthwhile if we expect those
>> > stable branches to acquire commits which break Xen, and which we could
>> > like to be told about.  But I'm not sure that's the case.
>> 
>> I occasionally backport Xen bug fixes to -maint branches. Cole has
>> also grabbed some Xen bug fixes when making a stable release of a
>> -maint branch. But such backports should be trivial and obvious bug
>> fixes that shouldn't cause build or runtime breakage with Xen.
> 
> OK.  Thanks for the feedback.  I'll go ahead with my plan with the
> git commit ids named in my earlier email.

The only (hopefully highly theoretical) problem I see with this is that
we may end up picking a libvirt commit which subsequently (e.g. via
a libxl backport) turns out to have an issue. Such a problem could be
dealt with in the suggested the stable branch tracking model (or any
other model not dealing with something completely frozen).

Jan