Re: [Caml-list] opam and godi

[David Scott <dave.scott@eu.citrix.com>]

On 21/07/13 15:20, Anil Madhavapeddy wrote:
[ snip ]
 > Feature minutiae aside, I'd say the biggest benefit of OPAM is the more
 > open development workflow. It's easier for people to maintain their
 > own branches and contribute changes to the central repository.

[ snip ]

 > Several development groups also maintain their own remotes without any
 > need to depend on the central repository. For example, see Citrix's:
 > https://github.com/xapi-project/opam-repo-dev/tree/master/packages

I really like the git-style development workflow encouraged by OPAM. 
Note I'm not a GODI user so I don't know if the same thing can be done 
there.

The packages you link to above are in development, and having our own 
package repo in git means that we can use pull requests both to propose 
changes to the code, and to quickly update the packages. As each package 
matures, we can then make pull requests to the main OPAM repo.

Lowering the effort needed to create and maintain a package has had 
another useful side-effect (IMHO). Previously while working on 
Xen(Server) we created a few large monolithic libraries which were 
tending (perhaps) towards becoming 'frameworks' (in a bad way). Now 
we've started isolating distinct areas of functionality and chopping 
them off into independently usable libs, or dropping them altogether in 
favour of better alternatives (e.g. we're dropping a custom HTTP server 
library in favour of cohttp). This kind of strong isolation between 
components will make the code easier for us to maintain.

Regarding binary packages: for our use-cases binary package support via 
OPAM or GODI isn't necessary. We'd like to distribute binary packages of 
our software through Linux distributions, which means we're keen to 
create .rpms and .debs in the usual way. Typically our stuff runs as 
services, which means you need to write distro-specific code to 
integrate with systemd/upstart anyway, so there's little an automatic 
tool can do to help.


Cheers,
Dave Scott
XenServer System Architect, Citrix