Hi Fijal,
I agree that jffi would be both a large project and without someone leading it, it would likely not get any where. But I tend to disagree that it would be a separate goal for the conference. I realize the goal of the summit is to talk about native-code compilation for Python and most would argue that means executing C code, assembly, or at the very least executing code at the speed of "C code". But the reality now is, numerical/scientific programming increasingly needs executing in a clustered environment. So I think we need to be careful to not only solve yesterday's problems but make sure we are covering the current day and future ones.
Today, big data and analytics, which is driving most numerical/scientific programming, is becoming almost exclusively run in a clustered environment, with the Apache Spark ecosystem as the de facto standard. A few years back, Python's ace up its sleeve for the scientific community was the numpy/scipy ecosystem but we have recently lost that edge by falling behind in clustered computing. At this point in time our best move forward on the numerical/scientific fronts is to become best buddies with the Spark ecosystem and make sure we can bring bridge the numpy/scipy ecosystem to it. That is we merge the best of both worlds and suddenly Python becomes to go to language again for numerical/scientific computing. Of course we still need to address what should have been yesterday's problem and deal with the "native-code compilation" issues.
John