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 pBCALDGM020077 for ; Mon, 12 Dec 2011 11:21:13 +0100 X-IronPort-AV: E=Sophos;i="4.71,337,1320620400"; d="scan'208";a="134996156" Received: from estephe.inria.fr (HELO [128.93.11.95]) ([128.93.11.95]) by mail1-relais-roc.national.inria.fr with ESMTP; 12 Dec 2011 11:21:07 +0100 Message-ID: <4EE5D593.9060708@inria.fr> Date: Mon, 12 Dec 2011 11:21:07 +0100 From: Xavier Leroy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Benedikt Meurer CC: caml-list@inria.fr References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE37070.4010702@inria.fr> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] OCaml maintenance status / community fork (again) On 12/10/2011 04:58 PM, Benedikt Meurer wrote: > Maybe we can get back to my original proposal and restart on the > right foot this time? All right. I have a number of concerns about your proposal, most of which have already been mentioned by others. Whether you call it a fork or not, the mere fact of having two separate code bases for exactly the same software components raises more issues than it solves: - 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? - It means additional efforts with some duplication. The synchronization between the "community" and the "reference" code bases will take work. From the core team's standpoint, that's about as much work as dealing with individual suggestions and contributions. At the same time, the community team will spend non-negligible time organizing and administering itself, at least initially. - It would be a PR disaster. I struggled (and still have to struggle) with my INRIA management to get a little bit of support for OCaml's development, e.g. Xavier Clerc's part-time assignment to work on OCaml. This support is fragile and can easily disappear if there's a perception that "the community" will take care of that anyway. Likewise, I don't quite see how to explain the situation to the members of the Caml consortium. For these reasons, I feel that the cure is worse than the illness. I am, however, much more sympathetic to your other proposal, namely: > Why not accept a model similar to i.e. the NetBSD project, with a > lot of committers (experts in their own areas) and 2-3 people to > keep an eye on the overall direction? Except for the "lot of committers" part, this is pretty much how the core Caml team has been working, and there is definitely room for more contributors. As I mentioned earlier, there are a number of areas where we're lacking manpower, e.g. Windows-related stuff and tools such as the debugger or Camlp4, but many other areas of the system would benefit from more contributors too. Smaller contributions are most welcome as well, such as commenting on the PRs, testing changes, new features and release candidates, PR triaging, helping to identify the top little things to be resolved by the next release, etc. That's a much more low-key approach, but one that is more likely to succeed. Volunteers are welcome to contact us as caml@inria.fr. - Xavier Leroy