>>> On 27.06.16 at 18:54, <ian.jackson@xxxxxxxxxxxxx> wrote:
> Jim Fehlig writes ("Re: [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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list