[opam-devel] [Caml-list] opam and godi

[Anil Madhavapeddy]

On 22 Jul 2013, at 08:44, Adrien Nader <adrien at notk.org> wrote:

> In the end, maybe you have:
> - godi, slower package updates but usually more stable; bugs in packages
>  are less common but when they exist, they can also take time to fix
> - opam, many more updates, maybe too many, packages get less testing
>  before they reach others (if you want new software, you can't have a
>  week of testing between each release)
> 
> NB: don't get me wrong, I don't blame any package maintainer or package
> on slow updates or bugs: many issues arise when software is used on 10
> different setups (different CPUs, different OS, ....)

This is absolutely true.  I've been assembling a little machine pool of
'exotic architectures' that make it easier to test all the various 
permutations.  OPAM has a vestigial autobuilder now that runs through a
bunch of different platforms.  For a *temporary* URL with our development
version, see:
https://ocaml-www3.ocamllabs.cl.cam.ac.uk/github/OCamlPro/opam-repository

Once the teething issues are sorted, David Sheets has also written Github
bindings so that work will be queued up directly from a Github pull request.
Anyone submitting a report can have their package tested on systems they
don't normally have access to.  This will in turn let us do acceptance tests
before merging pull requests into the 'stable' OPAM repository.

I really like the Git workflow behind all this.  It basically reflects
how we work with OCaml in an industrial setting: pool up a sequence of
local changes (across multiple repositories), publish them to an internal
OPAM remote, and then issue pull requests upstream until you hit the
central stable repository.  At no point do you have to block waiting for
someone else to do something for you, unless it's the default central
repository that Thomas and I monitor.

I'm also very pleased to announce that Rackspace (who use OCaml via the
Xen Cloud toolstack) have recently donated a significant number of VMs
to power all the builds behind this. We can use this infrastructure to
securely run unit tests: we just need to set up a "gold image" VM with
the build, unplugging its external network interface, run the test,
and then replug it back into the network.  All via HTTP interfaces,
with feedback sent back to the package maintainer via the Github pull
request interface.

-anil

(PS: for those concerned about an over-dependence on Github, I'm currently
evaluating Gitlab, which Jeremy Yallop pointed out to me -- it seems a
good candidate to mirror all this activity somewhere else, while still
using Github as a primary source).