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

[Jim Fehlig]

On 06/27/2016 10:12 AM, Ian Jackson wrote:
> Daniel P. Berrange writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?"):
>> On Mon, Jun 27, 2016 at 04:54:35PM +0100, Ian Jackson wrote:
>>> Created the following branch refs on xenbits in the toplevel
>>> libvirt.git:
>>>
>>>   osstest/frozen/xen-4.3-testing 9a0c7f5f834185db9017c34aabc03ad99cf37bed
>>>   osstest/frozen/xen-4.4-testing 33fb8ff185846a7b4974105d2c9400690a6f95cf
>>>   osstest/frozen/xen-4.5-testing cda1cc170f07b45911b3dad03e42c8ebfc210fa1
>>>   osstest/frozen/xen-4.6-testing eac167e2610d3e59b32f7ec7ba78cbc8c420a425
>>>   osstest/frozen/xen-4.7-testing 1a41ed5af5e1704dd9b0bdca40df5c9cacbdabfc
>> How did you pick those hashes ? Would it make more sense to pick the
>> nearest libvirt release tag ? eg v1.3.2 instead of 33fb8ff18584 ?
>>
>>> These were those tested by the following `tolerable' osstest push gate
>>> flights for the corresponding Xen tree:
>>>
>>>   xen-4.3-testing 9a0c7f5f8341 86673
>>>   xen-4.4-testing 33fb8ff18584 85031
>>>   xen-4.5-testing cda1cc170f07 83135
>>>   xen-4.6-testing eac167e2610d 96031
>>>   xen-4.7-testing 1a41ed5af5e1 95728
> I picked them by searching my mail archives for osstest `tolerable'
> push gate flights - ie, passes in our CI system.
>
> That minimises the risk that the selected versions are themselves
> troublesome for some reason, needing another round of adjustment.
>
> It might indeed be better to convert them to nearby release tags.
> However:
>
> mariner:libvirt> git-describe 9a0c7f5f834185db9017c34aabc03ad99cf37bed
> v1.3.2-202-g9a0c7f5
> mariner:libvirt> git-describe 33fb8ff185846a7b4974105d2c9400690a6f95cf
> v1.3.2-rc2-1-g33fb8ff
> mariner:libvirt> git-describe cda1cc170f07b45911b3dad03e42c8ebfc210fa1
> v1.3.1-262-gcda1cc1

It seems odd that Xen 4.5 would use an older libvirt release than Xen 4.3.

> mariner:libvirt> git-describe eac167e2610d3e59b32f7ec7ba78cbc8c420a425
> v1.3.5-318-geac167e
> mariner:libvirt> git-describe 1a41ed5af5e1704dd9b0bdca40df5c9cacbdabfc
> v1.3.5-129-g1a41ed5
> mariner:libvirt>
>
> So in most cases these hashes are well away from a release tag.
>
> 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.

Regards,
Jim