[ocaml-platform] OCamlot

[Anil Madhavapeddy]

On 14 Feb 2013, at 11:15, Sylvain Le Gall <sylvain+ocaml at le-gall.net> wrote:

> 2013/2/13 Anil Madhavapeddy <avsm2 at cl.cam.ac.uk>:
>> On 13 Feb 2013, at 22:42, Anil Madhavapeddy <avsm2 at cl.cam.ac.uk> wrote:
>> 
>>> Opamalot is more of a coordination service.  It interfaces with OPAM to get the (non-trivial) package database, version constraints and compiler variants out of it, and comes up with a prioritised schedule of builds and tests that need to be run on different platforms.  Some of these could (and should) run on third-party hosted services such as Travis, just to get some diversity.  Others, however, really require a Xen pool so that more exotic stuff can be done.
>> 
>> It's also worth noting the difference in execution speeds for adopting a copy-on-write approach.  We  need to test 300+ packages (which will grow) across 3.12.1/4.00.0/4.00.1/4.01.0dev and experimental compiler branches, ideally without recompiling the compiler for each package.  If a package fails to build on a fast architecture (x86), it should immediately be dropped from a slow one.
> 
> Humm, to be honest, I will:
> 1. limit the number of compiler version (4.00.1 or 4.01.0 when it will be out)
> 2. limit the number of packages

The whole point of this system is to test your code on systems that you wouldn't otherwise have access to.  It's much easier to fix breakage by testing continuously against trunk compiler versions, or ARM, or MIPS, on an ongoing basis.

> I think 300+ packages in OPAM term is the number of tarball. Let's
> just take either the last one or the last one that we were to build on
> all platform. I don't want to have OUnit 1.1.0 and 2.0.0...

That's the point of prioritising builds, but remember that older versions
are often depended on by packages, and don't just disappear from the
dependency chain.

-anil