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

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Jun 27, 2016 at 05:12:52PM +0100, 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
> 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.

Yep, there is a vN.N.N-maint branch for every release

NB, with our new numbering that'll be changing nto vN.N-maint instead.

> 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.

Stuff goes onto the stable branches on an as-needed basis - mostly coming
from the distro maintainers response to bug fixes from their users. There's
probably not a whole lot that's touching xen on a regular basis and we're
quite strict in what we accept for stable.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel