From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 295E281799 for ; Tue, 23 Jul 2013 11:07:15 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of adrien@notk.org) identity=pra; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of adrien@notk.org designates 91.121.71.147 as permitted sender) identity=mailfrom; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@nautica.notk.org) identity=helo; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="postmaster@nautica.notk.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAJJG7lFbeUeT/2dsb2JhbABbgwaEDr0wgREWdIIkAQEEASNWBQsLDgoCAgUTDgICDwUYMSeHdgqmZZFpgSiNKB6BJQeCXTNuA5dcAZFNgxQ6gS4 X-IPAS-Result: AigFAJJG7lFbeUeT/2dsb2JhbABbgwaEDr0wgREWdIIkAQEEASNWBQsLDgoCAgUTDgICDwUYMSeHdgqmZZFpgSiNKB6BJQeCXTNuA5dcAZFNgxQ6gS4 X-IronPort-AV: E=Sophos;i="4.89,726,1367964000"; d="scan'208";a="21984207" Received: from nautica.notk.org ([91.121.71.147]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 23 Jul 2013 11:07:14 +0200 Received: by nautica.notk.org (Postfix, from userid 1003) id 80764C009; Tue, 23 Jul 2013 11:07:13 +0200 (CEST) Date: Tue, 23 Jul 2013 11:07:13 +0200 From: Adrien Nader To: Gerd Stolpmann Cc: caml-list@inria.fr, godi-list@ocaml-programming.de Message-ID: <20130723090713.GA9274@notk.org> References: <1e141e2803d9dec6a8231dd4f16dd173.squirrel@gps.dynxs.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1e141e2803d9dec6a8231dd4f16dd173.squirrel@gps.dynxs.de> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Caml-list] GODI is shutting down Hi, On Mon, Jul 22, 2013, Gerd Stolpmann wrote: > Dear subscriber, > > Unfortunately, it is no longer possible for me to run the GODI > distribution. GODI will not upgrade to OCaml 4.01 once it is out, and it > will shut down the public service in the course of September 2013. The > website, camlcity.org, will remain up, but with reduced content. Existing > GODI installations can be continued to be used, but upgrades or bugfixes > will not be available when GODI is off. > > Although there are still a lot of GODI users, it is unavoidable to shut > GODI down due to lack of supporters, especially package developers. I was > more or less alone in the past months, and my time contingent will not > allow it to do the upgrade to OCaml 4.01 alone (when it is released). It is very sad to hear that. I was expecting some clashes for the past few months so I'm not completely surprised. I've been meaning to do more for godi but I've been completely unable to do so unfortunately and I'm sorry for that. > Also, there was a lot of noise about a competing packaging system for > OCaml in the past weeks: OPAM. Apparently, it got a lot of attention both > from individuals and from organizations. As I see it, the OCaml community > is too small to support two systems, and so in some sense GODI is > displaced by OPAM. I believe that this is the same as with LLVM and GCC. Two years ago, llvm was supposed to beat GCC within a year: performance of the generated code was increasing very quickly. It was a new software, not hampered by decades of development, and the rule of 80/20 struck. It was fairly obvious that the rate of improvements would slow down and that people would start asking for more stability and compatibility (to this day, llvm still doesn't have minor releases). It must have been hell for GCC people back then. Noone cared that they were more compatible (for hosts, targets, options and combinations of these), more stable, generated faster code, had been around for decades, ... > The sad part is that OPAM is only clearly better in one point, namely in > interacting with the community (via Github). In times where social > networks are worth billions this is probably the striking point. It > doesn't matter that OPAM lacks core functions like deleting all files when > a package is removed, and that it lacks many other features GODI has. So > there is some loss of functionality for the community (partly difficult to > replace, like GODI's support for Windows). To be honest, I've never understood why opam was "started". I believe the time would have been much better spent improving godi. I've heard complaints against the UI and the package release process of godi. How can such complaints about the UI be a reason to start a new project?! Couldn't the package release process be improved gradually? As for github, I concur its best feature is the "social" thing. And sometimes it gets in the way: you can see people who've forked your repo and their commits easily. But for other things, cgit is way better and clearer. Sure, it doesn't have a shiny CSS. On the other hand, it doesn't put flash objects in webpages like github. > If somebody wants to take over GODI, please do so. The source code is > still available as well as the package directories. Maybe it is sufficient > to move the repository to a public place and to redesign the package > release process to give GODI a restart. You haven't only written the code but you've also setup a whole infrastructure. Would you mind trying to pass it over or migrate it, maybe not leaving completely but letting others do some of the annoying admin-related tasks? > There is also another point that was driving me mad in the past weeks, > namely missing respect from the OPAM guys. Given the fact that OPAM is > only a thin layer around ocamlfind (and guess who wrote it), and given the > fact that GODI was pioneering in many fields, I was expecting nicer > wordings, and less dumb campaigning ("we have 400 packages, and you only > 170"). OPAM is only harvesting what I seeded many years ago. I tend to agree here. Something like 5 years ago, management of OCaml library was a real pain. Ocamlfind support was everything but universal (I remember when ocamlfind-enabled build systems where the minority and I found them annoying). I believe godi really helped with that but it also had to support build systems not using ocamlfind and that made some godi packages more complicated. The people involved in OPAM have clearly been more vocal and I'm definitely not going to blame them for that: if you build a new project but don't advertise it, noone will use it. Some of the messages were probably lacking some tact however. As far as I'm concerned, I don't want to use OPAM. I've been happy with GODI and would really like to continue to use it. I do not want to use a high-speed source-based rolling-release system and I believe that it is bad, especially for beginners who need a stable environment. I've been very irritated by pieces of advice for beginners that mentionned using svn branches of the OCaml compiler. OPAM makes it easy; great! It's still an unreleased version that is still in development. Generally speaking, I find the use of bleeding-edge software bad. It might be good OCaml libraries that are well-tested but it doesn't matter: you're going to get into troubles sooner or later. I'm not advocating waiting for years for things to settle but vim $package, :%s/0.14/0.15/g, :wq, git commit -a -m 'foo: Update to 0.15.', git push might be too quick. I also believe "pinning" is a bad idea in general: it picks bits and pieces of software from different timeframes. It will work for exceptional cases but otherwise you end up with an exponential explosion of combinations of versions that haven't been tested together. There could be a git branch or a git repo for stable stuff along with the development tree. Citrix already does that and others already do that too. Which means that there are several parallel distributions and that has its drawbacks too. Obviously, all of these can be fixed or improved, through code, process and probably better: a combination of both. However, currently, there are still open issues. I've lacked time recently and I'm still using godi with 3.12.1. And I can still update it and it works as well as the 4.00 branch. I doubt that I could get the same with OPAM (had it started with 3.12). -- Adrien Nader