[Caml-list] OCaml maintenance status / community fork

[Caml-list] OCaml maintenance status / community fork

[Benedikt Meurer]

Dear caml-list,

During the last year or two it seems that time and interest in OCaml maintenance from the official OCaml development team is diminishing. It takes several months to get a patch reviewed (if at all), which is quite frustrating for OCaml contributors and even worse for OCaml users. I suspect that this is one of the top reasons why there are only a few active contributors to OCaml (and the number of active users, at least on the mailing list, is declining).

I understand that INRIA does not necessarily pay people for full time maintenance jobs on OCaml (and Coq), and the official dev team is probably already doing as much as possible to maintain OCaml. Given that OCaml is such a nice language with a lot of useful frameworks available, it is too sad to see it loosing ground just because of it's closed development process and lack of time of the official team.

I'd therefore propose to open up OCaml development to a wider range of developers / contributors, to ensure that OCaml will be ready for the (functional programming) future. There are already various "OCaml forks" in the wild, with different goals and patch sets, so simply starting another fork would be rather useless. Instead I'd suggest to bundle efforts in a new "OCaml community fork", which is always based on the most recent upstream OCaml release (starting point would be 3.12.1 for now), and takes care to review and integrate pending patches as well as developing and testing new features. Let's say we'd name the fork "OCaml-ng", then we'd try to release a new patch set every month or two, based on the official OCaml release, i.e. "ocaml-3.12.1+ng201112" and so on, to get early testing and feedback (should work together closely with the Debian/Ubuntu/etc. OCaml maintainers).

With this process, OCaml upstream could merge (tested) patches from OCaml-ng once they proved working in the wild, and thereby

1. maintenance overhead for INRIA people is reduced,
2. maintenance status of OCaml would be way better,
3. there would be a lot less frustration for possible contributors, and
4. users benefit from a better and more up to date OCaml.

Now that does of course raise a few questions:

1. What is the opinion of the official development team / INRIA on this?
2. Who would help with the community fork?
3. What about infrastructure?

Feedback and suggestions are welcome.

Benedikt

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

[Goswin von Brederlow]

Benedikt Meurer <benedikt.meurer@googlemail.com> writes:

> Dear caml-list,
>
> During the last year or two it seems that time and interest in OCaml maintenance from the official OCaml development team is diminishing. It takes several months to get a patch reviewed (if at all), which is quite frustrating for OCaml contributors and even worse for OCaml users. I suspect that this is one of the top reasons why there are only a few active contributors to OCaml (and the number of active users, at least on the mailing list, is declining).
>
> I understand that INRIA does not necessarily pay people for full time maintenance jobs on OCaml (and Coq), and the official dev team is probably already doing as much as possible to maintain OCaml. Given that OCaml is such a nice language with a lot of useful frameworks available, it is too sad to see it loosing ground just because of it's closed development process and lack of time of the official team.
>
> I'd therefore propose to open up OCaml development to a wider range of developers / contributors, to ensure that OCaml will be ready for the (functional programming) future. There are already various "OCaml forks" in the wild, with different goals and patch sets, so simply starting another fork would be rather useless. Instead I'd suggest to bundle efforts in a new "OCaml community fork", which is always based on the most recent upstream OCaml release (starting point would be 3.12.1 for now), and takes care to review and integrate pending patches as well as developing and testing new features. Let's say we'd name the fork "OCaml-ng", then we'd try to release a new patch set every month or two, based on the official OCaml release, i.e. "ocaml-3.12.1+ng201112" and so on, to get early testing and feedback (should work together closely with the Debian/Ubuntu/etc. OCaml maintainers).
>
> With this process, OCaml upstream could merge (tested) patches from OCaml-ng once they proved working in the wild, and thereby
>
> 1. maintenance overhead for INRIA people is reduced,
> 2. maintenance status of OCaml would be way better,
> 3. there would be a lot less frustration for possible contributors, and
> 4. users benefit from a better and more up to date OCaml.
>
> Now that does of course raise a few questions:
>
> 1. What is the opinion of the official development team / INRIA on this?
> 2. Who would help with the community fork?
> 3. What about infrastructure?
>
> Feedback and suggestions are welcome.
>
> Benedikt

+1 for getting patches better/faster reviewd and included.

I'm still waiting to hear back for my Bigarray patch to support 31bit
integers.

MfG
        Goswin

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

[rixed]

So what your proposition adds to the existing ocaml forks out there
is that there should be people reviewing and merging incoming patches
and releasing a semi-official community version for each official
release.

The problem with this proposition as stated, in my opinion, is that
the original fork is very easy to do but the following review/release
processes asks for more volunteers time.

Why not concentrate on a fork that's already there with plenty of
patches, for instance this one :

https://github.com/thelema/ocaml-community

and roll a first release out of it ?

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

[Kakadu]

[-- Attachment #1: Type: text/plain, Size: 2912 bytes --]

Does anybody has news about OCamlPro?



-----------------------------------------------------------
Kakadu

On Tue, Dec 6, 2011 at 12:25 PM, Benedikt Meurer <
benedikt.meurer@googlemail.com> wrote:

> Dear caml-list,
>
> During the last year or two it seems that time and interest in OCaml
> maintenance from the official OCaml development team is diminishing. It
> takes several months to get a patch reviewed (if at all), which is quite
> frustrating for OCaml contributors and even worse for OCaml users. I
> suspect that this is one of the top reasons why there are only a few active
> contributors to OCaml (and the number of active users, at least on the
> mailing list, is declining).
>
> I understand that INRIA does not necessarily pay people for full time
> maintenance jobs on OCaml (and Coq), and the official dev team is probably
> already doing as much as possible to maintain OCaml. Given that OCaml is
> such a nice language with a lot of useful frameworks available, it is too
> sad to see it loosing ground just because of it's closed development
> process and lack of time of the official team.
>
> I'd therefore propose to open up OCaml development to a wider range of
> developers / contributors, to ensure that OCaml will be ready for the
> (functional programming) future. There are already various "OCaml forks" in
> the wild, with different goals and patch sets, so simply starting another
> fork would be rather useless. Instead I'd suggest to bundle efforts in a
> new "OCaml community fork", which is always based on the most recent
> upstream OCaml release (starting point would be 3.12.1 for now), and takes
> care to review and integrate pending patches as well as developing and
> testing new features. Let's say we'd name the fork "OCaml-ng", then we'd
> try to release a new patch set every month or two, based on the official
> OCaml release, i.e. "ocaml-3.12.1+ng201112" and so on, to get early testing
> and feedback (should work together closely with the Debian/Ubuntu/etc.
> OCaml maintainers).
>
> With this process, OCaml upstream could merge (tested) patches from
> OCaml-ng once they proved working in the wild, and thereby
>
> 1. maintenance overhead for INRIA people is reduced,
> 2. maintenance status of OCaml would be way better,
> 3. there would be a lot less frustration for possible contributors, and
> 4. users benefit from a better and more up to date OCaml.
>
> Now that does of course raise a few questions:
>
> 1. What is the opinion of the official development team / INRIA on this?
> 2. Who would help with the community fork?
> 3. What about infrastructure?
>
> Feedback and suggestions are welcome.
>
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3544 bytes --]

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

[Joel Reymont]

Erlang/OTP used to be a lot like OCaml. 

Development was done internally at Ericsson and official releases were done from time to time.

This year the OTP team uploaded the code to Github and started syncing their internal code frequently. 

Reviewing and discussing patches become much quicker and many more contributions are making it into official releases. 

Now, I don't know if this is a result of the Github making collaboration easier or a more open attitude on the part of the Ericsson team. 

I do know that it works, though.

--------------------------------------------------------------------------
- for hire: mac osx device driver ninja, kernel extensions and usb drivers
---------------------+------------+---------------------------------------
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
---------------------+------------+---------------------------------------

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

[Gerd Stolpmann]

I'd say it depends very much for which kind of work the community fork is
used. If it is just for enhancing the standard library, please don't do it
- there are as many opinions as contributors. If it is for fixing bugs I'm
for it - provided there is a process to get the fixes back to the original
Ocaml version.

Regarding your work, Benedikt, I'm not sure what would be the best. It's
highly interesting work, but it's deeply changing the compiler, so
probably not something a community of volunteers could review (although
they could test it at least).

I'd see this more as an effort to organize help for the core team, and it
would be essential that the "fork" is working in both directions.

Gerd


> Dear caml-list,
>
> During the last year or two it seems that time and interest in OCaml
> maintenance from the official OCaml development team is diminishing. It
> takes several months to get a patch reviewed (if at all), which is quite
> frustrating for OCaml contributors and even worse for OCaml users. I
> suspect that this is one of the top reasons why there are only a few
> active contributors to OCaml (and the number of active users, at least on
> the mailing list, is declining).
>
> I understand that INRIA does not necessarily pay people for full time
> maintenance jobs on OCaml (and Coq), and the official dev team is probably
> already doing as much as possible to maintain OCaml. Given that OCaml is
> such a nice language with a lot of useful frameworks available, it is too
> sad to see it loosing ground just because of it's closed development
> process and lack of time of the official team.
>
> I'd therefore propose to open up OCaml development to a wider range of
> developers / contributors, to ensure that OCaml will be ready for the
> (functional programming) future. There are already various "OCaml forks"
> in the wild, with different goals and patch sets, so simply starting
> another fork would be rather useless. Instead I'd suggest to bundle
> efforts in a new "OCaml community fork", which is always based on the most
> recent upstream OCaml release (starting point would be 3.12.1 for now),
> and takes care to review and integrate pending patches as well as
> developing and testing new features. Let's say we'd name the fork
> "OCaml-ng", then we'd try to release a new patch set every month or two,
> based on the official OCaml release, i.e. "ocaml-3.12.1+ng201112" and so
> on, to get early testing and feedback (should work together closely with
> the Debian/Ubuntu/etc. OCaml maintainers).
>
> With this process, OCaml upstream could merge (tested) patches from
> OCaml-ng once they proved working in the wild, and thereby
>
> 1. maintenance overhead for INRIA people is reduced,
> 2. maintenance status of OCaml would be way better,
> 3. there would be a lot less frustration for possible contributors, and
> 4. users benefit from a better and more up to date OCaml.
>
> Now that does of course raise a few questions:
>
> 1. What is the opinion of the official development team / INRIA on this?
> 2. Who would help with the community fork?
> 3. What about infrastructure?
>
> Feedback and suggestions are welcome.
>
> 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
>
>
>


-- 
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.

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

[Gaius Hammond]

