Re: [Caml-list] OCaml maintenance status / community fork (again)

[Xavier Leroy <Xavier.Leroy@inria.fr>]

On 12/08/2011 10:10 AM, Benedikt Meurer wrote:

> Opening up the development of OCaml is a great suggestion, for
> example. Personally I'd even suggest to disconnect OCaml and INRIA,
> with an independent team of core maintainers (with appropriate spare
> time and knowledge). INRIA would still contribute to OCaml, but no
> longer control OCaml.

Oh, my!  I go underwater for one week, first preparing a two-days training
course then delivering it deep inside an Airbus factory (without Wifi of
course so I had to read all that angst on my iPhone), and voila it's Arab
spring on the caml-list :-)

This discussion started on the wrong foot, and I don't see how I could
seriously consider Benedikt's plans given the amount of flaming and trolling
that surround it.  Benedikt, you should realize that your first message was
aggressive, even taking German style into account, and that your second is
offensive.  You barking louder isn't going to make me listen more.  For
instance, here you're aiming for the jugular (and missing):

> For example, have a look at PR/3746, a great example. It took almost
> 4 years(!) to update the ARM port to softfp (and EABI). At the time
> the issue was finally fixed, most ARM application boards were
> already shipping with VFP, so the port is lacking behind several
> years.

It is a great example indeed, but of my dedication to supporting OCaml in
the long run.  Yes, it took a long time, first because adapting ocamlopt to
a soft-FP model was absolutely not obvious (the code generator really wants
FP regs to hold FP values), second because I had to wait a long time before
an appropriate development and testing environment was available (namely,
Debian ARM EABI running inside QEMU), third because nobody really cared.
Your average maintainer would have given up at that point and canceled the
ARM port of OCaml because ARM's floating-point is a mess.  I didn't and
spent one full week of my summer vacations recoding the ARM port instead.
I'm quite happy with the result, thank you very much, and disagree with your
"lacking behind" claim -- the only way that this ARM port can live in the
long run (and I definitely care, as my CompCert project needs OCaml on ARM)
is to stick with the lowest common denominator, namely soft FP.

> The relevant bug report PR/5404, which includes a backward
> compatible patch, is already waiting for a sign of life for 3 weeks
> now (maybe wait another 4 years to get the port fixed).

More bile.  What's so urgent about it?  The next release of OCaml is 3-6
months in the future; your suggestion will be examined by then.  You know,
some people have busy professional lives. I can only devote 1 to 2 days per
months to OCaml maintenance, and would prefer to spend them on technical
work rather than on massaging egos or putting out the fires that you light
up on this list.

Having missed the jugular, you then aim for the groin:

> While we don't have a Drepper here in OCaml land (yet?) [...]

It's funny you mention Ulrich Drepper: I worked with him in the late 90's
integrating LinuxThreads version 1 into glibc, and he was courteous, to the
point, and frighteningly efficient.  Draw your own conclusions.

Enough of that: my physician is already concerned about my blood pressure,
and this discussion is making me grow a stomach ulcer on top.  So, let me
close with a few general messages to the esteemed Caml community.

1- Count your blessings and don't be ungrateful.  With the exception of the
Caml consortium members, no one is paying for the work of the Caml core
development team, yet several of you have demands that are ridiculous even
if you were paying customers of a commercial product.  (Minutes of the
internal discussions of the development team??  What's next, a live video
feed from my bathroom?)

2- As pointed out already in this discussion, it's not on the Caml compiler
that community efforts are most needed.  For example, the most impactful
action that his community could take, in my opinion, is to adopt and embrace
a common packaging system like Cabal for Haskell.

3- I am not impressed by the ability of the Caml community to do actual
community work.  We have N >= 2 (often N >> 2) independent implementations
of many things but a definite lack of convergence.  For instance, I admire
Gerd Stolpmann's and Sylvain Le Gall's efforts on the packaging front, but
see very few people actually joining these efforts.  For another example,
the core Caml development team sometimes asks for testing and opinions on
new directions (e.g. I on the x86-32bits-SSE2 code generator, or Jacques
Garrigue on GADT prototypes) and response rate is very low.  It feels like
herding cats.

4- Yes, we obviously have problems with PR triaging, in part because Mantis
makes this task more bureaucratic than strictly necessary, but more
importantly because it is often hard to guess who cares about this or that
suggestion, or even what problem it is supposed to address.  Volunteers
could greatly help by simply commenting on the PRs in Mantis, to express
support or disagreement, or to ask for clarifications.

5- Before embarking on patching the core Caml distribution, it wouldn't hurt
to ask (privately) where the priorities are.  For instance, I don't see the
point for a linear-scan allocator (Benedikt Meurer) or more efficient
compilation of value let-rec (Fabrice le Fessant), but anyone who would come
up with a GHC-quality function inliner would be welcome like the Messiah.
Likewise, for many years I've been looking for developers to work on the
Windows port(s) of OCaml and never found any.  Finally, at the latest OCaml
consortium meeting, the idea of splitting Camlp4 off the core distribution
was floated around; volunteers to take over its maintenance would be most
welcome.

All right.  Let me stop here and pray for constructive, non-knee-jerk reactions.

- Xavier Leroy