Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
>> On 27.06.16 at 18:54, <ian.jackson(a)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