From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id B39A6BC6C for ; Tue, 29 Jan 2008 14:45:02 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOi8nkfAXQInh2dsb2JhbACBWI5GAQEBCAopgRScQgE X-IronPort-AV: E=Sophos;i="4.25,269,1199660400"; d="scan'208";a="6698652" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 29 Jan 2008 14:45:02 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0TDiodX016454 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 29 Jan 2008 14:45:02 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOi8nkfU4367nmdsb2JhbACBWI5GAQEBAQEGBAYpgRScQgE X-IronPort-AV: E=Sophos;i="4.25,269,1199660400"; d="scan'208";a="6698650" Received: from moutng.kundenserver.de ([212.227.126.187]) by mail2-smtp-roc.national.inria.fr with ESMTP; 29 Jan 2008 14:45:01 +0100 Received: from gate.lan.gerd-stolpmann.de (dslb-084-059-121-246.pools.arcor-ip.net [84.59.121.246]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1JJqll3TYo-0002zw; Tue, 29 Jan 2008 14:44:58 +0100 Received: from [192.168.0.32] (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id 5D0EBC110; Tue, 29 Jan 2008 14:44:57 +0100 (CET) Subject: Re: [Caml-list] Re: The OCaml Community (aka back from the Developer Days) From: Gerd Stolpmann To: Markus Mottl Cc: ocaml , ocaml-users@janestcapital.com In-Reply-To: References: <1201439362.6302.15.camel@Blefuscu> <1201480729.479d2419c2f08@webmail.in-berlin.de> <1201519661.6747.27.camel@Blefuscu> <479E050B.3010306@fmf.uni-lj.si> Content-Type: text/plain Date: Tue, 29 Jan 2008 14:45:00 +0100 Message-Id: <1201614300.24248.23.camel@flake.lan.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+qumPZG9fk7/6R8QhzLqwidEJqz6/JBha4TXE SuVa0S6GqCJxyi5bTlnC4b8JBbc+amqqIVGK2zi/LwU+C8AFjO Ax7Bir/3HFgbgPbZixXXDnkO6JeZYJ3 X-Miltered: at concorde with ID 479F2DD2.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 markus:01 gerd:01 markus:01 mottl:01 ocamlfind:01 ocaml:01 tarball:01 recompile:01 c-library:01 dependencies:01 rebuilt:01 dependencies:01 Dear Markus, I'm a bit speechless, and admit I have really problems formulating an appropriate response. I know that companies tend to separate themselves from others, since they are finally only a group of people sitting together and working on their own agenda. So the discussion within companies usually has a lot of specifics which cannot be understood from the outside. Nevertheless it is sometimes important to recall some facts that might have been overlooked in the company-internal discussion. 1. GODI is meant as an effort to bundle the activities of the community. It is not a commercial offer, and there is no customer support complaints can be directed at. If you want to improve it, the only way is to spend time and energy, and to enter a constructive discussion on godi-list. It is a pity that nobody at Jane Street wants to do this. 2. As I'm the guy who mainly developed the core of GODI I can tell you that every hour I work on GODI is an hour I cannot work for one of my customers. So GODI produces opportunity costs for me. From that point of view I cannot understand a (probably) rich company that profited from this project for free, and is unwilling to share some of the costs. There is an economy behind free software, and Jane Street seems not to have understood it. 3. Jane Street announced several times that they wanted to release software into the OSS world. Nothing happened. From that experience I think your "new approach" is also nothing but vaporware. Sorry for the direct language, but you provoked it. It is a pity to lose Jane Street as supporter of GODI. If you still want to enter into a constructive dialog, I'm open to it. Gerd Am Montag, den 28.01.2008, 19:26 -0500 schrieb Markus Mottl: > Since there were quite a lot of positive comments about Godi lately, I > think it is also necessary to point out some of its significant > drawbacks. We (Jane Street Capital) have been using Godi internally > for quite a while, and I have to admit that we are less than thrilled > by it and are planning to phase it out from our development > environment. Following is a short description of what seem to be the > major problems. > > Users of package management systems usually fall into one (or more) of > these roles: > > * Software developers > * Package maintainers > * Installation administrators > * Package users > > In our experience the only role that is sufficiently well-supported by > Godi is the one of the package user. It essentially boils down to > using ocamlfind, which works fine for that purpose. The majority of > OCaml users belongs to this group most of the time, which probably > explains why Godi caught on so well. > > However, the other roles are much worse off. It seems one design > decision of Godi was to separate software developers and package > maintainers. In practice, however, package maintainers are usually > also the developers, and they are most often also package users. If I > want to roll out and work with an updated Godi-package, I have to jump > through several hoops before I can do so: upload my updated tarball to > my webserver, update the package metadata in the Godi SVN-repository, > point my browser to the Godi website to update the Godi distribution, > go to my local Godi-installation, update and recompile the package, > and finally, when I try to use it, I may find out that I had made a > mistake somewhere and have to start all over. The build system used > by Godi, which is based on NetBSD's package management, is arcane to > say the least. I still don't quite understand how to e.g. correctly > make packages check for C-library dependencies, etc. > > Administrating a Godi installation is no easy task either. The user > interface seems quite cumbersome and hard to use. Furthermore, it is > not easy to integrate libraries that are not in Godi (as packages). > They need to be rebuilt, too, when their dependencies get updated, but > automating this task is essentially only possible by jumping through > the hoops of making packages and becoming their maintainer. A task > that many would rather not take over and hardly makes sense if there > is no intention to release such packages to the general public in the > first place. > > The question now is how to solve these issues, and it's clear that > this would require a fairly significant development effort. > > As a software developer and package maintainer, I'd ideally like to be > able to work on a source tree containing the complete code of all > packages (and their dependencies), make changes wherever I want (fix > bugs, add features, add new libraries, etc.), share patches or full > versions with other maintainers, and all of this with a minimum amount > of overhead. Since Godi only tracks dependencies between packages, it > is not possible to just update code and let the build system figure > out what needs to be recompiled. One needs to build new packages > instead, which is way too much effort. As installation administrator > I'd like to be able to use a straightforward user interface and easily > add 3rd party libraries without having to manually make sure that > dependencies are not violated. > > It is still a point of discussion at our company how to replace Godi, > and also how we could find a solution that would integrate well with > the OCaml-community. We have developed a fair amount of > infrastructure to improve our team productivity (we have around 20 > full time developers now working in three different locations) by > lowering turnaround times associated with code changes. The use of > distributed version control, compile daemons and omake has made it > very easy for us to share code that is guaranteed to compile and > allows making modifications quickly with a minimum amount of time > required for recompilations. > > It seems likely that focusing on a high degree of standardization > around the usage of software development tools (which version control > to use, how to guarantee compilability, what build tools to use, > standards enforcing easy combination and modularity of build > processes) would lower development barriers and thus boost the > productivity of the OCaml community. But it seems rather unlikely to > most of us that Godi will be a suitable foundation for moving forward. > We greatly appreciate Gerd's tireless efforts to contribute tools > like Godi, which is a lot of hard work that nobody else wanted to do > before. We have certainly benefited from it in the past and hope that > a new approach will alleviate the problems that Godi-developers often > run into. > > Best regards, > Markus > -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------