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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 9D29D7EEAF for ; Tue, 22 Jan 2013 19:03:32 +0100 (CET) Received-SPF: None (mail1-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=mail1-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail1-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=mail1-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail1-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=mail1-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: Av4BAHfT/lBZELGagWdsb2JhbABEvj0OAQEWJieCHgEBBAFuCwULCxgMIlcGE4gTCq0JkCiMfg8Bg0dhA5JaA4Mvkz6Bbw X-IronPort-AV: E=Sophos;i="4.84,515,1355094000"; d="scan'208";a="191157899" Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) ([89.16.177.154]) by mail1-smtp-roc.national.inria.fr with SMTP; 22 Jan 2013 19:03:31 +0100 Received: (qmail 29052 invoked by uid 634); 22 Jan 2013 18:03:30 -0000 X-Spam-Level: * X-Spam-Check-By: dark.recoil.org Received: from volstagg-0.srg.cl.cam.ac.uk (HELO [10.0.0.83]) (128.232.32.232) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Tue, 22 Jan 2013 18:03:29 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Anil Madhavapeddy In-Reply-To: <50FEBFD4.9080004@frisch.fr> Date: Tue, 22 Jan 2013 18:03:21 +0000 Cc: =?iso-8859-1?Q?Daniel_B=FCnzli?= , Mirage List , Thomas Gazagnaire , OCaml mailing-list , Philippe Veber Content-Transfer-Encoding: quoted-printable Message-Id: References: <6833F17C-B642-4ED9-8C8F-2665A9742845@ocamlpro.com> <50F831B6.6020404@frisch.fr> <224865B3-055C-4E03-AA42-9F962AD516D7@recoil.org> <50F92486.2020704@frisch.fr> <50F92FA9.8050707@frisch.fr> <28252449-E0B3-4A0E-A001-57B72712DD99@recoil.org> <4144589AC12E46C09674D6D80D984289@erratique.ch> <50FEBFD4.9080004@frisch.fr> To: Alain Frisch X-Mailer: Apple Mail (2.1499) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Subject: Re: Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM) On 22 Jan 2013, at 16:35, Alain Frisch wrote: > On 01/19/2013 11:40 AM, Daniel B=FCnzli wrote: >> Yes, I know, that was not the point. I was proposing a lighter process f= or a package to be included in opam's default repository. >>=20 >> As Alain mentioned, the current process is rather involved for package d= evelopers --- but I disagree with his idea of an upload web interface. >>=20 >> The idea is that package developers publish repos with their work >=20 > Concretely, I guess that publish a repo means setting up a server somewhe= re. I don't think that everyone can easily do that or want to invest so mu= ch effort only to submit a single package. >=20 > What's the benefit of the git/github submission workflow? I don't immedi= ately see how this is easier for people responsible of accepting/rejection = packages than, say, something based on an upload interface (or even simpler= , an email with an attachment). Let's think through what an e-mail workflow might look like rather than jus= t throwing it out as a superior alternative to what we use now. Let's say = it goes to an e-mail list, with a few people subscribed to it. Then, someo= ne adding the package would reply to the list saying that they'll handle it= , and have to deal with it immediately and not get distracted. Next, we ha= ve to convert the package into a Git commit with the submitter's name, so t= hat we have a reasonable package history. Finally, we need a queue of pack= ages to track which ones haven't been replied to, or else risk forgetting p= ackages. And of course, anyone who wants to be involved has to subscribe t= o a mailing list, and the only way to find past submissions is by digging t= hrough e-mail archives. Git/Github takes care of all this, to the point where a merge is a single b= utton on the website. Specifically, it: - track provenance of updates (so we can go contact whoever introduced a pa= ckage reliably, assuming their Github ID doesn't change). - lets people maintain private branches outside of Github, and easily merge= against upstream updates. Citrix are doing this for their internal reposi= tories, which they re-base against OPAM upstream, and then regularly submit= their packages to the mainline once they're tested. I also do this with M= irage. - a public tracking system with comments to ensure packages don't get lost.= I don't particularly fancy having my mailbox fill up with mailed tar-balls. - an easy-to-use API that lets us run continuous build directly off Github.= I think of this as "Internet threads". A callback from Github wakes up an= Lwt thread to do some work on the continuous build server. That's kind of = cool :-) It should be really trivial to build a package uploader using the OPAM exte= nsion mechanism I described earlier, and the ocaml-github bindings. If anyo= ne wants to help add this, get in touch with me and I'll walk you through i= t. My plate's a bit too full to get to this in the near-term. -anil=