From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 55B22BBC1 for ; Thu, 6 Mar 2008 15:21:15 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJqMz0fRVcipgWdsb2JhbACQeQEBCAUECQoWk3eGeg X-IronPort-AV: E=Sophos;i="4.25,456,1199660400"; d="scan'208";a="9043819" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 06 Mar 2008 15:21:15 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m26ELE9d015427 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 6 Mar 2008 15:21:15 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJqMz0fRVcipgWdsb2JhbACQeQEBCAUECQoWk3eGeg X-IronPort-AV: E=Sophos;i="4.25,456,1199660400"; d="scan'208";a="9043818" Received: from wf-out-1314.google.com ([209.85.200.169]) by mail1-smtp-roc.national.inria.fr with ESMTP; 06 Mar 2008 15:21:14 +0100 Received: by wf-out-1314.google.com with SMTP id 26so3050441wfd.0 for ; Thu, 06 Mar 2008 06:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/XR4g0a/s3jzqlecdl2qH9/bB9hWGdhxAt8z66CV2Tg=; b=mDdoBg5GtHGdwI3qnQ5Sm7R4sXEyDovAuYG5JUmQ1i/MCbF5hTGiGLI2xP0+qBH08gKI3N3adlC1Ld0Q+l+xevFdUxOdMIS5okjTNNfx8IxoEhF2qJy2qXllnjhsJRSONDht1PgfaHsXQ+tqpvtQUJw4cgdIq4GzSDZl+vntPVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r4zQGF1vmUYpobMYmPTQ9Dpm7bCnFbRh9hjFx+upuHX9jQZzI17J09NmNFr4UljR/syK4BDZC2dkFHSsanhRz6rAjV1dGJlLgBBY8HxyTtc2poWSTvIHYD1/jykmL84UnpxvM3l4lmyIcbe1q+f9Bgurx2YDxhTGDi4VaVFq0Yw= Received: by 10.143.1.2 with SMTP id d2mr1121993wfi.91.1204813272779; Thu, 06 Mar 2008 06:21:12 -0800 (PST) Received: by 10.143.30.20 with HTTP; Thu, 6 Mar 2008 06:21:12 -0800 (PST) Message-ID: Date: Thu, 6 Mar 2008 09:21:12 -0500 From: "Jim Miller" To: caml-list Subject: Re: [Caml-list] OSR - "Batteries included" - Standardizing syntax extensions and extra libraries In-Reply-To: <47CE8702.6070202@frisch.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47CD82F3.20600@exalead.com> <20080305001003.GB14117@annexia.org> <47CE73CB.8070904@exalead.com> <47CE8702.6070202@frisch.fr> X-Miltered: at discorde with ID 47CFFDDA.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; syntax:01 cdk:01 summarized:01 alain's:01 fwiw:01 cdk:01 ocaml:01 ocaml:01 developpers:01 modular:01 modular:01 maintainers:01 experimental:01 experimental:01 caml-list:01 This is an excellent exposition of what I agree are the real issues in this effort. Technical issues are the easy ones to solve, its the non-technical that get hard. I've looked at the old CDK archives and didn't see a summarized list of the reasons why it was being shut down but I'd be really interested in hearing a brief summary, many of which I'm sure are reflected in Alain's comments below. My personal opinion (FWIW) is that I'd like a CDK type thing, or at least have the ability to put an OCAML-OSR "release" onto a CD. I work in a LOT of environments where we don't have access to the Internet and I end up having to copy stuff back and forth on CD. (USB pen drives are beginning to be restricted so yes, it tends to be CD). Having a fully contained distribution where I KNOW that I have everything, or at least know everything I have, would save a huge amount of the frustration I've had over the years. > - what is the intended audience? The will influence both the selection > process and the motivation of people putting efforts into the distribution. I believe that the audience should be the non-sysadmin developer. While existing package management schemes are great the system should not require root access to install. > > - what is the policy w.r.t. to upgrades of libraries? It is very common > that a new version of a library break existing code, so simply upgrading > as soon as possible might not be the best choice. Should several > versions of OCaml-OSR be maintained in parallel? > > - what should be done when a library doesn't work out-of-the box for a > new version of OCaml? Should it be removed (temporarily) so as to allow > an early distribution of OCaml-OSR with the new OCaml? > > - who's in charge of maintaining a web site, upgrading libraries, > testing for several architecture, preparing releases, etc? This is a > lot of work, so a collaborative approach might be needed, but > responsibilities need to be defined. > I'd support three variations. Stable, Unstable, and Experimental. Having a lifecycle that introduces a new release at the Experimental phase and having it move through Unstable to Stable would allow for sufficient testing. Libraries that are being considered for a release could be included in the Experimental phase with the requirement that once it moves to Unstable, that the API must remain the same. A new major version of the library, one that breaks the API, would have to be introduced in the next Experimental release. There are then two ways to assign people to this. A different individual, or group of individuals, can take ownership of a release when it is first created in the Experimental state and continue owning it until it moves into the Stable state. The second way is to have a team that handles a particular stage and hands a release to another team. The level of commitment at the Experimental state is much higher than the Unstable, which is much higher than the Stable. By the Stable release the managers would hopefully only be rolling in minor bugs and rebundling, if necessary. > - will there be binary distributions? (Relying on Debian/Fedora/... > OCaml developpers does not solve the question for Windows. I think that the primary OCAML-OSR release should be in source form only, Godi style. If other people want to release binary packages then they can sign up to do that. It should be a different group of people from the OCAML-OSR maintainers described above. > > - will the addition/upgrade of a single library force to reinstall all > of OCaml-OSR, or will the distribution be made modular? Distribution should be modular but there is a case that can be made for a monolithic install. > > - will there be a common place to find the documentation for all the > selected packages? I think that the documentation should be included as part of the distribution itself. I think that this is one thing that the JDK did right. Having the documentation for the entire library in one place is very nice and something I find frustrating about OCaml. I've gone so far as to hand create my own JDK-ish page with all of the libraries I use ... I'd like to see something more standard as part of this. > > - will libraries that depend on C code and/or external components be > accepted? I think that the distribution needs to be self contained. Any C libraries that are required by it must be installed during installation if they don't already exist on the system. We run into this issue with software distribution all the time for our C++ based systems. We depend on many libraries but depending on the system they may or may not be present. This is a royal pain. I think that anything that either can't or shouldn't be distributed should be packaged as an extension to the OCaml-OSR release and not part of the core.