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

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

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.

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.