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 pBCCKVme026354 for ; Mon, 12 Dec 2011 13:20:31 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMBAODw5U6GnQCBkWdsb2JhbABDhQeldSIBAQEBCQsLBxQDIoFyAQEEASMPAUUBBQsJAhgCAgUWCwICCQMCAQIBRQYNAQcCEId0CKMNkQ+BNIkjgRYElHGFS4xd X-IronPort-AV: E=Sophos;i="4.71,338,1320620400"; d="scan'208";a="135017424" Received: from shiva.jussieu.fr ([134.157.0.129]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Dec 2011 13:20:26 +0100 Received: from hydrogene.pps.jussieu.fr (hydrogene.pps.jussieu.fr [134.157.168.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id pBCCJsfZ047859 ; Mon, 12 Dec 2011 13:20:07 +0100 (CET) X-Ids: 168 Received: from [127.0.0.1] (unknown [134.157.168.1]) by hydrogene.pps.jussieu.fr (Postfix) with ESMTPS id 73038C137F; Mon, 12 Dec 2011 13:19:53 +0100 (CET) Message-ID: <4EE5F173.1080607@dogguy.org> Date: Mon, 12 Dec 2011 13:20:03 +0100 From: Mehdi Dogguy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111120 Icedove/8.0 MIME-Version: 1.0 To: Benedikt Meurer CC: Xavier Leroy , caml users References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE37070.4010702@inria.fr> <4EE5D593.9060708@inria.fr> In-Reply-To: X-Enigmail-Version: 1.3.3 OpenPGP: id=1C00C790 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Miltered: at jchkmail.jussieu.fr with ID 4EE5F16A.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4EE5F16A.003/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/ Subject: Re: [Caml-list] OCaml maintenance status / community fork (again) 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, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/