Dear platform fellows, Many good points have been made already, so let me just add a few remarks.
- I have the impression that OCaml 4.03 introduces more breaking changes than 4.02 did. That could explain why OPAM packages are taking longer to be upgraded to 4.03. I don't know what it means for the future: should the OCaml core team be more prudent with breaking changes? should the packaging community get ready to handle even more breakage? - As an upstream author of a few libraries, it's not obvious to me what the best / recommended way is to communicate with the packagers of "my" software, e.g. being informed of problem reports with the corresponding packages, or informing them of new versions of "my" soft. - OPAM-wide continuous integration is great, of course. Concerning computing resources: > On Thu, Jun 30, 2016 at 11:09 AM, Fabrice Le Fessant > The reason why OPAM-builder cannot monitor trunk is by design: to > achieve almost real time on a 4-core computer for 5 versions of OCaml, > opam-builder makes an extensive use of caching binary installations of > dependencies. This cannot be done on a moving target like trunk, where > you would have to recompile all packages (all versions, sometimes with > different depends because of depopts) at every commit in the trunk, > after clearing the cache. That's the reason why I only do it for > official beta releases, and opam-builder takes two or three days to > compile the repo. What would it take to get, say, one full build every day? I think we could find some funds for that, e.g. from the Caml consortium. After all, a cool 12 cores / 24 threads blade server costs only 2.5 kEur or so. - Xavier Leroy _______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
