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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, Dec 10, 2013 at 2:10 PM, George Dunlap
<george.dunlap@xxxxxxxxxxxxx> wrote:
> 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.

If anyone has a better "rubric" to use in situations like these, I'm
open to hearing it...

 -George

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