Re: [Caml-list] GODI is shutting down

[Anil Madhavapeddy <anil@recoil.org>]

On 24 Jul 2013, at 15:06, Virgile Prevosto <virgile.prevosto@m4x.org> wrote:
> 
>> project from the beginning. Basically, three organizations joined to  
>> create a new software. The discussion about the design wasn't public.
>> I was excluded from the beginning - and don't understand why, since
>> I made an offer for cooperation when I first heard from Ocamlpro's
>> plans (not about OPAM in particular, but other stuff, but I suggested
>> to cooperate in package manager questions). I never got a response to
> 
> Presented as above, it can be summarized as "opam developers
> arbitrarily refused a cooperation offer". As a potential package
> maintainer, hearing this has an impact on my motivation to devote too
> much time to it. I would thus be quite interested to see the other side
> of this coin.

Luckily, the OPAM bug tracking speaks for itself.  As the first 'user' of
OPAM, I found it incredibly easy to work with the team.  Just inspect the
issues in reverse order and read the discussions if you want to re-live
the early, exciting days of OPAM (spoiler: they weren't very exciting).
https://github.com/OCamlPro/opam/issues?direction=asc&page=1&sort=created&state=closed

The "discussion about the design wasn't public" verges on being a farcical
statement. The design document was detailed from day 1, and Thomas kept it
updated after every major change.  Don't believe me?  Run:

$ cd opam.git
$ git log --follow doc/dev-manual/dev-manual.tex

The actual discussions of the design were very user-driven, as seen in
the issues I linked earlier, and the Mirage list which adopted OPAM early:
http://www.openmirage.org/blog/breaking-up-is-easy-with-opam 
(back then, we needed some pretty nasty compiler hacks to bootstrap
various low-level libraries, and OPAM switches did the trick nicely,
along with the remote pinning support).

Gerd persists in dismissing my "Git-workflow" point as "the most harmless
variant". What he doesn't seem to realise is that version control workflow
dominates how many industrial users interact with and fix bugs in complex
applications based on OCaml. When I coordinated the Xen repositories, I had
over 300 active repos and branches to represent all the codeflow, and today
there are around 80 OCaml repositories and libraries in Xen Cloud alone.
Jane Street publish around 40 repositories, and Mirage has around 30.

The only reason I was interested in OPAM in the beginning was this feature,
with the rest just being icing on the cake.  On the other hand, when this 
was pointed out to Gerd in 2008, his reaction was to remove Core from GODI
for QA reasons.
http://caml.inria.fr/pub/ml-archives/caml-list/2008/01/f2a634e3ce1d93a047a55316acd08b77.en.html

That's really not a helpful response. I still remember the ICFP OCaml
tutorial that Yaron and I did in 2011 with some embarrassment. It took
almost 2 hours for participants to get OCaml and libraries installed and
working.  In 2012, when we re-ran the tutorial with a very alpha version
of OPAM, it took around 30 minutes (mainly waiting for compiler builds to
finish). This year, I expect it to be a non-issue.  The year after, users
should have binaries packages to make it near-instant.

That's progress of the good kind.  Time for a group hug!

-anil