[ocaml-platform] OCamlot

[Sylvain Le Gall]

2013/2/15 Thomas Gazagnaire <thomas at ocamlpro.com>:
>> 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
>>
>> 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...
>
> From my point-of-view, I really would like to see most of the 650+ packages (ie. 350+ unique packages) to be tested, in order to get a very precise idea of the dependencies constraints. This is indeed less useful than getting the latest version for each package, but it's quite important in order to get a reliable and consistent user experience.
>

Indeed 350+ package, didn't realize the number... (congrat)

As you stated, this is "less useful". So let's make it a secondary
target and focus on delivering a platform in 6 months. If possible
that would be great but we should focus on the main goal, we will have
to solve enough issues in the first round.

> Regarding the compiler versions, I think it's very useful to have an easy way to automatically test and benchmarks experimental SVN branches to look for regressions before integrating them in trunk, so I really think that opamalot should be able to do this as well.

I think we should have:
1. one chosen compiler version, which will be the target of the next
platform release (e.g 4.01, which happens to be the trunk right now)
2. the SVN trunk, as a "helper" to the  OCaml team so that we provide
them  enough information to have the best possible possible N+1
compiler (at least well tested)

Also 2. is a secondary target, let focus on 1.

My POV: deliver something interesting enough in 6 months.

If we reach a stable OCaml Platform in 3 months: GREAT ! Deliver it to
the community and try to act on the secondary target...

>
> Thomas
>
>>
>> Concerning Travis/Jenkins/whatever, I think we should consider this:
>> - just create a shell script that do the job and don't interface
>> strongly with the build system in the core job
>> - most of the builder I know, can have some restriction, esp
>> concerning accessing the network. This is not always true but we
>> should try to avoid downloading stuff
>> - create a big git repository that basically contains an opam
>> repository + the builder shell script and do the job inside it
>> - try to output the results of tests/build in a "common test result
>> format" (either TAP or JUnit)
>> - consider that most platform don't allow you to install stuff that
>> are 3rd party (e.g. C libraries that comes with the OS, like libzmq0
>> or libfoo.so.XX), I don't think we should build them on our own (let's
>> focus on OCaml)
>>
>> I think this can be done independently of the platform we use for
>> continuous integration, when we will have gained some experience, we
>> can enhance the process for a specific/preferred platform.
>>
>> I start to play quite nicely with Jenkins and I think you don't have
>> to build any plugin to make it works:
>> - use a matrix project to build on all platform, have a first step on
>> 1 particular platform that need to succeed (integrated, I use it)
>> - use a shell script to start the build, no maven, no ant (I use it)
>> - ...
>>
>> I will look at memory issue with java worker... Let's say I have a
>> couple of Java specialist sitting next to me. I will need to run one
>> on my RPi...
>>
>> Regards
>> Sylvain
>> _______________________________________________
>> Platform mailing list
>> Platform at lists.ocaml.org
>> http://lists.ocaml.org/listinfo/platform
>