caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: Benedikt Meurer <benedikt.meurer@googlemail.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] OCaml maintenance status / community fork
Date: Tue, 6 Dec 2011 12:40:07 +0100	[thread overview]
Message-ID: <CAPFanBEJhuvkex-HHT_kk_kDbC9fv9+vt8QXDLt902j9ovK2jg@mail.gmail.com> (raw)
In-Reply-To: <1B0D83BD-1902-4F7C-B3FB-B759122D6AB9@googlemail.com>

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

  parent reply	other threads:[~2011-12-06 11:40 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-06  8:25 Benedikt Meurer
2011-12-06  9:17 ` Goswin von Brederlow
2011-12-06 10:08   ` Gaius Hammond
2011-12-06  9:31 ` rixed
2011-12-06 12:10   ` Benedikt Meurer
2011-12-06  9:42 ` Kakadu
2011-12-06  9:48   ` Joel Reymont
2011-12-06 10:51   ` Fabrice Le Fessant
2011-12-06 10:58     ` Stefano Zacchiroli
2011-12-06 16:12       ` Fabrice Le Fessant
2011-12-06 19:24         ` Mehdi Dogguy
2011-12-06 10:00 ` Gerd Stolpmann
2011-12-06 12:20   ` Benedikt Meurer
2011-12-06 10:35 ` Gabriel Scherer
2011-12-06 11:31   ` Gerd Stolpmann
2011-12-06 12:34     ` Benedikt Meurer
2011-12-15 18:49     ` Jérôme Benoit
2011-12-06 13:09   ` Goswin von Brederlow
2011-12-06 22:48   ` oliver
2011-12-07  7:23     ` Adrien
2011-12-06 11:40 ` Gabriel Scherer [this message]
2011-12-06 12:02   ` Stefano Zacchiroli
2011-12-06 12:16     ` Joel Reymont
2011-12-06 12:43       ` Stefano Zacchiroli
2011-12-06 12:27   ` François Bobot
2011-12-06 13:01   ` Benedikt Meurer
2011-12-06 13:52 ` ivan chollet
2011-12-06 14:42   ` Alexandre Pilkiewicz
2011-12-06 15:10     ` Gerd Stolpmann
2011-12-06 15:14       ` Yitzhak Mandelbaum
2011-12-06 15:24         ` Pierre-Alexandre Voye
2011-12-07  9:36       ` Goswin von Brederlow
2011-12-06 22:07 ` oliver
2011-12-07  9:39   ` Goswin von Brederlow
2011-12-07 20:42     ` oliver
     [not found] <201112071100.pB7B0N8J020839@walapai.inria.fr>
2011-12-07 13:59 ` tools
2011-12-07 14:37   ` Jérémie Dimino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPFanBEJhuvkex-HHT_kk_kDbC9fv9+vt8QXDLt902j9ovK2jg@mail.gmail.com \
    --to=gabriel.scherer@gmail.com \
    --cc=benedikt.meurer@googlemail.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).