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 pB6GuoCr014204 for ; Tue, 6 Dec 2011 17:56:50 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYBAIlI3k7RVdY2kGdsb2JhbABDmiyFCYMOAYgQCCIBAQEBCQkNBxQEIYFyAQEBAQIBEgIsARsSCwEDAQsGBQsNDSEiAREBBQEKEgYTEgIHB4dlCJgaCotkgmuFID2IcQIFCoNoh0AEgluFU4w4jWw9hBU X-IronPort-AV: E=Sophos;i="4.71,307,1320620400"; d="scan'208";a="122275386" 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 17:56:44 +0100 Received: by bkat2 with SMTP id t2so13414874bka.27 for ; Tue, 06 Dec 2011 08:56:44 -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=mG01V3qx4qLxLbMXD+2MijtMIF5BHHoVvOX+Y9STJLI=; b=Rc1A3GgCj1M0UJZH9jbMJ2eDLtvLSrskNf3l4IfBvtBm5ACfgwlspo101wDg73LQDU U/3hwYhVZQ497F6DeN4Wwif3/QTuVAChWM8xPvRB8jPLDzjuPd+BkWT/FIpVmnpU5xW+ Mplwn7JRi48gIG7SOSCxoqb0HRnUqzrcasHy8= Received: by 10.180.75.204 with SMTP id e12mr18009001wiw.61.1323190604276; Tue, 06 Dec 2011 08:56:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.54.19 with HTTP; Tue, 6 Dec 2011 08:56:23 -0800 (PST) In-Reply-To: References: <4EDE33A0.6070004@gmail.com> From: Ashish Agarwal Date: Tue, 6 Dec 2011 11:56:23 -0500 Message-ID: To: Benedikt Meurer Cc: Jonathan Protzenko , caml-list@inria.fr Content-Type: multipart/alternative; boundary=f46d04389567f0220f04b36f517e Subject: Re: [Caml-list] Some comments on recent discussions --f46d04389567f0220f04b36f517e Content-Type: text/plain; charset=ISO-8859-1 I agree that package management, a *single* standard library, and a good web presence are the most useful things we can do. We desperately need oasis, oasis-db, and eventually an OCaml Platform to succeed. The standard library contenders are Batteries and Jane St Core. Ideally these could be merged, but that will take a lot of effort from both teams. On the web side, we did start a project to build a new website for OCaml, announced at the last User Meeting. We are continuing to work on it, although admittedly progress has been slow. Nothing wrong with compiler improvements. We don't have to pick between these options. Let's just work on all of them. :) On Tue, Dec 6, 2011 at 11:03 AM, Benedikt Meurer < benedikt.meurer@googlemail.com> wrote: > > On Dec 6, 2011, at 16:24 , Jonathan Protzenko wrote: > > > [...] > > > > If it's about improving the general situation with OCaml and its > community (the title of this thread contains the word "community"), then I > believe hacking on the compiler is not the most effective way to achieve > that goal. We're hackers. We like to hack on things. And we often fail to > ask ourselves: is it really worth implementing? Submitting patches is easy. > Submitting quality patches that do solve a real problem is harder. The ARM > backend does need a cleanup, and the patch does solve a stringent issue. > That may not be the case for all patches. > > You may be right, but I think you are also missing my point to some degree > here. Improving the OCaml community as a whole is a worthwhile goal and > more than welcome, but that is a far away, probably very difficult to > achieve goal. What I am talking about and what I am trying to address is a > rather practical problem: How to avoid pissing off possible contributors to > the OCaml core (these are most likely different people than the ones that > would help with web site, spreading the word, community stuff) and how to > improve the maintenance status of the OCaml core? Or maybe: How to set > OCaml free? > > > There is indeed a problem w.r.t external contributions. I agree that the > INRIA team could make it clearer what its stance on external contributions > is. Maybe one solution would be to have a INRIA-endorsed ocaml-next on > github that everyone can fork, where we would merge really outstanding > features, before submitting them to INRIA, as you described. I don't think > it is such a good idea creating a real fork. Maybe some sort of integration > platform on GitHub would be the right solution to the "patch review" > problem. > > As long as that would be INRIA-controlled, I fear that it would be the > same story with different infrastructure (you'll have pull requests that > don't get attention rather than bug reports that don't get attention). > > > I'm not even sure what kind of patches you wish to see integrated. Can > you clarify that? > > Mantis is down currently. > > > Kind regards, > > jonathan > > 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 > > --f46d04389567f0220f04b36f517e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree that package management, a *single* standard library, and a good we= b presence are the most useful things we can do. We desperately need oasis,= oasis-db, and eventually an OCaml Platform to succeed. The standard librar= y contenders are Batteries and Jane St Core. Ideally these could be merged,= but that will take a lot of effort from both teams. On the web side, we di= d start a project to build a new website for OCaml, announced at the last U= ser Meeting. We are continuing to work on it, although admittedly progress = has been slow.

Nothing wrong with compiler improvements. We don't have = to pick between these options. Let's just work on all of them. =A0:)


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

On Dec 6, 2011, at 16:24 , Jonathan Protzenko wrote:

> [...]
>
> If it's about improving the general situation with OCaml and its c= ommunity (the title of this thread contains the word "community")= , then I believe hacking on the compiler is not the most effective way to a= chieve that goal. We're hackers. We like to hack on things. And we ofte= n fail to ask ourselves: is it really worth implementing? Submitting patche= s is easy. Submitting quality patches that do solve a real problem is harde= r. The ARM backend does need a cleanup, and the patch does solve a stringen= t issue. That may not be the case for all patches.

You may be right, but I think you are also missing my point to some d= egree here. Improving the OCaml community as a whole is a worthwhile goal a= nd more than welcome, but that is a far away, probably very difficult to ac= hieve goal. What I am talking about and what I am trying to address is a ra= ther practical problem: How to avoid pissing off possible contributors to t= he OCaml core (these are most likely different people than the ones that wo= uld help with web site, spreading the word, community stuff) and how to imp= rove the maintenance status of the OCaml core? Or maybe: How to set OCaml f= ree?

> There is indeed a problem w.r.t external contributions. I agree that t= he INRIA team could make it clearer what its stance on external contributio= ns is. Maybe one solution would be to have a INRIA-endorsed ocaml-next on g= ithub that everyone can fork, where we would merge really outstanding featu= res, before submitting them to INRIA, as you described. I don't think i= t is such a good idea creating a real fork. Maybe some sort of integration = platform on GitHub would be the right solution to the "patch review&qu= ot; problem.

As long as that would be INRIA-controlled, I fear that it would be th= e same story with different infrastructure (you'll have pull requests t= hat don't get attention rather than bug reports that don't get atte= ntion).

> I'm not even sure what kind of patches you wish to see integrated.= Can you clarify that?

Mantis is down currently.

> Kind regards,
> jonathan

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


--f46d04389567f0220f04b36f517e--