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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 7E3B081799 for ; Mon, 22 Jul 2013 15:30:53 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=pra; client-ip=89.16.177.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=mailfrom; client-ip=89.16.177.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@dark.recoil.org) identity=helo; client-ip=89.16.177.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="postmaster@dark.recoil.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8GAPYy7VFZELGadGdsb2JhbABagzutRZM7gSQOAQwVCDyCJAEBBAE6PwULC0ZXBhOICgYECLc6BI5lgTEHgxBuA5ddlGCBZyQ X-IPAS-Result: Am8GAPYy7VFZELGadGdsb2JhbABagzutRZM7gSQOAQwVCDyCJAEBBAE6PwULC0ZXBhOICgYECLc6BI5lgTEHgxBuA5ddlGCBZyQ X-IronPort-AV: E=Sophos;i="4.89,719,1367964000"; d="scan'208";a="26882522" Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) ([89.16.177.154]) by mail2-smtp-roc.national.inria.fr with SMTP; 22 Jul 2013 15:30:53 +0200 Received: (qmail 19480 invoked by uid 634); 22 Jul 2013 13:30:53 -0000 X-Spam-Level: * X-Spam-Check-By: dark.recoil.org Received: from volstagg-0.srg.cl.cam.ac.uk (HELO clink-4.office) (128.232.32.232) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Mon, 22 Jul 2013 14:30:52 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Anil Madhavapeddy In-Reply-To: <20130722074459.GA10640@notk.org> Date: Mon, 22 Jul 2013 14:30:51 +0100 Cc: caml-list@inria.fr, "opam-devel@lists.ocaml.org" Content-Transfer-Encoding: 7bit Message-Id: <66667E06-8E92-4CB8-BF59-578E1E961AC0@recoil.org> References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> <7b4c87b5d9aa76728e239f0a2172b795.squirrel@gps.dynxs.de> <6796313D-9F02-4C70-87D9-8DC9BC896028@recoil.org> <20130722074459.GA10640@notk.org> To: Adrien Nader X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Subject: Re: [Caml-list] opam and godi On 22 Jul 2013, at 08:44, Adrien Nader wrote: > In the end, maybe you have: > - godi, slower package updates but usually more stable; bugs in packages > are less common but when they exist, they can also take time to fix > - opam, many more updates, maybe too many, packages get less testing > before they reach others (if you want new software, you can't have a > week of testing between each release) > > NB: don't get me wrong, I don't blame any package maintainer or package > on slow updates or bugs: many issues arise when software is used on 10 > different setups (different CPUs, different OS, ....) This is absolutely true. I've been assembling a little machine pool of 'exotic architectures' that make it easier to test all the various permutations. OPAM has a vestigial autobuilder now that runs through a bunch of different platforms. For a *temporary* URL with our development version, see: https://ocaml-www3.ocamllabs.cl.cam.ac.uk/github/OCamlPro/opam-repository Once the teething issues are sorted, David Sheets has also written Github bindings so that work will be queued up directly from a Github pull request. Anyone submitting a report can have their package tested on systems they don't normally have access to. This will in turn let us do acceptance tests before merging pull requests into the 'stable' OPAM repository. I really like the Git workflow behind all this. It basically reflects how we work with OCaml in an industrial setting: pool up a sequence of local changes (across multiple repositories), publish them to an internal OPAM remote, and then issue pull requests upstream until you hit the central stable repository. At no point do you have to block waiting for someone else to do something for you, unless it's the default central repository that Thomas and I monitor. I'm also very pleased to announce that Rackspace (who use OCaml via the Xen Cloud toolstack) have recently donated a significant number of VMs to power all the builds behind this. We can use this infrastructure to securely run unit tests: we just need to set up a "gold image" VM with the build, unplugging its external network interface, run the test, and then replug it back into the network. All via HTTP interfaces, with feedback sent back to the package maintainer via the Github pull request interface. -anil (PS: for those concerned about an over-dependence on Github, I'm currently evaluating Gitlab, which Jeremy Yallop pointed out to me -- it seems a good candidate to mirror all this activity somewhere else, while still using Github as a primary source).