I for one would love to see OCaml up on GitHub. 



G



------------------

-----Original Message-----
From: Goswin von Brederlow <goswin-v-b@web.de>
Date: Tue, 06 Dec 2011 10:17:46 
To: Benedikt Meurer<benedikt.meurer@googlemail.com>
Cc: <caml-list@inria.fr>
Subject: Re: [Caml-list] OCaml maintenance status / community fork

Benedikt Meurer <benedikt.meurer@googlemail.com> writes:

> Dear caml-list,
>
> During the last year or two it seems that time and interest in OCaml maintenance from the official OCaml development team is diminishing. It takes several months to get a patch reviewed (if at all), which is quite frustrating for OCaml contributors and even worse for OCaml users. I suspect that this is one of the top reasons why there are only a few active contributors to OCaml (and the number of active users, at least on the mailing list, is declining).
>
> I understand that INRIA does not necessarily pay people for full time maintenance jobs on OCaml (and Coq), and the official dev team is probably already doing as much as possible to maintain OCaml. Given that OCaml is such a nice language with a lot of useful frameworks available, it is too sad to see it loosing ground just because of it's closed development process and lack of time of the official team.
>
> I'd therefore propose to open up OCaml development to a wider range of developers / contributors, to ensure that OCaml will be ready for the (functional programming) future. There are already various "OCaml forks" in the wild, with different goals and patch sets, so simply starting another fork would be rather useless. Instead I'd suggest to bundle efforts in a new "OCaml community fork", which is always based on the most recent upstream OCaml release (starting point would be 3.12.1 for now), and takes care to review and integrate pending patches as well as developing and testing new features. Let's say we'd name the fork "OCaml-ng", then we'd try to release a new patch set every month or two, based on the official OCaml release, i.e. "ocaml-3.12.1+ng201112" and so on, to get early testing and feedback (should work together closely with the Debian/Ubuntu/etc. OCaml maintainers).
>
> With this process, OCaml upstream could merge (tested) patches from OCaml-ng once they proved working in the wild, and thereby
>
> 1. maintenance overhead for INRIA people is reduced,
> 2. maintenance status of OCaml would be way better,
> 3. there would be a lot less frustration for possible contributors, and
> 4. users benefit from a better and more up to date OCaml.
>
> Now that does of course raise a few questions:
>
> 1. What is the opinion of the official development team / INRIA on this?
> 2. Who would help with the community fork?
> 3. What about infrastructure?
>
> Feedback and suggestions are welcome.
>
> Benedikt

+1 for getting patches better/faster reviewd and included.

I'm still waiting to hear back for my Bigarray patch to support 31bit
integers.

MfG
        Goswin

-- 
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

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

[Gabriel Scherer]

I would like to comment on a tangential aspect of the rationale you gave:

> Given that OCaml is such a nice language with a lot of useful frameworks available,
> it is too sad to see it loosing ground just because of it's closed development process
> and lack of time of the official team.

I don't think OCaml "losing ground" can be just-because-explained by a
closed development process. It's a fact that the OCaml community is
generally less active than other communities of comparable programming
languages, the first example coming to mind being Haskell. It is
interesting to discuss what we could/should do to get a comparably
healthy community.

I agree with the analysis that the OCaml language implementation is
not as open as it could be, and I understand the idea that this
probably had a detrimental effect on the "OCaml community" as a whole.
But this is by no mean obvious (and difficult to objectively verify),
and it is certainly not the only factor -- or even, I claim, the main
factor -- to explain OCaml feeble community growth.

There have been numerous "OCaml community meeting" discussing
precisely these issues. I attended the 2008 meeting, and several
aspects were discussed, including among others
(1) the lack of openness of the compiler development (what you discuss here)
(2) the apparent stagnation of the OCaml language itself
(3) the lack of a comprehensive general-purpose set of software
libraries that newcomers could just use as a standard starting point
(4) the lack of visibility of user-contributed OCaml code, tools and
libraries, or perceived difficulties to install and deploy such code
(5) (related) the lack of communication of OCaml users about what they do

You are singling out problem (1) as *the* problem with OCaml. I think
this is more a reflect of your personal preferences (indeed, you are
now a distinguished OCaml backend hacker) than a global analysis of
the needs of the "OCaml community". I agree that (1) hasn't changed
much since 2008; as you noted (at least from an external point of
view), there are important human factors that make the situation
difficult : not everyone can contribute to the compiler as there are
both technical and social barriers to contribution.

(2) has clearly turned to be wrong. I distinctly remember being
surprised at that time by the announcement of 3.12's first-class
module, and thinking when Xavier Leroy mentioned GADTs -- at the 2008
meeting -- that it would just never happen.

(3) is currently being worked on by different people. The OCaml
Batteries Included project as an ambitious goal to provide a
community-built "distribution" of OCaml software in a coherent whole
(the idea was later taken, and impressively performed, by the "Haskell
Platform" effort). It has since restrained it ambitions to providing a
superset of the libraries distributed with the compiler, as a wider
"standard library". Jane Street Core's library similarly aims to
provide a "bigger standard library", with in particular an impressive
offering regarding the pervasive cross-module aspects such as
marshalling / unmarshalling data and similar datatype-generic
concerns.
  http://batteries.forge.ocamlcore.org/
  http://ocaml.janestreet.com/?q=node/13

Using, contributing to or talking about those projects would also help
OCaml not to "loose ground". I won't make any judgement on whether a
more complete library is more or less useful that a change to the
compiler toolchain, and it certainly is a different kind of work prone
to interest different peoples. But it is also an important aspect of
the OCaml ecosystem.
I have irregularly contributed to the Batteries project, and I know
for sure that the project is willing to accept any help on things to
improve (in particular unit testing and documentation). Even, or
especially, small one-shot contributions can help : three unit tests
for a given function, a new tiny auxiliary function in such module, a
bunch of typo fixes for the documentation...

The problem (4), which is really a multi-faceted set of related
problem, has also been tackled by different people with different
projects. In particular, GODI and Oasis are both impressive efforts in the right
direction, and I suspect both projects would benefit from
contributions, eg. packaging existing libraries, reporting issues with
either tool, communicating about them and disseminating exemple
packages that other can look upon to reproduce for their own software.

If think specific progress on (5) resulted from those meeting. There
is now an OCaml Planet, which has interesting posts about OCaml from,
for example, Matías Giovannini (
http://alaska-kamtchatka.blogspot.com/ ). Activity on the planet come
and goes, but everyone can help by posting interesting stories that
would be of interest to an OCaml audience, or targeted at non-ocaml
people that may be interested in the language. As a starter, you could
just suscribe to the planet, read the posts, and submit stimulating
feedback to the writers.
  http://planet.ocamlcore.org/

Having a personal blog is not the only way to help disseminate
information about OCaml. If you participate to news-aggregation sites
such as Slashdot, Reddit or whatever, you should consider submitting
OCaml-related content that could be of interest to the target
audience, or participating in relevant discussions when appropriate.
"Appropriate" is the key word here : quality should be favored over
quantity, and I personally try not to get involved in negative
discussions (in particular language flamewars: informed users of other
programming languages are not enemies, even if they are frustratingly
better at propaganda, have a nicer surface syntax, and indulge
themselves into letting people think that "pure" necessarily means
"better", hint hint :-). The OCaml community should have a public face
to be proud of; it is currently gradually moving out of total silence.


I'm not trying to say that your fork is a bad idea, not useful or
anything. I have really no opinion; we'll see how things turn out. But
I wouldn't want people to start thinking that "indeed, compiler
development is the biggest problem with OCaml today, we need the great
Xavier, Benedikt, Jun, Jacques, Alain, Fabrice... to sort things out",
hiding or neglecting other issues that are not so delicate (on the
human side) to handle, could easily benefit from efforts from
everyone, and may have an equal or higher impact in the long term.

Dear reader, if you wish to help OCaml strive as a language, there are
a lot of different ways you can help. Improving the compiler toolchain
may be one of them, but there are others that are also useful,
important, lack manpower and have a lower barrier to entry. Consider
how you could be involved according to your interests; I'm not talking
about a huge, demanding personal investment from some key people, but
lots of small contributions by anyone interested. A community is a
collective effort.

On Tue, Dec 6, 2011 at 9:25 AM, Benedikt Meurer
<benedikt.meurer@googlemail.com> wrote:
> Dear caml-list,
>
> During the last year or two it seems that time and interest in OCaml maintenance from the official OCaml development team is diminishing. It takes several months to get a patch reviewed (if at all), which is quite frustrating for OCaml contributors and even worse for OCaml users. I suspect that this is one of the top reasons why there are only a few active contributors to OCaml (and the number of active users, at least on the mailing list, is declining).
>
> I understand that INRIA does not necessarily pay people for full time maintenance jobs on OCaml (and Coq), and the official dev team is probably already doing as much as possible to maintain OCaml. Given that OCaml is such a nice language with a lot of useful frameworks available, it is too sad to see it loosing ground just because of it's closed development process and lack of time of the official team.
>
> I'd therefore propose to open up OCaml development to a wider range of developers / contributors, to ensure that OCaml will be ready for the (functional programming) future. There are already various "OCaml forks" in the wild, with different goals and patch sets, so simply starting another fork would be rather useless. Instead I'd suggest to bundle efforts in a new "OCaml community fork", which is always based on the most recent upstream OCaml release (starting point would be 3.12.1 for now), and takes care to review and integrate pending patches as well as developing and testing new features. Let's say we'd name the fork "OCaml-ng", then we'd try to release a new patch set every month or two, based on the official OCaml release, i.e. "ocaml-3.12.1+ng201112" and so on, to get early testing and feedback (should work together closely with the Debian/Ubuntu/etc. OCaml maintainers).
>
> With this process, OCaml upstream could merge (tested) patches from OCaml-ng once they proved working in the wild, and thereby
>
> 1. maintenance overhead for INRIA people is reduced,
> 2. maintenance status of OCaml would be way better,
> 3. there would be a lot less frustration for possible contributors, and
> 4. users benefit from a better and more up to date OCaml.
>
> Now that does of course raise a few questions:
>
> 1. What is the opinion of the official development team / INRIA on this?
> 2. Who would help with the community fork?
> 3. What about infrastructure?
>
> Feedback and suggestions are welcome.
>
> 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
>

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

[Fabrice Le Fessant]

[-- Attachment #1: Type: text/plain, Size: 3859 bytes --]

On 12/06/2011 10:42 AM, Kakadu wrote:
> Does anybody have news about OCamlPro?

Yes, OCamlPro is working on different projects to improve OCaml
(namespaces, better inlining, debugging, multicore gc, etc.), but the
main focus is currently on improving development tools (edition,
refactoring, navigation, documentation, etc.), while minimizing the
modifications on the compiler itself. The plan is to release a first
version by the beginning of 2012, but it will be complementary to OCaml,
not a replacement.

For the OCaml distribution itself, OCamlPro will have a different
release cycle for its own version, targetting industrial users, but the
high quality testing process required to do that is still under
construction.

Fabrice

> -----------------------------------------------------------
> Kakadu
> 
> On Tue, Dec 6, 2011 at 12:25 PM, Benedikt Meurer
> <benedikt.meurer@googlemail.com <mailto:benedikt.meurer@googlemail.com>>
> wrote:
> 
>     Dear caml-list,
> 
>     During the last year or two it seems that time and interest in OCaml
>     maintenance from the official OCaml development team is diminishing.
>     It takes several months to get a patch reviewed (if at all), which
>     is quite frustrating for OCaml contributors and even worse for OCaml
>     users. I suspect that this is one of the top reasons why there are
>     only a few active contributors to OCaml (and the number of active
>     users, at least on the mailing list, is declining).
> 
>     I understand that INRIA does not necessarily pay people for full
>     time maintenance jobs on OCaml (and Coq), and the official dev team
>     is probably already doing as much as possible to maintain OCaml.
>     Given that OCaml is such a nice language with a lot of useful
>     frameworks available, it is too sad to see it loosing ground just
>     because of it's closed development process and lack of time of the
>     official team.
> 
>     I'd therefore propose to open up OCaml development to a wider range
>     of developers / contributors, to ensure that OCaml will be ready for
>     the (functional programming) future. There are already various
>     "OCaml forks" in the wild, with different goals and patch sets, so
>     simply starting another fork would be rather useless. Instead I'd
>     suggest to bundle efforts in a new "OCaml community fork", which is
>     always based on the most recent upstream OCaml release (starting
>     point would be 3.12.1 for now), and takes care to review and
>     integrate pending patches as well as developing and testing new
>     features. Let's say we'd name the fork "OCaml-ng", then we'd try to
>     release a new patch set every month or two, based on the official
>     OCaml release, i.e. "ocaml-3.12.1+ng201112" and so on, to get early
>     testing and feedback (should work together closely with the
>     Debian/Ubuntu/etc. OCaml maintainers).
> 
>     With this process, OCaml upstream could merge (tested) patches from
>     OCaml-ng once they proved working in the wild, and thereby
> 
>     1. maintenance overhead for INRIA people is reduced,
>     2. maintenance status of OCaml would be way better,
>     3. there would be a lot less frustration for possible contributors, and
>     4. users benefit from a better and more up to date OCaml.
> 
>     Now that does of course raise a few questions:
> 
>     1. What is the opinion of the official development team / INRIA on this?
>     2. Who would help with the community fork?
>     3. What about infrastructure?
> 
>     Feedback and suggestions are welcome.
> 
>     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
> 
> 

[-- Attachment #2: fabrice_le_fessant.vcf --]
[-- Type: text/x-vcard, Size: 380 bytes --]

begin:vcard
fn:Fabrice LE FESSANT
n:LE FESSANT;Fabrice
org:INRIA Saclay -- Ile-de-France;P2P & OCaml
adr;quoted-printable:;;Parc Orsay Universit=C3=A9 ;Orsay CEDEX;;91893;France
email;internet:fabrice.le_fessant@inria.fr
title;quoted-printable:Charg=C3=A9 de Recherche
tel;work:+33 1 74 85 42 14
tel;fax:+33 1 74 85 42 49 
url:http://fabrice.lefessant.net/
version:2.1
end:vcard

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

[Stefano Zacchiroli]

On Tue, Dec 06, 2011 at 11:51:00AM +0100, Fabrice Le Fessant wrote:
> For the OCaml distribution itself, OCamlPro will have a different
> release cycle for its own version, targetting industrial users, but the
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Meaning that the code will not be freely (as in Free Software)
available?  (in case you have already decided that)

All the best to OCamlPro!
-- 
Stefano Zacchiroli     zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ......   http://upsilon.cc/zack   ......   . . o
Debian Project Leader    .......   @zack on identi.ca   .......    o o o
« the first rule of tautology club is the first rule of tautology club »

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

[Gerd Stolpmann]

> I would like to comment on a tangential aspect of the rationale you gave:
>
>> Given that OCaml is such a nice language with a lot of useful frameworks
>> available,
>> it is too sad to see it loosing ground just because of it's closed
>> development process
>> and lack of time of the official team.

I'm quite reluctant to discuss topics about the said decline of something.
However, there is certainly a point here. I have my own theory - basically
the users with FP knowledge have now more options (e.g. F# or the
JVM-based FP languages like Scala), and so the "share" for Ocaml is
decreasing. This has nothing to do with the language.

However, the question is whether we can do more to attract programmers
with FP knowledge (or even better educate programmers without). Ocaml is
not doing enough here - there is no (really good) beginner's site, and
there are not enough "success stories", i.e. users reporting that they
solved something with Ocaml, and why it was a good choice.

Gerd

> I don't think OCaml "losing ground" can be just-because-explained by a
> closed development process. It's a fact that the OCaml community is
> generally less active than other communities of comparable programming
> languages, the first example coming to mind being Haskell. It is
> interesting to discuss what we could/should do to get a comparably
> healthy community.
>
> I agree with the analysis that the OCaml language implementation is
> not as open as it could be, and I understand the idea that this
> probably had a detrimental effect on the "OCaml community" as a whole.
> But this is by no mean obvious (and difficult to objectively verify),
> and it is certainly not the only factor -- or even, I claim, the main
> factor -- to explain OCaml feeble community growth.
>
> There have been numerous "OCaml community meeting" discussing
> precisely these issues. I attended the 2008 meeting, and several
> aspects were discussed, including among others
> (1) the lack of openness of the compiler development (what you discuss
> here)
> (2) the apparent stagnation of the OCaml language itself
> (3) the lack of a comprehensive general-purpose set of software
> libraries that newcomers could just use as a standard starting point
> (4) the lack of visibility of user-contributed OCaml code, tools and
> libraries, or perceived difficulties to install and deploy such code
> (5) (related) the lack of communication of OCaml users about what they do
>
> You are singling out problem (1) as *the* problem with OCaml. I think
> this is more a reflect of your personal preferences (indeed, you are
> now a distinguished OCaml backend hacker) than a global analysis of
> the needs of the "OCaml community". I agree that (1) hasn't changed
> much since 2008; as you noted (at least from an external point of
> view), there are important human factors that make the situation
> difficult : not everyone can contribute to the compiler as there are
> both technical and social barriers to contribution.
>
> (2) has clearly turned to be wrong. I distinctly remember being
> surprised at that time by the announcement of 3.12's first-class
> module, and thinking when Xavier Leroy mentioned GADTs -- at the 2008
> meeting -- that it would just never happen.
>
> (3) is currently being worked on by different people. The OCaml
> Batteries Included project as an ambitious goal to provide a
> community-built "distribution" of OCaml software in a coherent whole
> (the idea was later taken, and impressively performed, by the "Haskell
> Platform" effort). It has since restrained it ambitions to providing a
> superset of the libraries distributed with the compiler, as a wider
> "standard library". Jane Street Core's library similarly aims to
> provide a "bigger standard library", with in particular an impressive
> offering regarding the pervasive cross-module aspects such as
> marshalling / unmarshalling data and similar datatype-generic
> concerns.
>   http://batteries.forge.ocamlcore.org/
>   http://ocaml.janestreet.com/?q=node/13
>
> Using, contributing to or talking about those projects would also help
> OCaml not to "loose ground". I won't make any judgement on whether a
> more complete library is more or less useful that a change to the
> compiler toolchain, and it certainly is a different kind of work prone
> to interest different peoples. But it is also an important aspect of
> the OCaml ecosystem.
> I have irregularly contributed to the Batteries project, and I know
> for sure that the project is willing to accept any help on things to
> improve (in particular unit testing and documentation). Even, or
> especially, small one-shot contributions can help : three unit tests
> for a given function, a new tiny auxiliary function in such module, a
> bunch of typo fixes for the documentation...
>
> The problem (4), which is really a multi-faceted set of related
> problem, has also been tackled by different people with different
> projects. In particular, GODI and Oasis are both impressive efforts in the
> right
> direction, and I suspect both projects would benefit from
> contributions, eg. packaging existing libraries, reporting issues with
> either tool, communicating about them and disseminating exemple
> packages that other can look upon to reproduce for their own software.
>
> If think specific progress on (5) resulted from those meeting. There
> is now an OCaml Planet, which has interesting posts about OCaml from,
> for example, Matías Giovannini (
> http://alaska-kamtchatka.blogspot.com/ ). Activity on the planet come
> and goes, but everyone can help by posting interesting stories that
> would be of interest to an OCaml audience, or targeted at non-ocaml
> people that may be interested in the language. As a starter, you could
> just suscribe to the planet, read the posts, and submit stimulating
> feedback to the writers.
>   http://planet.ocamlcore.org/
>
> Having a personal blog is not the only way to help disseminate
> information about OCaml. If you participate to news-aggregation sites
> such as Slashdot, Reddit or whatever, you should consider submitting
> OCaml-related content that could be of interest to the target
> audience, or participating in relevant discussions when appropriate.
> "Appropriate" is the key word here : quality should be favored over
> quantity, and I personally try not to get involved in negative
> discussions (in particular language flamewars: informed users of other
> programming languages are not enemies, even if they are frustratingly
> better at propaganda, have a nicer surface syntax, and indulge
> themselves into letting people think that "pure" necessarily means
> "better", hint hint :-). The OCaml community should have a public face
> to be proud of; it is currently gradually moving out of total silence.
>
>
> I'm not trying to say that your fork is a bad idea, not useful or
> anything. I have really no opinion; we'll see how things turn out. But
> I wouldn't want people to start thinking that "indeed, compiler
> development is the biggest problem with OCaml today, we need the great
> Xavier, Benedikt, Jun, Jacques, Alain, Fabrice... to sort things out",
> hiding or neglecting other issues that are not so delicate (on the
> human side) to handle, could easily benefit from efforts from
> everyone, and may have an equal or higher impact in the long term.
>
> Dear reader, if you wish to help OCaml strive as a language, there are
> a lot of different ways you can help. Improving the compiler toolchain
> may be one of them, but there are others that are also useful,
> important, lack manpower and have a lower barrier to entry. Consider
> how you could be involved according to your interests; I'm not talking
> about a huge, demanding personal investment from some key people, but
> lots of small contributions by anyone interested. A community is a
> collective effort.
>
> On Tue, Dec 6, 2011 at 9:25 AM, Benedikt Meurer
> <benedikt.meurer@googlemail.com> wrote:
>> Dear caml-list,
>>
>> During the last year or two it seems that time and interest in OCaml
>> maintenance from the official OCaml development team is diminishing. It
>> takes several months to get a patch reviewed (if at all), which is quite
>> frustrating for OCaml contributors and even worse for OCaml users. I
>> suspect that this is one of the top reasons why there are only a few
>> active contributors to OCaml (and the number of active users, at least
>> on the mailing list, is declining).
>>
>> I understand that INRIA does not necessarily pay people for full time
>> maintenance jobs on OCaml (and Coq), and the official dev team is
>> probably already doing as much as possible to maintain OCaml. Given that
>> OCaml is such a nice language with a lot of useful frameworks available,
>> it is too sad to see it loosing ground just because of it's closed
>> development process and lack of time of the official team.
>>
>> I'd therefore propose to open up OCaml development to a wider range of
>> developers / contributors, to ensure that OCaml will be ready for the
>> (functional programming) future. There are already various "OCaml forks"
>> in the wild, with different goals and patch sets, so simply starting
>> another fork would be rather useless. Instead I'd suggest to bundle
>> efforts in a new "OCaml community fork", which is always based on the
>> most recent upstream OCaml release (starting point would be 3.12.1 for
>> now), and takes care to review and integrate pending patches as well as
>> developing and testing new features. Let's say we'd name the fork
>> "OCaml-ng", then we'd try to release a new patch set every month or two,
>> based on the official OCaml release, i.e. "ocaml-3.12.1+ng201112" and so
>> on, to get early testing and feedback (should work together closely with
>> the Debian/Ubuntu/etc. OCaml maintainers).
>>
>> With this process, OCaml upstream could merge (tested) patches from
>> OCaml-ng once they proved working in the wild, and thereby
>>
>> 1. maintenance overhead for INRIA people is reduced,
>> 2. maintenance status of OCaml would be way better,
>> 3. there would be a lot less frustration for possible contributors, and
>> 4. users benefit from a better and more up to date OCaml.
>>
>> Now that does of course raise a few questions:
>>
>> 1. What is the opinion of the official development team / INRIA on this?
>> 2. Who would help with the community fork?
>> 3. What about infrastructure?
>>
>> Feedback and suggestions are welcome.
>>
>> 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
>>
>
>
> --
> 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
>
>
>


-- 
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.

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

[Gabriel Scherer]

[-- Attachment #1: Type: text/plain, Size: 4968 bytes --]

>
> 3. What about infrastructure?
>

Short answer: Ocamlforge ( http://forge.ocamlcore.org/ ) for mailing list,
bug tracking and homepage, and Gitorious ( https://gitorious.org/ ) for
code repository hosting.

Long answer:

In my experience, the most important things for a relatively-small-scale
free software project are, in decreasing order of importance:
1. a place where to drop code that people can look at (and follow
development, etc.)
2. a mailing-list
3. a bug tracker (mailing-list can do that but you risk forgetting old bugs)
4. some static web pages describing your project to the newcomer

Regarding (1), Github is all the hype today. I would personally advise
against it, or at least about "just github", because:
- it is not free software (compared to free software alternatives such as
gitorious : http://gitorious.org/ ), and I dislike hosting a free software
project on a proprietary platform, although most people seems ok with it
and that's their choice
- it does not provide a mailing-list, which is critical; in fact,
mailing-lists tend to be replaced in github-centric (or gitorious-centric
for the matter) projects tend by pull-request discussions that are by
nature sparse, less effective, not very well archived, and more generally a
bad way to discuss even code contributions

The OCaml Forge ( http://forge.ocamlcore.org/ ) provides hosting for OCaml
software which fulfills all requirement above. Arguably, it is a bit heavy
for code hosting and the bug tracker interface is less welcoming than
others -- in particular Github bugtracker is very refined. I would consider
Ocamlforge, with code hosting disabled and a central Gitorious repository
as a very good choice for any OCaml free software project.

There are other non-OCaml-specific forges that provide mailing-lists and
run on free software. Launchpad ( https://launchpad.net/ ) may be
compelling if you are ready to use the Bazaar DCVS, and Sourceforge (
http://sourceforge.net/ ) has recently launched a renewed open source forge
( http://sourceforge.net/p/allura/wiki/Allura%20Wiki/ ) with apparently
good support for the mainstream control version systems (git, hg, svn).

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

> Dear caml-list,
>
> During the last year or two it seems that time and interest in OCaml
> maintenance from the official OCaml development team is diminishing. It
> takes several months to get a patch reviewed (if at all), which is quite
> frustrating for OCaml contributors and even worse for OCaml users. I
> suspect that this is one of the top reasons why there are only a few active
> contributors to OCaml (and the number of active users, at least on the
> mailing list, is declining).
>
> I understand that INRIA does not necessarily pay people for full time
> maintenance jobs on OCaml (and Coq), and the official dev team is probably
> already doing as much as possible to maintain OCaml. Given that OCaml is
> such a nice language with a lot of useful frameworks available, it is too
> sad to see it loosing ground just because of it's closed development
> process and lack of time of the official team.
>
> I'd therefore propose to open up OCaml development to a wider range of
> developers / contributors, to ensure that OCaml will be ready for the
> (functional programming) future. There are already various "OCaml forks" in
> the wild, with different goals and patch sets, so simply starting another
> fork would be rather useless. Instead I'd suggest to bundle efforts in a
> new "OCaml community fork", which is always based on the most recent
> upstream OCaml release (starting point would be 3.12.1 for now), and takes
> care to review and integrate pending patches as well as developing and
> testing new features. Let's say we'd name the fork "OCaml-ng", then we'd
> try to release a new patch set every month or two, based on the official
> OCaml release, i.e. "ocaml-3.12.1+ng201112" and so on, to get early testing
> and feedback (should work together closely with the Debian/Ubuntu/etc.
> OCaml maintainers).
>
> With this process, OCaml upstream could merge (tested) patches from
> OCaml-ng once they proved working in the wild, and thereby
>
> 1. maintenance overhead for INRIA people is reduced,
> 2. maintenance status of OCaml would be way better,
> 3. there would be a lot less frustration for possible contributors, and
> 4. users benefit from a better and more up to date OCaml.
>
> Now that does of course raise a few questions:
>
> 1. What is the opinion of the official development team / INRIA on this?
> 2. Who would help with the community fork?
> 3. What about infrastructure?
>
> Feedback and suggestions are welcome.
>
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 6164 bytes --]

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

[Stefano Zacchiroli]

On Tue, Dec 06, 2011 at 12:40:07PM +0100, Gabriel Scherer wrote:
> I would consider Ocamlforge, with code hosting disabled and a central
> Gitorious repository as a very good choice for any OCaml free software
> project.

I concur. That said, Gitorious being Free Software, it is also possible
to set it up on alternative locations. I'm still an admin of OCamlForge,
although a *very* dormant one. But if there are enthusiastic volunteers
to work on the idea, I'll be happy to support them in an attempt to
install a Gitorious instance as part of the OCamlForge.

It that will prove to be feasible, we can ask FusionForge upstream to
add support for self-hosted Gitorious instances, as the current
FusionForge for Git is hardly useful at all (no support for multiple Git
repositories, no support for pull request, etc.). I believe this could
benefit the OCamlForge, as well as a very valuable addition to
FusionForge in general. (We can even dare asking the Caml Consortium to
sponsor the last part of the plan, but first we need to show the plan is
feasible ant that it has potential.)

Cheers.
-- 
Stefano Zacchiroli     zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ......   http://upsilon.cc/zack   ......   . . o
Debian Project Leader    .......   @zack on identi.ca   .......    o o o
« the first rule of tautology club is the first rule of tautology club »

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

[Benedikt Meurer]

On Dec 6, 2011, at 10:31 , rixed@happyleptic.org wrote:

> The problem with this proposition as stated, in my opinion, is that
> the original fork is very easy to do but the following review/release
> processes asks for more volunteers time.

I'm willing to spend time and knowledge, and I hope others are also willing to do so, that's what my mail is about to some degree.

> Why not concentrate on a fork that's already there with plenty of
> patches, for instance this one :
> 
> https://github.com/thelema/ocaml-community
> 
> and roll a first release out of it ?

As mentioned there are various forks, we also have several forks of our own. I'm not proposing to add just another fork with 1-2 contributors, but I'm proposing to join forces on a single OCaml community project with a clear goal (the other forks can continue to exist and work on their respective goals with merging into ocaml-ng from time to time, i.e. when a milestone is reached).

Benedikt

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

[Joel Reymont]

On Dec 6, 2011, at 1:02 PM, Stefano Zacchiroli wrote:

> I concur. That said, Gitorious being Free Software, it is also possible
> to set it up on alternative locations.

Why does this matter more than ease of collaboration and usability?

--------------------------------------------------------------------------
- for hire: mac osx device driver ninja, kernel extensions and usb drivers
---------------------+------------+---------------------------------------
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
---------------------+------------+---------------------------------------

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

[Benedikt Meurer]

On Dec 6, 2011, at 11:00 , Gerd Stolpmann wrote:

> I'd say it depends very much for which kind of work the community fork is
> used. If it is just for enhancing the standard library, please don't do it
> - there are as many opinions as contributors. If it is for fixing bugs I'm
> for it - provided there is a process to get the fixes back to the original
> Ocaml version.

Yes that'd be one major goal: to get patches applied (whether they're fixing bugs or adding features). Whether it will be possible to get the "original OCaml version" updated using a new process or whether the "original OCaml" will be obsolete at some point,... I don't know. I guess time will tell. At least we'll see some more activity in the OCaml core area again.

> Regarding your work, Benedikt, I'm not sure what would be the best. It's
> highly interesting work, but it's deeply changing the compiler, so
> probably not something a community of volunteers could review (although
> they could test it at least).

I can't tell you right now how these things are going to work out, I'm open for suggestions. Most of what I have in the pipe (and others who sent me their patches for review because they haven't received any response from the OCaml team) does not "deeply change the compiler". The largest patch, which I'm working on right now, is about replacing the existing arm port with two new ports, armel and armhf, to overcome the various issues with the existing port (and to utilize VFP/Neon hardware in modern ARM boards/netbooks).

> I'd see this more as an effort to organize help for the core team, and it
> would be essential that the "fork" is working in both directions.

... or as an effort to disconnect "core team" and INRIA...

> Gerd

Benedikt

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

[François Bobot]

Le 06/12/2011 12:40, Gabriel Scherer a écrit :
>     3. What about infrastructure?
>
>
> Short answer: Ocamlforge ( http://forge.ocamlcore.org/ ) for mailing
> list, bug tracking and homepage, and Gitorious ( https://gitorious.org/
> ) for code repository hosting.
>

For reviewing, gerrit seems to be a great infrastructure (I never use
it as a developer) :

http://code.google.com/p/gerrit/
======
Gerrit is a web based code review system, facilitating online code 
reviews for projects using the Git version control system.

Gerrit makes reviews easier by showing changes in a side-by-side 
display, and allowing inline comments to be added by any reviewer.

Gerrit simplifies Git based project maintainership by permitting any 
authorized user to submit changes to the master Git repository, rather 
than requiring all approved changes to be merged in by hand by the 
project maintainer. This functionality enables a more centralized usage 
of Git.
======

You can see a review of a CyanogenMod patch :
http://review.cyanogenmod.com/#change,10719



-- 
François Bobot

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

[Benedikt Meurer]

On Dec 6, 2011, at 12:31 , Gerd Stolpmann wrote:

>> I would like to comment on a tangential aspect of the rationale you gave:
>> 
>>> Given that OCaml is such a nice language with a lot of useful frameworks
>>> available,
>>> it is too sad to see it loosing ground just because of it's closed
>>> development process
>>> and lack of time of the official team.
> 
> I'm quite reluctant to discuss topics about the said decline of something.
> However, there is certainly a point here. I have my own theory - basically
> the users with FP knowledge have now more options (e.g. F# or the
> JVM-based FP languages like Scala), and so the "share" for Ocaml is
> decreasing. This has nothing to do with the language.
> 
> However, the question is whether we can do more to attract programmers
> with FP knowledge (or even better educate programmers without). Ocaml is
> not doing enough here - there is no (really good) beginner's site, and
> there are not enough "success stories", i.e. users reporting that they
> solved something with Ocaml, and why it was a good choice.

Let me clarify what I mean: I think that both Gabriel and Gerd and right, and the success of OCaml does not solely depend on the openness of the compiler toolchain. Of course there's a lot more people can do to help with OCaml.

Now, I'm not particularly good at writing documentation or blogging about OCaml, but I can provide code and knowledge for the language implementation and in particular the compiler. And looking through Mantis there are others who are also willing to help with core stuff by sending patches, reporting bugs, etc. Unfortunately this is highly frustrating, as mentioned, because the OCaml core does not get a lot of love from the OCaml core team (for whatever reasons). Now you can move on and fork OCaml (Git makes that amazingly easy today) and add your patches, etc. We did this several times, and others also did. And the end you have the situation as we see it today: several forks with different goals / quality, various long standing bug reports with / without patches that don't get attention, almost no activity in the OCaml Subversion repository (as a result) compared to other active programming languages, and many frustrated contributors with time, interest and knowledge that would be really beneficial to OCaml otherwise.

> Gerd

Benedikt

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

[Stefano Zacchiroli]

On Tue, Dec 06, 2011 at 01:16:27PM +0100, Joel Reymont wrote:
> > I concur. That said, Gitorious being Free Software, it is also possible
> > to set it up on alternative locations.
> 
> Why does this matter more than ease of collaboration and usability?

- Politically, to not depend on a 3rd party infrastructure for your
  work.

- Practically, to find and exploit synergies (e.g. Git <-> bug tracker
  integration) that are, at present, not possible on Gitorious alone
  (e.g. because Gitorious lacks a bug tracking system)

But you do have a point: as Gitorious is not structured as a federated
service, moving away from it means making a bit more difficult for
already existing Gitorious users to send pull requests on another
instance. Given Gitorious supports OpenID login, though, this "bit" of
extra difficulty is very tiny, IMHO.

-- 
Stefano Zacchiroli     zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ......   http://upsilon.cc/zack   ......   . . o
Debian Project Leader    .......   @zack on identi.ca   .......    o o o
« the first rule of tautology club is the first rule of tautology club »

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

[Benedikt Meurer]

On Dec 6, 2011, at 12:40 , Gabriel Scherer wrote:

> 3. What about infrastructure?
> 
> Short answer: Ocamlforge ( http://forge.ocamlcore.org/ ) for mailing list, bug tracking and homepage, and Gitorious ( https://gitorious.org/ ) for code repository hosting.

Personally I'd prefer GitHub and OCamlForge, mostly because of the nice interface offered by GitHub (integration with pull requests / issue tracker, wiki, etc.). Technically we could also push stuff to Gitorious and OCamlForge Git repositories (but accept pull requests on GitHub only for now) if people are worried about code only on GitHub.

Benedikt

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

[Goswin von Brederlow]

Gabriel Scherer <gabriel.scherer@gmail.com> writes:

> There have been numerous "OCaml community meeting" discussing
> precisely these issues. I attended the 2008 meeting, and several
> aspects were discussed, including among others
> (1) the lack of openness of the compiler development (what you discuss here)
> (2) the apparent stagnation of the OCaml language itself
> (3) the lack of a comprehensive general-purpose set of software
> libraries that newcomers could just use as a standard starting point
> (4) the lack of visibility of user-contributed OCaml code, tools and
> libraries, or perceived difficulties to install and deploy such code
> (5) (related) the lack of communication of OCaml users about what they do
>
> You are singling out problem (1) as *the* problem with OCaml. I think
> this is more a reflect of your personal preferences (indeed, you are
> now a distinguished OCaml backend hacker) than a global analysis of
> the needs of the "OCaml community". I agree that (1) hasn't changed
> much since 2008; as you noted (at least from an external point of
> view), there are important human factors that make the situation
> difficult : not everyone can contribute to the compiler as there are
> both technical and social barriers to contribution.

It is *the* problem with ocamls upstream. Patches to the compiler and
core modules are not getting reviewed or accepted in a long time if at
all. And there is nothing you can do outside of the ocaml compiler to
fix that. Only option is to fork.

> (2) has clearly turned to be wrong. I distinctly remember being
> surprised at that time by the announcement of 3.12's first-class
> module, and thinking when Xavier Leroy mentioned GADTs -- at the 2008
> meeting -- that it would just never happen.

Yeah, when they do release something there seems to be allways something
new and shiny added. I also don't so much mind a language that remains
static. Means existing code does not break. Ocaml has been verry good in
this and only added to the language without breaking compatibility (much).

> (3) is currently being worked on by different people. The OCaml
> Batteries Included project as an ambitious goal to provide a
> community-built "distribution" of OCaml software in a coherent whole
> (the idea was later taken, and impressively performed, by the "Haskell
> Platform" effort). It has since restrained it ambitions to providing a
> superset of the libraries distributed with the compiler, as a wider
> "standard library". Jane Street Core's library similarly aims to
> provide a "bigger standard library", with in particular an impressive
> offering regarding the pervasive cross-module aspects such as
> marshalling / unmarshalling data and similar datatype-generic
> concerns.
>   http://batteries.forge.ocamlcore.org/
>   http://ocaml.janestreet.com/?q=node/13
>
> Using, contributing to or talking about those projects would also help
> OCaml not to "loose ground". I won't make any judgement on whether a
> more complete library is more or less useful that a change to the
> compiler toolchain, and it certainly is a different kind of work prone
> to interest different peoples. But it is also an important aspect of
> the OCaml ecosystem.
> I have irregularly contributed to the Batteries project, and I know
> for sure that the project is willing to accept any help on things to
> improve (in particular unit testing and documentation). Even, or
> especially, small one-shot contributions can help : three unit tests
> for a given function, a new tiny auxiliary function in such module, a
> bunch of typo fixes for the documentation...

As you say this is being worked on and this can be easily be worked on
outside of the compiler. This is just add-ons that need little to no
coordination with the ocaml core team.

Over the years many extra modules have been written and the OCaml
Batteries Included project has taken up the job of integrating those
modules with each other into a cohesive collection. Cudos to them, they
are doing a great work.

I think what we need for the ocaml core is exactly something like
Batteries but at a lower level. A group of people that will work
together to grab the little bug fixes and feature from various ocaml
forks and provide a single point of communication between both the core
team and forks as well as between forks itself. Even if it just improves
the communication between forks and maybe manages to merge a few of them
it will be a big win.

As a second example, not ocaml related as such, of what we need maybe
look at glibc. The glibc upstream has been slow and difficult to accept
patches. So lots of linux distribution had to maintain their own patches
for a long time, esspecially for not x86 architectures, and bugfixes
where not shared between distribution as a result. So a bunch of people
got together and create eglibc. Several distributions now use eglibc and
bugfixes flow from distributions to eglibc and from there to glibc
upstream and back to other distriutions. Now bugfixes spread quickly
between the distributions.

MfG
        Goswin

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

[ivan chollet]

[-- Attachment #1: Type: text/plain, Size: 3558 bytes --]

On a side note, it's important to realise that there is no incentive for
INRIA to give up on the centralisation of the OCaml project.
The current status of OCaml is more than stable enough to serve its goals,
which are to teach computer science to french undergrads and provide a
playground for computer languages researchers.
Any attempt to expect something different from a public organisation is
unrealistic in my view.
It would be as wrong to think that the original OCaml contributers do what
they want with this project, public politics can also play a significant
role here.

A fork could possibly get traction from the community, but you would have
to provide interesting features that the real OCaml does not provide. Bug
fixes won't be enough.


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

> Dear caml-list,
>
> During the last year or two it seems that time and interest in OCaml
> maintenance from the official OCaml development team is diminishing. It
> takes several months to get a patch reviewed (if at all), which is quite
> frustrating for OCaml contributors and even worse for OCaml users. I
> suspect that this is one of the top reasons why there are only a few active
> contributors to OCaml (and the number of active users, at least on the
> mailing list, is declining).
>
> I understand that INRIA does not necessarily pay people for full time
> maintenance jobs on OCaml (and Coq), and the official dev team is probably
> already doing as much as possible to maintain OCaml. Given that OCaml is
> such a nice language with a lot of useful frameworks available, it is too
> sad to see it loosing ground just because of it's closed development
> process and lack of time of the official team.
>
> I'd therefore propose to open up OCaml development to a wider range of
> developers / contributors, to ensure that OCaml will be ready for the
> (functional programming) future. There are already various "OCaml forks" in
> the wild, with different goals and patch sets, so simply starting another
> fork would be rather useless. Instead I'd suggest to bundle efforts in a
> new "OCaml community fork", which is always based on the most recent
> upstream OCaml release (starting point would be 3.12.1 for now), and takes
> care to review and integrate pending patches as well as developing and
> testing new features. Let's say we'd name the fork "OCaml-ng", then we'd
> try to release a new patch set every month or two, based on the official
> OCaml release, i.e. "ocaml-3.12.1+ng201112" and so on, to get early testing
> and feedback (should work together closely with the Debian/Ubuntu/etc.
> OCaml maintainers).
>
> With this process, OCaml upstream could merge (tested) patches from
> OCaml-ng once they proved working in the wild, and thereby
>
> 1. maintenance overhead for INRIA people is reduced,
> 2. maintenance status of OCaml would be way better,
> 3. there would be a lot less frustration for possible contributors, and
> 4. users benefit from a better and more up to date OCaml.
>
> Now that does of course raise a few questions:
>
> 1. What is the opinion of the official development team / INRIA on this?
> 2. Who would help with the community fork?
> 3. What about infrastructure?
>
> Feedback and suggestions are welcome.
>
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 4205 bytes --]

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

[Alexandre Pilkiewicz]

Hi all,

I will not jump in the "how to save OCaml from dying because nothing
moves" discussion. But just in the "nothing moves" discussion.

On Tue, Dec 6, 2011 at 2:52 PM, ivan chollet <ivan.chollet@gmail.com> wrote:
> The current status of OCaml is more than stable enough to serve its goals,
> which are to teach computer science to french undergrads and provide a
> playground for computer languages researchers.

First, french undergrads sadly often still use camllight... Which is
not the case for example of Harvard undergrad
(http://www.seas.harvard.edu/courses/cs51/lectures.html) and some
UPenn one (http://www.seas.upenn.edu/~cis341/). But you are right that
I can't find any well known university out of France using OCaml to
teach computer science...

And for the "computer languages researchers" part, I'll refer you to
http://caml.inria.fr/consortium/

> A fork could possibly get traction from the community, but you would have to
> provide interesting features that the real OCaml does not provide. Bug fixes
> won't be enough.

So now, here is my real problem. What are those famous so wanted
feature that this fork will provide? And what makes you (a plural you)
think that ocaml is such a slowly moving and evolving language?
According to the caml web site, in the past two years, we've seen
native dynlink, polymorphic recursion and first class module making
there way into the language. According to what can be found on the
trunk of the ocaml svn, the next release will have GADTs. And the
compiler have also been modified to incorporate things like a nice
multiprecision library (http://forge.ocamlcore.org/projects/zarith/)
and some backends have been added.

Except maybe haskell and Scala, can you really name me a programming
language that in fact evolves that quickly, and basically without ever
breaking backward compatibility? I really don't think that any of
python, perl, java, C, C++ would really win. But I might be wrong.

So before saying we need to fork the OCaml compiler to add "much
needed patches", it would be nice to minimally agree on witch patches
are so much needed. Because if "the community" can't agree on this, I
doubt the future of this potential fork will be so bright.

My 2c.

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

[Gerd Stolpmann]

> Hi all,
>
> I will not jump in the "how to save OCaml from dying because nothing
> moves" discussion. But just in the "nothing moves" discussion.
>
> On Tue, Dec 6, 2011 at 2:52 PM, ivan chollet <ivan.chollet@gmail.com>
> wrote:
>> The current status of OCaml is more than stable enough to serve its
>> goals,
>> which are to teach computer science to french undergrads and provide a
>> playground for computer languages researchers.
>
> First, french undergrads sadly often still use camllight... Which is
> not the case for example of Harvard undergrad
> (http://www.seas.harvard.edu/courses/cs51/lectures.html) and some
> UPenn one (http://www.seas.upenn.edu/~cis341/). But you are right that
> I can't find any well known university out of France using OCaml to
> teach computer science...

Well, if you ask whether _any_ FP language is taught, the results won't be
much better.

I'm currently doing consulting for a web company (in Germany) - around 60
developers, many fresh from the University. There are only three guys
knowing FP languages at all - one Scala, one Erlang, and one R. It's a
complete failure of the academic education.

IMHO it does not matter which FP language you are taught in. The point is
that the students understand the ideas, and that they recognize them as
relevant. These web developers here in the company have no clue that they
actually developing a big continuation-style FP program.

Gerd


>
> And for the "computer languages researchers" part, I'll refer you to
> http://caml.inria.fr/consortium/
>
>> A fork could possibly get traction from the community, but you would
>> have to
>> provide interesting features that the real OCaml does not provide. Bug
>> fixes
>> won't be enough.
>
> So now, here is my real problem. What are those famous so wanted
> feature that this fork will provide? And what makes you (a plural you)
> think that ocaml is such a slowly moving and evolving language?
> According to the caml web site, in the past two years, we've seen
> native dynlink, polymorphic recursion and first class module making
> there way into the language. According to what can be found on the
> trunk of the ocaml svn, the next release will have GADTs. And the
> compiler have also been modified to incorporate things like a nice
> multiprecision library (http://forge.ocamlcore.org/projects/zarith/)
> and some backends have been added.
>
> Except maybe haskell and Scala, can you really name me a programming
> language that in fact evolves that quickly, and basically without ever
> breaking backward compatibility? I really don't think that any of
> python, perl, java, C, C++ would really win. But I might be wrong.
>
> So before saying we need to fork the OCaml compiler to add "much
> needed patches", it would be nice to minimally agree on witch patches
> are so much needed. Because if "the community" can't agree on this, I
> doubt the future of this potential fork will be so bright.
>
> My 2c.
>
> --
> 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
>
>
>


-- 
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.

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

[Yitzhak Mandelbaum]

Gerd,

I think this is a great topic, but perhaps we could change the title to keep it separate from the main discussion?

(e.g. FP-language education)

Yitzhak

On Dec 6, 2011, at 10:10 AM, Gerd Stolpmann wrote:

> 
>> Hi all,
>> 
>> I will not jump in the "how to save OCaml from dying because nothing
>> moves" discussion. But just in the "nothing moves" discussion.
>> 
>> On Tue, Dec 6, 2011 at 2:52 PM, ivan chollet <ivan.chollet@gmail.com>
>> wrote:
>>> The current status of OCaml is more than stable enough to serve its
>>> goals,
>>> which are to teach computer science to french undergrads and provide a
>>> playground for computer languages researchers.
>> 
>> First, french undergrads sadly often still use camllight... Which is
>> not the case for example of Harvard undergrad
>> (http://www.seas.harvard.edu/courses/cs51/lectures.html) and some
>> UPenn one (http://www.seas.upenn.edu/~cis341/). But you are right that
>> I can't find any well known university out of France using OCaml to
>> teach computer science...
> 
> Well, if you ask whether _any_ FP language is taught, the results won't be
> much better.
> 
> I'm currently doing consulting for a web company (in Germany) - around 60
> developers, many fresh from the University. There are only three guys
> knowing FP languages at all - one Scala, one Erlang, and one R. It's a
> complete failure of the academic education.
> 
> IMHO it does not matter which FP language you are taught in. The point is
> that the students understand the ideas, and that they recognize them as
> relevant. These web developers here in the company have no clue that they
> actually developing a big continuation-style FP program.
> 
> Gerd
> 
> 
>> 
>> And for the "computer languages researchers" part, I'll refer you to
>> http://caml.inria.fr/consortium/
>> 
>>> A fork could possibly get traction from the community, but you would
>>> have to
>>> provide interesting features that the real OCaml does not provide. Bug
>>> fixes
>>> won't be enough.
>> 
>> So now, here is my real problem. What are those famous so wanted
>> feature that this fork will provide? And what makes you (a plural you)
>> think that ocaml is such a slowly moving and evolving language?
>> According to the caml web site, in the past two years, we've seen
>> native dynlink, polymorphic recursion and first class module making
>> there way into the language. According to what can be found on the
>> trunk of the ocaml svn, the next release will have GADTs. And the
>> compiler have also been modified to incorporate things like a nice
>> multiprecision library (http://forge.ocamlcore.org/projects/zarith/)
>> and some backends have been added.
>> 
>> Except maybe haskell and Scala, can you really name me a programming
>> language that in fact evolves that quickly, and basically without ever
>> breaking backward compatibility? I really don't think that any of
>> python, perl, java, C, C++ would really win. But I might be wrong.
>> 
>> So before saying we need to fork the OCaml compiler to add "much
>> needed patches", it would be nice to minimally agree on witch patches
>> are so much needed. Because if "the community" can't agree on this, I
>> doubt the future of this potential fork will be so bright.
>> 
>> My 2c.
>> 
>> --
>> 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
>> 
>> 
>> 
> 
> 
> -- 
> Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
> Creator of GODI and camlcity.org.
> Contact details:        http://www.camlcity.org/contact.html
> Company homepage:       http://www.gerd-stolpmann.de
> *** Searching for new projects! Need consulting for system
> *** programming in Ocaml? Gerd Stolpmann can help you.
> 
> 
> 
> -- 
> 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
> 

-----------------------------
Yitzhak Mandelbaum

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

[Pierre-Alexandre Voye]

[-- Attachment #1: Type: text/plain, Size: 5196 bytes --]

And one of the great sub-topic is how to avoid that students *hate* FP.
When i say to other programmers i code in ocaml, they answer they
absolutely hate this language they have to learn at university. I met this
"effect" more than 15 times !
There's a great problem of old boring professors who teach FP with
uninteresting problems (and lectures).
So the litlle part of programmers who faces FP-language simply forget how
to think in FP way..

2011/12/6 Yitzhak Mandelbaum <yitzhakm@cs.princeton.edu>

> Gerd,
>
> I think this is a great topic, but perhaps we could change the title to
> keep it separate from the main discussion?
>
> (e.g. FP-language education)
>
> Yitzhak
>
> On Dec 6, 2011, at 10:10 AM, Gerd Stolpmann wrote:
>
> >
> >> Hi all,
> >>
> >> I will not jump in the "how to save OCaml from dying because nothing
> >> moves" discussion. But just in the "nothing moves" discussion.
> >>
> >> On Tue, Dec 6, 2011 at 2:52 PM, ivan chollet <ivan.chollet@gmail.com>
> >> wrote:
> >>> The current status of OCaml is more than stable enough to serve its
> >>> goals,
> >>> which are to teach computer science to french undergrads and provide a
> >>> playground for computer languages researchers.
> >>
> >> First, french undergrads sadly often still use camllight... Which is
> >> not the case for example of Harvard undergrad
> >> (http://www.seas.harvard.edu/courses/cs51/lectures.html) and some
> >> UPenn one (http://www.seas.upenn.edu/~cis341/). But you are right that
> >> I can't find any well known university out of France using OCaml to
> >> teach computer science...
> >
> > Well, if you ask whether _any_ FP language is taught, the results won't
> be
> > much better.
> >
> > I'm currently doing consulting for a web company (in Germany) - around 60
> > developers, many fresh from the University. There are only three guys
> > knowing FP languages at all - one Scala, one Erlang, and one R. It's a
> > complete failure of the academic education.
> >
> > IMHO it does not matter which FP language you are taught in. The point is
> > that the students understand the ideas, and that they recognize them as
> > relevant. These web developers here in the company have no clue that they
> > actually developing a big continuation-style FP program.
> >
> > Gerd
> >
> >
> >>
> >> And for the "computer languages researchers" part, I'll refer you to
> >> http://caml.inria.fr/consortium/
> >>
> >>> A fork could possibly get traction from the community, but you would
> >>> have to
> >>> provide interesting features that the real OCaml does not provide. Bug
> >>> fixes
> >>> won't be enough.
> >>
> >> So now, here is my real problem. What are those famous so wanted
> >> feature that this fork will provide? And what makes you (a plural you)
> >> think that ocaml is such a slowly moving and evolving language?
> >> According to the caml web site, in the past two years, we've seen
> >> native dynlink, polymorphic recursion and first class module making
> >> there way into the language. According to what can be found on the
> >> trunk of the ocaml svn, the next release will have GADTs. And the
> >> compiler have also been modified to incorporate things like a nice
> >> multiprecision library (http://forge.ocamlcore.org/projects/zarith/)
> >> and some backends have been added.
> >>
> >> Except maybe haskell and Scala, can you really name me a programming
> >> language that in fact evolves that quickly, and basically without ever
> >> breaking backward compatibility? I really don't think that any of
> >> python, perl, java, C, C++ would really win. But I might be wrong.
> >>
> >> So before saying we need to fork the OCaml compiler to add "much
> >> needed patches", it would be nice to minimally agree on witch patches
> >> are so much needed. Because if "the community" can't agree on this, I
> >> doubt the future of this potential fork will be so bright.
> >>
> >> My 2c.
> >>
> >> --
> >> 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
> >>
> >>
> >>
> >
> >
> > --
> > Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
> > Creator of GODI and camlcity.org.
> > Contact details:        http://www.camlcity.org/contact.html
> > Company homepage:       http://www.gerd-stolpmann.de
> > *** Searching for new projects! Need consulting for system
> > *** programming in Ocaml? Gerd Stolpmann can help you.
> >
> >
> >
> > --
> > 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
> >
>
> -----------------------------
> Yitzhak Mandelbaum
>
>
>
>
>
> --
> 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
>
>


-- 
---------------------
https://twitter.com/#!/ontologiae/
http://linuxfr.org/users/montaigne

[-- Attachment #2: Type: text/html, Size: 7945 bytes --]

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

[Fabrice Le Fessant]

On Tue, Dec 6, 2011 at 11:58 AM, Stefano Zacchiroli <zack@upsilon.cc> wrote:
> On Tue, Dec 06, 2011 at 11:51:00AM +0100, Fabrice Le Fessant wrote:
>> For the OCaml distribution itself, OCamlPro will have a different
>> release cycle for its own version, targetting industrial users, but the
>                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Meaning that the code will not be freely (as in Free Software)
> available?  (in case you have already decided that)

If you check on Mantis, you will see that many patches have been
submitted by OCamlPro for inclusion in the mainstream OCaml
distribution. Our goal is not to compete with INRIA's distribution,
but to improve it (so, everything that OCamlPro does will be submitted
for inclusion in the mainstream distribution), and to package it more
often, providing/including bug fixes faster, with a high quality
testing process before each release, that fits the need of industrial
users for stability.

--Fabrice

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

[Mehdi Dogguy]

On 12/06/2011 05:12 PM, Fabrice Le Fessant wrote:
> On Tue, Dec 6, 2011 at 11:58 AM, Stefano Zacchiroli <zack@upsilon.cc>
> wrote:
>> On Tue, Dec 06, 2011 at 11:51:00AM +0100, Fabrice Le Fessant 
>> wrote:
>>> For the OCaml distribution itself, OCamlPro will have a
>>> different release cycle for its own version, targetting
>>> industrial users, but the
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> Meaning that the code will not be freely (as in Free Software) 
>> available?  (in case you have already decided that)
> 
> If you check on Mantis, you will see that many patches have been 
> submitted by OCamlPro for inclusion in the mainstream OCaml 
> distribution. Our goal is not to compete with INRIA's distribution, 
> but to improve it (so, everything that OCamlPro does will be 
> submitted for inclusion in the mainstream distribution), and to 
> package it more often, providing/including bug fixes faster, with a 
> high quality testing process before each release, that fits the need
>  of industrial users for stability.
> 

For example, does it mean that [1] will be sent to upstream? It is in
"For Beta-testers" section for now… but, I'm pretty sure you'll have
more testers if the patch was publicly published (reading code helps
testing). And, if yes, then do you know when?

[1] http://www.ocamlpro.com/code/2011-05-06-longval.html

(I can't check ocaml's bugtracker content right now as it appears to be
offline. Apologies if that specific patch has been _publicly_ submitted
on mantis).

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/

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

[oliver]

Hello,


during the last years, more than one person mourned about
this or that dark sides of OCaml.

Even some of the mourning and the proposals had mentioned good ideas and had
positive motivation, after a while it became clear, that the same people with
the one or the other good idea, failed badly in other areas. Good, that they
did not have had too much influence in the development of OCaml.

Even in general I like the community/bazaar, I think in case of OCaml,
there is a lot of high knowledge in the core team, which was criticized
by others already, but in the long run, it turned out that the core team
had their reasons for a lot of decisions, which were criticized.
Ocaml of course will also have some history-related issues that might be
changed, but maybe also a lot of decisions inside, which relies on theoretical
reasoning.

So I'm sceptical here again.

There is a lot of software around, where even beginners could change it to the
better.

But regarding OCaml, I think even for advanced programmers, it might be easy
to change it to the worse.

Of course (nearly) nobody of the people on this list would admit that,
but let's wait a while, and it maybe will show again, as it did before. ;-)


Instead of general mourning, I think discussing on certain
topics would make more sense.

But this also was done already and often.


Maybe I misunderstood the original intention of the thread starter,
but that are just my opinions here.

It's often assumed, that anything that is driven by the community / bazaar
can flourish and anything driven by the "cathedral" is starving to death.

Not sure if this is true.

Isn't it a general problem of functional languages to have a small
user base?

What are the OCaml-forks doing?
Are they flourishing?
Do they make functional programming more popular?

Or is it just a minor change?


Functional languages are minority languages.
And forks of such languages... are they really hype?

It seems to me, that rather imperative languages pick up functional features,
and become more popular through this kind of process.

So... what happens if the minority splits again and again?

Can a community of a hand full of users/hackers flourish more
than a couple of hands of such people?

Will Ocaml and other functional languages become more popular by
splitting the user base into even smaller parts?

Will such projects live long (enough)?

I have some reasonable doubts here.


Ciao,
   Oliver

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

[oliver]

Hello,


On Tue, Dec 06, 2011 at 11:35:55AM +0100, Gabriel Scherer wrote:
[...]
> Having a personal blog is not the only way to help disseminate
> information about OCaml. If you participate to news-aggregation sites
> such as Slashdot, Reddit or whatever, you should consider submitting
> OCaml-related content that could be of interest to the target
> audience, or participating in relevant discussions when appropriate.
> "Appropriate" is the key word here : quality should be favored over
> quantity, and I personally try not to get involved in negative
> discussions (in particular language flamewars: informed users of other
> programming languages are not enemies, even if they are frustratingly
> better at propaganda, have a nicer surface syntax, and indulge
> themselves into letting people think that "pure" necessarily means
> "better", hint hint :-). The OCaml community should have a public face
> to be proud of; it is currently gradually moving out of total silence.
[...]


It's not easy to talk about Ocaml, if you not already have used it...
...and understood, what's different there, and why it's, as it is.

It's very similar to explaining a user of "office software" the
advantages of LaTeX.

But with Ocaml it's even more complicated, because some terms
(like "reference" or "abstract data type") are also used in other
languages... but these terms have a different meaning there.

So, when you try to explain the certain properties of OCaml,
people put it into the same box that they use for their own language,
even it's completely different stuff.

I'm really tired of long language flamewars, and so I better
enjoy using OCaml in my (personal) projects (because
t work it's very unlikely that I can use it), than trying to convince
others of OCaml.

This seems to be different here for the people on the list...?!


And if I nevertheless fall back into old convincing-behaviour,
most often I fail.

So if I'm such a bad person in PR / "evangelisation" / Ocaml-propaganda,
I better let other people do the work, who can do it much better.

And one way to explain the advantages of OCaml (as compared to java for example),
is this article from Yaron Minsky:

  Why the next language you learn should be functional
  Yaron Minsky, Jane Street
    http://queue.acm.org/detail.cfm?id=2038036


Of course this can't convince people who are fixed at their non-OCaml language,
but from at least two people (with some mathematical and programming background,
who are not OCaml-programmers) I got very positive feedback ofr that article.

So, instead of never ending language flamewars, I think, such good and clear articles
like that, mentioned above, would make more sense.

BTW I  also have to mourn about that article: instead of
  "Why the next language you learn should be functional"
the tile should have been better
  "Why the next language you learn should be OCaml" :-)


Ciao,
   Oliver

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

[Adrien]

Hi,

My only complaint about the current development model is that it is a
bit opaque and we don't really know what is happening; we mostly only
see the result once it has been done.

I'd like to know some things like: this feature/patch (will/will
not/might/might not) go in/will be tried/we have no idea/... Maybe a
preliminary opinion from the guts but at least some signal because
it's impossible to see a difference between something that hasn't been
looked at yet and something that is being silently rejected.

This would also make the core development seem more active (and
considering the major changes we've seen with each major release in
the past years, it definitely is).

Regards,
Adrien Nader

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

[Goswin von Brederlow]

"Gerd Stolpmann" <info@gerd-stolpmann.de> writes:

>> Hi all,
>>
>> I will not jump in the "how to save OCaml from dying because nothing
>> moves" discussion. But just in the "nothing moves" discussion.
>>
>> On Tue, Dec 6, 2011 at 2:52 PM, ivan chollet <ivan.chollet@gmail.com>
>> wrote:
>>> The current status of OCaml is more than stable enough to serve its
>>> goals,
>>> which are to teach computer science to french undergrads and provide a
>>> playground for computer languages researchers.
>>
>> First, french undergrads sadly often still use camllight... Which is
>> not the case for example of Harvard undergrad
>> (http://www.seas.harvard.edu/courses/cs51/lectures.html) and some
>> UPenn one (http://www.seas.upenn.edu/~cis341/). But you are right that
>> I can't find any well known university out of France using OCaml to
>> teach computer science...
>
> Well, if you ask whether _any_ FP language is taught, the results won't be
> much better.
>
> I'm currently doing consulting for a web company (in Germany) - around 60
> developers, many fresh from the University. There are only three guys
> knowing FP languages at all - one Scala, one Erlang, and one R. It's a
> complete failure of the academic education.
>
> IMHO it does not matter which FP language you are taught in. The point is
> that the students understand the ideas, and that they recognize them as
> relevant. These web developers here in the company have no clue that they
> actually developing a big continuation-style FP program.
>
> Gerd

In Tuebingen we started with scheme in the first year and later there
were several classes on FP languages and a few using ocaml, for example
the compiler construction class. But the later classes are pick&choose,
you just need enough credits from each of the 3 major groups, so people
can probably completly avoid FP based curses.

Personally I think the introduction to computer languages class we had
is a must. How else do you even know what is out there and if you like
it?

MfG
        Goswin

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

[Goswin von Brederlow]

oliver <oliver@first.in-berlin.de> writes:

> Hello,
>
>
> during the last years, more than one person mourned about
> this or that dark sides of OCaml.
>
> Even some of the mourning and the proposals had mentioned good ideas and had
> positive motivation, after a while it became clear, that the same people with
> the one or the other good idea, failed badly in other areas. Good, that they
> did not have had too much influence in the development of OCaml.
>
> Even in general I like the community/bazaar, I think in case of OCaml,
> there is a lot of high knowledge in the core team, which was criticized
> by others already, but in the long run, it turned out that the core team
> had their reasons for a lot of decisions, which were criticized.
> Ocaml of course will also have some history-related issues that might be
> changed, but maybe also a lot of decisions inside, which relies on theoretical
> reasoning.

That is no excuse for not reacting to bug or feature patches. If
there is a reason not to accept a patch then that can be communicated.

There is no excuse for silence.

MfG
        Goswin

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

[oliver]

On Wed, Dec 07, 2011 at 10:39:30AM +0100, Goswin von Brederlow wrote:
> oliver <oliver@first.in-berlin.de> writes:
> 
> > Hello,
> >
> >
> > during the last years, more than one person mourned about
> > this or that dark sides of OCaml.
> >
> > Even some of the mourning and the proposals had mentioned good ideas and had
> > positive motivation, after a while it became clear, that the same people with
> > the one or the other good idea, failed badly in other areas. Good, that they
> > did not have had too much influence in the development of OCaml.
> >
> > Even in general I like the community/bazaar, I think in case of OCaml,
> > there is a lot of high knowledge in the core team, which was criticized
> > by others already, but in the long run, it turned out that the core team
> > had their reasons for a lot of decisions, which were criticized.
> > Ocaml of course will also have some history-related issues that might be
> > changed, but maybe also a lot of decisions inside, which relies on theoretical
> > reasoning.
> 
> That is no excuse for not reacting to bug or feature patches. If
> there is a reason not to accept a patch then that can be communicated.
> 
> There is no excuse for silence.
[...]

OK, I can agree here.
More communication might be fine.

I don't know how much the OCaml team is overwhelmed with work.
And I don't know how much time it needs to give feedback; that
also depends on the bugtracking tools.
If the used tools are too uncnvenient, maybe they could be changed.

But that also needs work.

I remember that I once had a feature wish.
As far as I remember, it was picked up, but
also done silently...

Last time when I was logged in at the OCaml bugtracker (long ago btw),
there were a lot of issues... some bug-reports, some feature wishes.
Don't remember if automatic messaging must be activated, but I
don't remember that status change was reported to me.

When I use launchpad for Ubuntu, then Messages will be delivered automatically
to the reporter of a bug.

Maybe the toolchain can be enhanced, so that no extra overhead for writing
messages is necessary.

Ciao,
   Oliver

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

[Jérôme Benoit]

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

On Tue, 6 Dec 2011 12:31:07 +0100
"Gerd Stolpmann" <info@gerd-stolpmann.de> wrote:

> 
> > I would like to comment on a tangential aspect of the rationale you
> > gave:
> >
> >> Given that OCaml is such a nice language with a lot of useful
> >> frameworks available,
> >> it is too sad to see it loosing ground just because of it's closed
> >> development process
> >> and lack of time of the official team.
> 
> I'm quite reluctant to discuss topics about the said decline of
> something. However, there is certainly a point here. I have my own
> theory - basically the users with FP knowledge have now more options
> (e.g. F# or the JVM-based FP languages like Scala), and so the
> "share" for Ocaml is decreasing. This has nothing to do with the
> language.

It's not an issue for OCaml development, it's an issue for newcomers.
The main issue is : OCaml community do not have a fucking clue of what
a codeflow really *is*. 

Never ever seen a commit only list on all of the OCaml projects seen so
far. Never ever seen a patches flow working (via BTS or mail). Never
read a well documented commit comment. Never read a comment on a patch
or a commit. 

And you want hackers to be implicate in the OCaml development
process with not even a working and documented codeflow, the first
and essential brick any FOSS project just all share ? 

Cheers.

-- 
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Jérémie Dimino]

Le mercredi 07 décembre 2011 à 05:59 -0800, tools a écrit :
> --- LWT:   We have experience with the ocsigen people, and a track record of several lwt bugs discovered, testcases that assert the problem, and patches to the mailing list or the developers personally.
>    If it concerns code, 95% (not measured, but this is how it feels) of the time, things are fixed the same or next day in their repo. 
>    [We also sent documentation patches cleaning up the "Franglais", but these were totally ignored. I guess they just don't notice how bad it really is.]

Sorry, i just forgot about the typos.txt file you sent me. I am going to
make the changes.

-- 
Jérémie

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

[tools]

Hi,

I'm responsible for the introduction of OCaml in two companies( www.incubaid.com , www.amplidata.com ).
This cost me a lot of energy and a few years of my life, I'm sure. 

As we now are few years further, so I can look back and reflect a bit.

The whole experience of working with a strongly typed, polymorphic, functional, programming language feels really gratifying.
I think everybody who has been exposed to this for a longer period of time feels the same.
It's a winning strategy.

As far as compiler/toolchain/runtime/programming environment/libraries/community go, I have a few remarks which I address below
 (random order):

- "language" I'm not eagerly awaiting new features. OCaml might not be too sexy, but it gets the job done.

- "multi core" (talked about in great detail here on the mailing list) I won't say anything more than
    it would be nice if there was support to harvest the current generation of cpus as we currently resort 
   to ad hoc solutions (and keep on reinventing the wheel). We're not really in pain, but worried.

- "ocamlbuild/oasis/ " I have a hard time bashing 'autofoo' and 'make' when every little thing I need to explain to ocamlbuild
  eats away a half day of my time. Yes, in the end, the delta is always small, but it's the time not the number of lines that matter.
  It's probably a documentation issue (the wiki is outdated)

- "IDE". actually, only emacs is more or less ok; tuareg needs tweaking, and debugging is painful (and yes, sometimes you would like too).
   ...but not everybody likes emacs. Personally I'm rather impartial, but I have access to an emacs zealot, which helps.

- "tools": what tools? 
-- a heap profiler would be nice. OCamlviz is broken/abandoned/not enough.
    You just hope you never have an ocaml lwt-based server that fuzzily grows to 10GB without any clue about what's eating the memory.
-- a performance profiler that understands the language would help too: we currently resort to valgrind (Valgrind is not the problem)
-- a debugger that doesn't make you want to kill your spouse would be nice too.
-- we use bisect for coverage and that's ok.

- "Windows". has been covered before. It seems to be difficult to set up. Actually, I wouldn't know as we currently (and nothing in the pipeline) only do linux.
   (And it's a reassuring feeling that our brief escapades on BSD and Solaris turned out ok). 

   But I'm convinced  people who have windows as their only platform, will prefer F# or Haskell (I would too).

- "libraries": A lot is out there. Some are good, some are bad,  some don't like each other (lwt and async fe), some are lean, some are kitchen sinks.
  This will always be the case (whatever paradigm, programming language, or community). We actually don't need a lot since we mostly do system programming. 
  What we do need and often use is the foreign function interface, and I don't have complaints there (having experienced JNI in the past, I know this can be painful).

- "Community" I think we might split them in 2. the "Cathedral" (responsible for the download bundle) and Others (sometimes the same people in a different context)
-- Cathedral: If you want to have something in there (patch, bugfix, feature) and you're not part of the inner circle, you have zero insight in what will happen, 
   and a small chance of success. (This has also been covered here a lot, no need to digress)
-- Others 
--- LWT:   We have experience with the ocsigen people, and a track record of several lwt bugs discovered, testcases that assert the problem, and patches to the mailing list or the developers personally.
   If it concerns code, 95% (not measured, but this is how it feels) of the time, things are fixed the same or next day in their repo. 
   [We also sent documentation patches cleaning up the "Franglais", but these were totally ignored. I guess they just don't notice how bad it really is.]

--- Other libraries: again, most of the time, if we contact the developer(s) we quickly get a response. If it is a bug, it's fixed (almost) immediately.
    most (OCaml library) developers seem to have enough pride in what they do to make this happen. Really, no complaints there.

The bottom line is this: In our companies, there are 3 sets of people with OCaml exposure.
- those attracted to the greener pastures of Haskell
- those that think the OCaml ecosystem sucks, but less than other things, and not enough to move.
- those that think OCaml tool support sucks too much, and consider moving back to "the evil they know" (C++)


Btw, I checked, and none of them have any problem with type inference, or functional programming.


Anyway, I think that the next time we have the opportunity to choose the programming language for a component, we will have some interesting discussions.

have fun,

Romain.