From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pB6DqBHk002086 for ; Tue, 6 Dec 2011 14:52:12 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4BAIUc3k7RVdi2kGdsb2JhbABEmiyIFwGIEAgiAQEBAQkJDQcUBCGBcgEBAQMBEgIsARsSCwEDAQsGBQsaISIBEQEFAQoSBhMSAg6HZQiYBAqLZIJrhSc9iHECBQqDaIdABIJbjjWDVo1sPYN3 X-IronPort-AV: E=Sophos;i="4.71,306,1320620400"; d="scan'208";a="134166164" Received: from mail-qy0-f182.google.com ([209.85.216.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 06 Dec 2011 14:52:04 +0100 Received: by mail-qy0-f182.google.com with SMTP id e13so3185681qcs.27 for ; Tue, 06 Dec 2011 05:52:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LyJt/lhtaQIyedjF2MRTlYezxpH9TonvyalDMXGDUxk=; b=hVb59Fd2uf/mABOET7wR5ULvcZIkP9uvxu+GuMIgRjNh2d4iFX+ydu6cxS1ZIPyRqw 04SqxUri295NcjmX1x9PV0f2qKG/ApF+KqqDiQW+ETarzqRLeNbr1LQbXuOZDdvtN+qx hmm2fsfNphiGMbMUBnJxrbrcmhcW1m4Vv9UBU= MIME-Version: 1.0 Received: by 10.50.173.4 with SMTP id bg4mr7870828igc.42.1323179523934; Tue, 06 Dec 2011 05:52:03 -0800 (PST) Received: by 10.42.163.3 with HTTP; Tue, 6 Dec 2011 05:52:03 -0800 (PST) In-Reply-To: <1B0D83BD-1902-4F7C-B3FB-B759122D6AB9@googlemail.com> References: <1B0D83BD-1902-4F7C-B3FB-B759122D6AB9@googlemail.com> Date: Tue, 6 Dec 2011 13:52:03 +0000 Message-ID: From: ivan chollet To: Benedikt Meurer Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=e89a8f642ec47f89dc04b36cbda3 Subject: Re: [Caml-list] OCaml maintenance status / community fork --e89a8f642ec47f89dc04b36cbda3 Content-Type: text/plain; charset=ISO-8859-1 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 > > --e89a8f642ec47f89dc04b36cbda3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On a side note, it's important to realise that there is no incentive fo= r INRIA to give up on the centralisation of the OCaml project.
The curre= nt 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 fo= r computer languages researchers.
Any attempt to expect something different from a public organisation is unr= ealistic in my view.
It would be as wrong to think that the original OCa= ml contributers do what they want with this project, public politics can al= so play a significant role here.

A fork could possibly get traction from the community, but you would ha= ve to provide interesting features that the real OCaml does not provide. Bu= g 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 mainte= nance from the official OCaml development team is diminishing. It takes sev= eral 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 dec= lining).

I understand that INRIA does not necessarily pay people for full time maint= enance jobs on OCaml (and Coq), and the official dev team is probably alrea= dy 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 s= ee it loosing ground just because of it's closed development process an= d 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 (func= tional programming) future. There are already various "OCaml forks&quo= t; in the wild, with different goals and patch sets, so simply starting ano= ther fork would be rather useless. Instead I'd suggest to bundle effort= s in a new "OCaml community fork", which is always based on the m= ost 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 developi= ng and testing new features. Let's say we'd name the fork "OCa= ml-ng", then we'd try to release a new patch set every month or tw= o, based on the official OCaml release, i.e. "ocaml-3.12.1+ng201112&qu= ot; and so on, to get early testing and feedback (should work together clos= ely with the Debian/Ubuntu/etc. OCaml maintainers).

With this process, OCaml upstream could merge (tested) patches from OCaml-n= g 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. =A0Subscription 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


--e89a8f642ec47f89dc04b36cbda3--