[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6 00/11] libxl: ocaml: improve the bindings



On 12/10/2013 01:20 PM, Ian Campbell wrote:
On Mon, 2013-12-09 at 15:17 +0000, Rob Hoes wrote:
This series contains version 6 of the remaining patches to fix the OCaml
bindings to libxl.

The main change compared to version 5 is that we now properly register the
"user" values (OCaml values that are given to the libxl event system, and
returned to OCaml in callbacks) with the OCaml GC.
So the release process has moved on sufficiently that I think we need to
consider whether the previous release-ack still stands:
http://thread.gmane.org/gmane.comp.emulators.xen.devel/180254/focus=180383

I think the arguments made there still stand, in short it would be
awesome if xapi could move to using libxl on top of 4.4 and the risks
are almost entirely contained within this use case, which cannot be
satisfied by the code as it stands today.

Except that that basically calls into question what a "code freeze" is at all. At some point we just need to say, "No more, this is what we have; from now on we work on bug fixes."

We've decided that PVH dom0 and ARM "physical address space leak" fixes are blockers for strategic reasons. Is there a good reason that we should consider updated OCaml bindings in the same light?

At this point, the fact that there is only one downstream user (XenServer) is an argument *against* its inclusion: there is very little benefit, as XS can simply carry the patches if they want to.

The timeframe in which we did this kind of "cost/benefits" analysis for new features was meant to have passed already -- the "grace period" has already been three weeks; the schedule for the code freeze has been published and hasn't changed in 6 weeks.

While I can certainly understand the feeling of "just having missed" when it might have been accepted, given the number of people working on Xen now, I think we are almost always going to be in that situation. We can either keep slipping the window until we happen to get lucky enough not to have any "really nice" features to add in, or we can set a hard deadline and say, "Sorry, that will have to wait." Feel free to make a case for the first, but at the moment the second seems like the only way to proceed to me.

 -George

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.