>>> On 27.06.16 at 18:54, <ian.jack...@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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel