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 C8D2381799 for ; Mon, 22 Jul 2013 15:51:50 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dave.scott@eu.citrix.com) identity=pra; client-ip=46.33.159.39; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="Dave.Scott@eu.citrix.com"; x-sender="dave.scott@eu.citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of Dave.Scott@eu.citrix.com designates 46.33.159.39 as permitted sender) identity=mailfrom; client-ip=46.33.159.39; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="Dave.Scott@eu.citrix.com"; x-sender="Dave.Scott@eu.citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@SMTP.EU.CITRIX.COM designates 46.33.159.39 as permitted sender) identity=helo; client-ip=46.33.159.39; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="Dave.Scott@eu.citrix.com"; x-sender="postmaster@SMTP.EU.CITRIX.COM"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoBAJ447VEuIZ8nnGdsb2JhbABagzsBwH+BDxYOAQEBAQEICwkJFCiCJAEBBAE4QAEQCyEWDwkDAgECAUUGDQEHAQGIBgoIt0sEkBYHg34DiHCVEI49Ow X-IPAS-Result: ApoBAJ447VEuIZ8nnGdsb2JhbABagzsBwH+BDxYOAQEBAQEICwkJFCiCJAEBBAE4QAEQCyEWDwkDAgECAUUGDQEHAQGIBgoIt0sEkBYHg34DiHCVEI49Ow X-IronPort-AV: E=Sophos;i="4.89,719,1367964000"; d="scan'208";a="21906556" Received: from smtp.eu.citrix.com ([46.33.159.39]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 22 Jul 2013 15:51:26 +0200 X-IronPort-AV: E=Sophos;i="4.89,719,1367971200"; d="scan'208";a="6944763" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Jul 2013 13:51:25 +0000 Received: from [10.80.239.111] (10.80.239.111) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Mon, 22 Jul 2013 14:51:24 +0100 Message-ID: <51ED38F5.2030705@eu.citrix.com> Date: Mon, 22 Jul 2013 14:51:49 +0100 From: David Scott User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Anil Madhavapeddy CC: Gerd Stolpmann , , References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> <7b4c87b5d9aa76728e239f0a2172b795.squirrel@gps.dynxs.de> <6796313D-9F02-4C70-87D9-8DC9BC896028@recoil.org> In-Reply-To: <6796313D-9F02-4C70-87D9-8DC9BC896028@recoil.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] opam and godi 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