From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 00/18 v3] libxl: fork and event fixes for libvirt and 4.4 Date: Thu, 6 Feb 2014 10:52:39 +0000 Message-ID: <52F36977.6030106@eu.citrix.com> References: <1391444091-22796-1-git-send-email-ian.jackson@eu.citrix.com> <52F24642.5000300@eu.citrix.com> <21234.21167.684304.970488@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21234.21167.684304.970488@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Jim Fehlig , xen-devel@lists.xensource.com, Ian Campbell List-Id: xen-devel@lists.xenproject.org On 02/05/2014 03:03 PM, Ian Jackson wrote: > George Dunlap writes ("Re: [PATCH 00/18 v3] libxl: fork and event fixes for libvirt and 4.4"): >> On 02/03/2014 04:14 PM, Ian Jackson wrote: >>> This is the latest version of my libxl event fixes apropos of Jim's >>> libvirt testing. >> Did you have any opinions on the suitability of this for 4.4? > Sorry, I should have made that clear in the body text rather than just > the subject line. > > I think this needs a freeze exception on the following grounds: > > * There is little change visible to non-eventy/thready callers and > the risk of new races there is limited; basic functional testing > ought to catch those errors. > > * The most prominent eventy/thready caller we are currently aware of > is libvirt. Without these changes it is nearly impossible to have > a reliable libvirt. Thanks. I think libvirt support for libxl is a really important functionality from a strategic perspective: a solid support should make it much easier to integrate with other projects such as OpenStack and Cloudstack, as well as (in theory) other tools built on top of libvirt. So I'm inclined to consider this a blocker*; I think we should accept it and delay the release until we feel comfortable that it has been sufficiently tested. Release-acked-by: George Dunlap * "blocker" is never an absolute specification; there is almost always a point where we would say, "we're just going to have to release without this". Specifying a feature or bug a blocker just means, "At this point, we are still willing to slip the release if necessary to include this feature / bug fix."