I agree that package management, a *single* standard library, and a good web presence are the most useful things we can do. We desperately need oasis, oasis-db, and eventually an OCaml Platform to succeed. The standard library contenders are Batteries and Jane St Core. Ideally these could be merged, but that will take a lot of effort from both teams. On the web side, we did start a project to build a new website for OCaml, announced at the last User Meeting. We are continuing to work on it, although admittedly progress has been slow.

Nothing wrong with compiler improvements. We don't have to pick between these options. Let's just work on all of them.  :)


On Tue, Dec 6, 2011 at 11:03 AM, Benedikt Meurer <benedikt.meurer@googlemail.com> wrote:

On Dec 6, 2011, at 16:24 , Jonathan Protzenko wrote:

> [...]
>
> If it's about improving the general situation with OCaml and its community (the title of this thread contains the word "community"), then I believe hacking on the compiler is not the most effective way to achieve that goal. We're hackers. We like to hack on things. And we often fail to ask ourselves: is it really worth implementing? Submitting patches is easy. Submitting quality patches that do solve a real problem is harder. The ARM backend does need a cleanup, and the patch does solve a stringent issue. That may not be the case for all patches.

You may be right, but I think you are also missing my point to some degree here. Improving the OCaml community as a whole is a worthwhile goal and more than welcome, but that is a far away, probably very difficult to achieve goal. What I am talking about and what I am trying to address is a rather practical problem: How to avoid pissing off possible contributors to the OCaml core (these are most likely different people than the ones that would help with web site, spreading the word, community stuff) and how to improve the maintenance status of the OCaml core? Or maybe: How to set OCaml free?

> There is indeed a problem w.r.t external contributions. I agree that the INRIA team could make it clearer what its stance on external contributions is. Maybe one solution would be to have a INRIA-endorsed ocaml-next on github that everyone can fork, where we would merge really outstanding features, before submitting them to INRIA, as you described. I don't think it is such a good idea creating a real fork. Maybe some sort of integration platform on GitHub would be the right solution to the "patch review" problem.

As long as that would be INRIA-controlled, I fear that it would be the same story with different infrastructure (you'll have pull requests that don't get attention rather than bug reports that don't get attention).

> I'm not even sure what kind of patches you wish to see integrated. Can you clarify that?

Mantis is down currently.

> Kind regards,
> jonathan

Benedikt

--
Caml-list mailing list.  Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs