Re: [PATCH 00/18 v3] libxl: fork and event fixes for libvirt and 4.4

[George Dunlap <george.dunlap@eu.citrix.com>]

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 <george.dunlap@eu.citrix.com>

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