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

[oliver <oliver@first.in-berlin.de>]

On Fri, Dec 09, 2011 at 12:03:30PM +0100, Gabriel Scherer wrote:
> > 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;
[...]

Yes, a read-only list was, what today came to my mind also.


> but could we restrain
> ourselves (... and others of the list and on the web) to silence?

Instead of commanded silence, the Caml-list could be a place,
where these issues could be discussed.

So, the core-team could sometimes look at the Caml list and get some
ideas from there, without being forced to answer.

[...]
> 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.
[...]

This is what I think: there might be some reasons for certain decisions,
which might not be clear to those who are new in a certain field.

I had experienced simliar things last year on a hardware project,
when a new colleage added some (flyback) diodes to a current source, and
some days later he saw that the backward current brings problems that make
the circuit unusable. :-)  LOL
I had good reasons, NOT to insert those diodes... which the colleague
was not aware of. Later he knew it. ;)

That's very similar to what you say here on the point of the type
annotation syntax. :-)

Regarding the discussions on this list, I think many times
it was similar. First big proposals and announcements,
later stumbling...


But the read-only option on some discussions from the core team
of course would be interesting.

It could gain two points: more openly sharing of the work of the
core team together with the protective barrier that stops
discussions becoming too much bloated by too many posts,
that are not directly accessing the discussion of the core team
(which of course has best insights into OCaml).

It also would be fine, to know if there is something like a
priority list of the Ocaml team.
The points mentioned by the one Debian OCaml maintainer
seem not to be very satisfactory.
Not sure if some parts of the codes were already planned to change...

So, maybe the inner circle / core team has just different priorities?

I think it might also make sense to ask in a different direction:
instead on insisting how the core team has to be(have), to make
the development more open, it maybe could be better to ask,
how the core team could be helped, so that the goals of this
team and the OCaml users can be brought together.

Maybe they already have ideas or wishes on changing the process,
but being confronted just with a bunch of request on how they have to change.

Maybe asking on how to help is better than insisting that they have to be as
peoplefrom the outside  want it.


Ciao,
   Oliver