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

[Gabriel Scherer <gabriel.scherer@gmail.com>]

> Also the development of OCaml seems a bit opaque, we don't know where
> the discutions of the core team happen. Maybe it is on caml@inria.fr but
> it is not public. I think people are interested (i am) about technical
> discutions on the compiler.

Just a remark on that: I agree that it's frustrating to be kept out
the discussions of the core caml team.
I would be interested in learning more about it as well as you are.

However, I also understand the reason why this choice is made: when
discussion programming language matters, there is usually an
extraordinary amount of bike-shedding. Camlers are quite disciplined
but still the caml-list often come backs on the same topic with few
additional content added, starts endless discussions about thing that
don't move so much in the end (because discussing is fun and
interesting, etc.).
I have heard from people that do take part in internal discussions
that the debates are already long and exhausting. I do understand (yet
does not support) the choice to not open them to public discussion. I
would love, for example, a kind of read-only mode where we hear about
the discussion, without adding noise to it; but could we restrain
ourselves (... and others of the list and on the web) to silence? I
can very well imagine a discussion on the public lists "on some
suggestions about the debate about ...", filled with sneaky remarks
such that "I'm disappointed no core-team member has taken the time to
comment on my proposal".

Just a little story: between the 3.11 and 3.12 transition I followed
the ocaml SVN branches (which are publicly accessible ways of having
information about the current evolution of Caml) and was excited about
the new stuff. When I stumbled about Alain Frisch's work on rigid
names for type variables (
http://caml.inria.fr/pub/docs/manual-ocaml/manual021.html#toc80 ), I
was immediately appalled by the syntax.
I immediately started writing a mail to the list discussing the issue,
making several suggestions, etc. Yet I decided to contact Alain
privately first, as it seemed fitting¹. His immediate answer was
around the lines "please don't; we already had a troll about it, other
options were mentioned, but we really need to settle on a compromise
here, no another, longer troll". I respected his opinion, and in
retrospect I think that was the right choice.

¹: It seemed fitting to contact him privately first, and would also
have been in Benedikt's case by the way, contrarily to what some
people seem to think. Giving people notice does not hurt transparency
or open discussion. If I wrote a scientific paper discussing someone's
work, especially if it's a bit negative about it, I would try to
contact him privately before sending it to the public or reviewers.

On Fri, Dec 9, 2011 at 11:37 AM, Jérémie Dimino <jeremie@dimino.org> wrote:
> Le vendredi 09 décembre 2011 à 11:11 +0900, Jacques Garrigue a écrit :
>> I do agree that the problem with ARM reflect some problem in the current development
>> organization, but I don't think that you need to fork to solve it.
>> *(And note by the way that a real fork could be in contradiction with the QPL.)*
>
> I thought OCaml was a free software...
>
> Seriously, i don't understand why a fork would be a bad thing. There are
> lots of parts for which one don't need to be superman to contribute. And
> right now there are lots of trivial patches on the tracker that remain
> without response after several years, so there is clearly a need for
> improvement.
>
> Also the development of OCaml seems a bit opaque, we don't know where
> the discutions of the core team happen. Maybe it is on caml@inria.fr but
> it is not public. I think people are interested (i am) about technical
> discutions on the compiler.
>
> Cheers,
>
> --
> Jérémie
>
>
>
> --
> 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
>