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 pBJ49tw7021485 for ; Mon, 19 Dec 2011 05:09:55 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMBAMy37k7RVdW2kGdsb2JhbABDq1MIIgEBAQEJCQ0HFAQhgXIBAQEEEgIsARsdAQMMBgULDS4iAREBBQEcBhMUDodgmkAKi2WCa4QWP4hxAgULi3kEiDaMSI14PYQY X-IronPort-AV: E=Sophos;i="4.71,374,1320620400"; d="scan'208";a="123850339" Received: from mail-yx0-f182.google.com ([209.85.213.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 19 Dec 2011 05:09:49 +0100 Received: by yenl9 with SMTP id l9so4143515yen.27 for ; Sun, 18 Dec 2011 20:09:48 -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:content-transfer-encoding; bh=2hV2vdSBf1dCgCYInOpFtXc7x7vwISoQRZMMuzTsjBo=; b=QuFMX7usax0J0br1B6V7joOG9Q/ST5wR/At8lBsgEM/rj5gd19dwUi/K4RzEMt42rE IJ0VYDZ7dBJZMLaPAivzkiDL9ZgGTiQ7n+dEQr5BQmiJIKwGR5Adsf7Try5fOZ5aC7UI iSnJkpeFnUWYgF/S671Mn5ks7ZA6PXMjxKfy0= Received: by 10.236.174.72 with SMTP id w48mr16016061yhl.79.1324267788213; Sun, 18 Dec 2011 20:09:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.80.102 with HTTP; Sun, 18 Dec 2011 20:09:27 -0800 (PST) In-Reply-To: <4EE5F173.1080607@dogguy.org> References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE37070.4010702@inria.fr> <4EE5D593.9060708@inria.fr> <4EE5F173.1080607@dogguy.org> From: Romain Beauxis Date: Sun, 18 Dec 2011 22:09:27 -0600 Message-ID: To: Mehdi Dogguy Cc: Benedikt Meurer , Xavier Leroy , caml users Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id pBJ49tw7021485 Subject: Re: [Caml-list] OCaml maintenance status / community fork (again) Hi all, 2011/12/12 Mehdi Dogguy : > On 12/12/2011 11:59 AM, Benedikt Meurer wrote: >> >> On Dec 12, 2011, at 11:21 , Xavier Leroy wrote: >> >>> - It complicates the lives of OCaml users, packagers, and >>> 3rd-party library developers: what version should they use?  what >>> will be the basis for the packagers's distribution-specific >>> patches?  what happens if a library is compatible with one version >>> but not the other?  what if the community effort runs out of steam >>> in a few years? >> >> If we can adopt the eglibc model, then the community thing will be >> the version shipped by distributions, i.e. the community thing is the >> OCaml for distributions/packagers, not an alternative to the official >> version. That way we do no longer need to maintain specific patches / >> versions for Debian, Red Hat, MacPorts, etc. This ensures that >> versions are compatible across different distributions (because they >> do no longer need to maintain their own set of patches). >> > > No, distributions won't start shipping the community distribution just > because it exists. I cannot speak for Fedora (and others), but > Debian/Ubuntu won't switch to the community distribution that easily. In > fact, it may appear as a seperate source package at some point but won't > replace INRIA's ocaml in Debian. > > If you look at Debian's ocaml package, you'll notice that very few > custom patches are applied. > >        http://patch-tracker.debian.org/package/ocaml/3.12.1-2 > > Patches from 1 to 6 are just (let's say) build configurations to cope > with Debian's standards. All the rest has been submitted to upstream, > except patch 11. Some of the submitted patches were even applied in > trunk. I guess the rest will be integrated as well… Most of the patches > (from 7 to 15) are there to avoid build failures on some architectures. > > The problem with the community distribution is that: > 1) it doesn't exist yet. So, we cannot commit on something more than vague. > 2) we don't even know its release schedule, etc… > 3) we don't know the kind of changes that will be integrated to the > community distribution > 4) as of today, we don't even know if it is a good idea ; if it will be > a success ; etc… > >> I think of the community thing as: >> >> (a) A single place for patches, while waiting for the next official >> OCaml release. >> >> (b) A common ground for experimenting with new features. As you >> already noted, feedback and adoption for experimental stuff hidden >> within the SVN repository wasn't all that great, so maybe we can >> change it this way (esp. since it would be coordinated with the >> distributions/packagers to some degree). >> > > (a) seems very reasonable but (b) is unclear to me. You don't need to > create a community distribution of ocaml to experiment new features > sitting in ocaml's svn. Just checkout the relevant branch, and start > playing. The idea of the community distribution is to have an ocaml with > some patches on top of it (patches for bugs those sitting in mantis for > long time, a few features/experiments that are not present in ocaml's > svn). The idea is also to not diverge too much to keep things compatible. > > my 2cents, I have been busy with several fires and only came back to list recently. I might be late for the party but I would like to voice my opinion as this idea of "forking" OCaml is a pretty sensitive one. I, for one, am convinced that "forking" OCaml's core would be a terrible idea. As mentioned above by Mehdi as well as others, a "community" driven development process would not address the fundamental issue of taking core decisions. Those familiar with the Debian project surely know how these processes can be time-consuming and bring another form of frustration anyway. I would also like to mention that OCaml core developers probably do not get the proper recognition they deserve for the work they've put in the past years. Surely, some aspects could be criticized, but overall I have seen many changes which also preserved backward compatibility and minimized the amount of bugs introduced. I think this is overall a great job. OCaml's core is a sensitive part of the language and I can see how it can get frustrating to get one's work included into it. But, considering the importance of this part of the language, frustration is probably somehow a good thing. At least, it does not seem to me to justify any kind of forking. My real concern for the future of OCaml's development is more about side tasks that could very well be addressed by the community without completely breaking down the stability of its core. For instance, I have been maintaining for some time a version of Richard's cross-compiler in Debian. Most of those changes concern OCaml's build system which, admittedly, could be very well improved. On this point, I believe that it would be very nice to have, indeed, a clearer integration process and more communication from the core development team. For instance, if I would be to propose a complete rewrite of OCaml's build system, I'd like to know beforehand if my changes have any chance to be integrated and, if so, how should I tackle the issue in order to facilitates this integration (split up the changes in several patches, post them for review somewhere etc..). This also stand for the patches required to build the cross-compiler, which I think would be a great thing to have out of the box and would not require much changes in the core. On another topic, I also agree that there should be a real effort put into the visibility of the language and, more importantly, available libraries. Contrary to what others have mentioned, functional programming is not, I believe, a paradigm that would be so difficult to take on. Things like coffeescript [1], a "syntactic sugar" for javascript, becoming more and more used by JS programmers shows that the basics of functional programming syntactic have a great potential for adoption by a wider basis of developers. As it has been mentioned earlier, I, too, think that having more visibility on places where other languages and projects are also available is a key here. Github, indeed, seems like unavoidable at this point and, on the contrary, hosting our own gitorious would be yet another failure as it would set up an isolated platform for the language. Ultimately, I do not believe that academics should be taken responsible for the adoption of OCaml by young programmers. If one looks at ruby/rails or nodejs or, until recently, python, the success of those languages have little to do with academic programs but more with the dynamic, visibility and communication of their early adopters. Romain [1]: http://jashkenas.github.com/coffee-script/