From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pB6BeTt1028979 for ; Tue, 6 Dec 2011 12:40:31 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssDAMH+3U7RVdY2kGdsb2JhbABEmiw0h2MBhRyBXoEVCCIBAQEBCQkNBxQEIYFyAQEBAwESAiwBGxILAQMBCwYFCxohIgERAQUBChIGExICDodlCJduCotkgmuFND2IcQIFCoNoh0AEgluSC41sPYN4 X-IronPort-AV: E=Sophos;i="4.71,304,1320620400"; d="scan'208";a="122219275" Received: from mail-bw0-f54.google.com ([209.85.214.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 06 Dec 2011 12:40:31 +0100 Received: by bkat2 with SMTP id t2so12796030bka.27 for ; Tue, 06 Dec 2011 03:40:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C6+bXK8OYiBZ91oIQ8X17TBBfXhdYB92oFwEFrn04K0=; b=tKko/Cb17A/9P1HwNOYSdyzJRdCojvSXNf1McOlolFtuU5LtbudDV1ExHKYjJ5Heh2 U1ViF9cAMjpKw/eGuFC8WFgG9yBjWuKOzN11wIc6H5zGoRFsc9SGnm8oKyyQCuyrAkLJ 3P573Sxf0BtEPaOMhQQzhM85UVA7Ov8UXqAlQ= Received: by 10.216.174.74 with SMTP id w52mr640867wel.11.1323171629336; Tue, 06 Dec 2011 03:40:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.43.4 with HTTP; Tue, 6 Dec 2011 03:40:07 -0800 (PST) In-Reply-To: <1B0D83BD-1902-4F7C-B3FB-B759122D6AB9@googlemail.com> References: <1B0D83BD-1902-4F7C-B3FB-B759122D6AB9@googlemail.com> From: Gabriel Scherer Date: Tue, 6 Dec 2011 12:40:07 +0100 Message-ID: To: Benedikt Meurer Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=001485f44c74f18a3904b36ae615 Subject: Re: [Caml-list] OCaml maintenance status / community fork --001485f44c74f18a3904b36ae615 Content-Type: text/plain; charset=ISO-8859-1 > > 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 > > --001485f44c74f18a3904b36ae615 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
3. What about infrastructure?

Short answer: Ocamlf= orge ( http://forge.ocamlcore.org/<= /a> ) for mailing list, bug tracking and homepage, and Gitorious ( https://gitorious.org/ ) for code repositor= y hosting.

Long answer:

In my experience, the most important things for a r= elatively-small-scale free software project are, in decreasing order of imp= ortance:
1. a place where to drop code that people can look at (and foll= ow development, etc.)
2. a mailing-list
3. a bug tracker (mailing-list can do that but you ris= k 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", b= ecause:
- it is not free software (compared to free software alternatives such as g= itorious : http://gitorious.org/ ), a= nd I dislike hosting a free software project on a proprietary platform, alt= hough most people seems ok with it and that's their choice
- it does not provide a mailing-list, which is critical; in fact, mailing-l= ists tend to be replaced in github-centric (or gitorious-centric for the ma= tter) projects tend by pull-request discussions that are by nature sparse, = less effective, not very well archived, and more generally a bad way to dis= cuss even code contributions

The OCaml Forge ( http://= forge.ocamlcore.org/ ) provides hosting for OCaml software which fulfil= ls all requirement above. Arguably, it is a bit heavy for code hosting and = the bug tracker interface is less welcoming than others -- in particular Gi= thub bugtracker is very refined. I would consider Ocamlforge, with code hos= ting 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 an= d run on free software. Launchpad ( http= s://launchpad.net/ ) may be compelling if you are ready to use the Baza= ar DCVS, and Sourceforge ( http://sourc= eforge.net/ ) has recently launched a renewed open source forge ( http://sourcefor= ge.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 Meu= rer <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


--001485f44c74f18a3904b36ae615--