> -----Original Message----- > From: centos-devel-bounces at centos.org [mailto:centos-devel- > bounces at centos.org] On Behalf Of Jim Perrin > Sent: 19 November 2014 4:13 PM > To: centos-devel at centos.org > Subject: Re: [CentOS-devel] RFC: OCaml SIG > > > > On 11/19/2014 07:20 AM, Jon Ludlam wrote: > > Hi all, > > > > I'd like to propose a new SIG for the OCaml language. > > > > OCaml is an industrial strength programming language supporting > functional, imperative and object-oriented styles. It has in recent years seen > a marked increase in development activity, particularly in the compiler itself > [1], core libraries [2] and developer tools [3]. Many of these newer libraries > and features are already dependencies of a number of large upstream > projects [4]. > > > > The version of OCaml in CentOS 6 is quite old (3.11.2, released in Jan 2010), > and even that in CentOS 7 is fairly old (4.00.1, released in October 2012). I see > the OCaml SIG providing the current stable compiler (4.02.1 at time of > writing), and a selection of useful libraries and developer tools. This could > then be used as a basis for other applications or SIGs to build upon - for > example, it would make CentOS a good platform for building Unikernels [5] > and it would be helpful in getting the Xapi Project suite of daemons [4] into > one of the virtualisation/cloud SIGs. We actually already have a number of > specs that are built for CentOS 6 which could make a good starting point [6]. > > > > A number of people have already agreed that they are interested and may > be able to help (all CC'd): > > > > From OCaml Labs (http://www.cl.cam.ac.uk/projects/ocamllabs/): > > - Anil Madhavapeddy > > - Thomas Gazagnaire > > > > From Jane Street (https://www.janestreet.com/): > > - Yaron Minsky > > - Dominick LoBraico > > > > From Citrix (https://www.citrix.com/): > > - Me > > - Euan Harris > > > > From OCamlPro (http://www.ocamlpro.com/): > > - Louis Gesbert > > > > Comments? > > > > Jon > > > > [1] GADTs, record disambiguation, PPX extensions, immutable strings, etc. > > [2] ocaml-ctypes, Jane Street Core, the openmirage.org suite of libraries, > etc. > > [3] opam, merlin, utop, etc. > > [4] https://github.com/xapi-project and http://ocsigen.org/ [5] > > http://queue.acm.org/detail.cfm?id=2566628 > > [6] https://github.com/xenserver/buildroot > > > > This seems like a very good start to the proposal. A few > questions/statements: > > 1. What would you require in terms of distribution resources? I'm assuming > git/koji access, so that you could build and distribute sig packages. > That sounds right. > 1a. Would you require a mailing list or forum area? > I think a mailing list would be helpful. Personally I'm less bothered by the forum area, but others may disagree. > 2. What do you envision for release planning? Tracking upstream builds vs a > newer stabilized release? I would imagine this decision being taken on a case-by-case basis. For critical things such as the compiler and some of the core libraries we may want to take the releases only after they've stabilised in the community for a while - e.g. the 4.02.0 release had a number of issues that 4.02.1 addressed, so we should be conservative in areas like this. For projects that are less mature, it may make more sense to simply track the releases as they happen. > > 3. How would releases be built/scheduled? Build every month, every 6 > months, "when something happens upstream" ? > Things happen upstream quite rapidly at the moment, so that would be too frequent. I suspect a monthly cadence would be right to begin with. > 4. Testing? How would you validate package builds? Are test suites included > as part of the source, or would you consider implementing some form of test > suite criteria to ensure builds do the right thing? > Many of the libraries that are obvious candidates right now have test suites designed to be run by travis - we can certainly ensure these are run as part of the build. Citrix could also run tests on any candidate changes before they get pushed by building, which may be helpful. Jon