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

[Romain Beauxis <romain.beauxis@gmail.com>]

Hi all,

2011/12/12 Mehdi Dogguy <mehdi@dogguy.org>:
> On 12/12/2011 11:59 AM, Benedikt Meurer wrote:
>>
>> On Dec 12, 2011, at 11:21 , Xavier Leroy wrote:
>>
>>> - It complicates the lives of OCaml users, packagers, and
>>> 3rd-party library developers: what version should they use?  what
>>> will be the basis for the packagers's distribution-specific
>>> patches?  what happens if a library is compatible with one version
>>> but not the other?  what if the community effort runs out of steam
>>> in a few years?
>>
>> If we can adopt the eglibc model, then the community thing will be
>> the version shipped by distributions, i.e. the community thing is the
>> OCaml for distributions/packagers, not an alternative to the official
>> version. That way we do no longer need to maintain specific patches /
>> versions for Debian, Red Hat, MacPorts, etc. This ensures that
>> versions are compatible across different distributions (because they
>> do no longer need to maintain their own set of patches).
>>
>
> No, distributions won't start shipping the community distribution just
> because it exists. I cannot speak for Fedora (and others), but
> Debian/Ubuntu won't switch to the community distribution that easily. In
> fact, it may appear as a seperate source package at some point but won't
> replace INRIA's ocaml in Debian.
>
> If you look at Debian's ocaml package, you'll notice that very few
> custom patches are applied.
>
>        http://patch-tracker.debian.org/package/ocaml/3.12.1-2
>
> Patches from 1 to 6 are just (let's say) build configurations to cope
> with Debian's standards. All the rest has been submitted to upstream,
> except patch 11. Some of the submitted patches were even applied in
> trunk. I guess the rest will be integrated as well… Most of the patches
> (from 7 to 15) are there to avoid build failures on some architectures.
>
> The problem with the community distribution is that:
> 1) it doesn't exist yet. So, we cannot commit on something more than vague.
> 2) we don't even know its release schedule, etc…
> 3) we don't know the kind of changes that will be integrated to the
> community distribution
> 4) as of today, we don't even know if it is a good idea ; if it will be
> a success ; etc…
>
>> I think of the community thing as:
>>
>> (a) A single place for patches, while waiting for the next official
>> OCaml release.
>>
>> (b) A common ground for experimenting with new features. As you
>> already noted, feedback and adoption for experimental stuff hidden
>> within the SVN repository wasn't all that great, so maybe we can
>> change it this way (esp. since it would be coordinated with the
>> distributions/packagers to some degree).
>>
>
> (a) seems very reasonable but (b) is unclear to me. You don't need to
> create a community distribution of ocaml to experiment new features
> sitting in ocaml's svn. Just checkout the relevant branch, and start
> playing. The idea of the community distribution is to have an ocaml with
> some patches on top of it (patches for bugs those sitting in mantis for
> long time, a few features/experiments that are not present in ocaml's
> svn). The idea is also to not diverge too much to keep things compatible.
>
> my 2cents,

I have been busy with several fires and only came back to list
recently. I might be late for the party but I would like to voice my
opinion as this idea of "forking" OCaml is a pretty sensitive one.

I, for one, am convinced that "forking" OCaml's core would be a
terrible idea. As mentioned above by Mehdi as well as others, a
"community" driven development process would not address the
fundamental issue of taking core decisions. Those familiar with the
Debian project surely know how these processes can be time-consuming
and bring another form of frustration anyway.

I would also like to mention that OCaml core developers probably do
not get the proper recognition they deserve for the work they've put
in the past years. Surely, some aspects could be criticized, but
overall I have seen many changes which also preserved backward
compatibility and minimized the amount of bugs introduced. I think
this is overall a great job.

OCaml's core is a sensitive part of the language and I can see how it
can get frustrating to get one's work included into it. But,
considering the importance of this part of the language, frustration
is probably somehow a good thing. At least, it does not seem to me to
justify any kind of forking.

My real concern for the future of OCaml's development is more about
side tasks that could very well be addressed by the community without
completely breaking down the stability of its core. For instance, I
have been maintaining for some time a version of Richard's
cross-compiler in Debian. Most of those changes concern OCaml's build
system which, admittedly, could be very well improved.

On this point, I believe that it would be very nice to have, indeed, a
clearer integration process and more communication from the core
development team. For instance, if I would be to propose a complete
rewrite of OCaml's build system, I'd like to know beforehand if my
changes have any chance to be integrated and, if so, how should I
tackle the issue in order to facilitates this integration (split up
the changes in several patches, post them for review somewhere etc..).

This also stand for the patches required to build the cross-compiler,
which I think would be a great thing to have out of the box and would
not require much changes in the core.

On another topic, I also agree that there should be a real effort put
into the visibility of the language and, more importantly, available
libraries. Contrary to what others have mentioned, functional
programming is not, I believe, a paradigm that would be so difficult
to take on. Things like coffeescript [1], a "syntactic sugar" for
javascript, becoming more and more used by JS programmers shows that
the basics of functional programming syntactic have a great potential
for adoption by a wider basis of developers.

As it has been mentioned earlier, I, too, think that having more
visibility on places where other languages and projects are also
available is a key here. Github, indeed, seems like unavoidable at
this point and, on the contrary, hosting our own gitorious would be
yet another failure as it would set up an isolated platform for the
language.

Ultimately, I do not believe that academics should be taken
responsible for the adoption of OCaml by young programmers. If one
looks at ruby/rails or nodejs or, until recently, python, the success
of those languages have little to do with academic programs but more
with the dynamic, visibility and communication of their early
adopters.

Romain


[1]: http://jashkenas.github.com/coffee-script/