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 B117B7F890 for ; Tue, 25 Mar 2014 17:29:55 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=pra; client-ip=89.16.177.154; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=mailfrom; client-ip=89.16.177.154; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@dark.recoil.org) identity=helo; client-ip=89.16.177.154; receiver=mail3-smtp-sop.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: AuIDAFKuMVNZELGagGdsb2JhbABZg0GrHpgmgTEOAQELFAc+giUBAQEDATo0CwULC0ZXBhOHcQwJz00XjgwRAVAHgySBFASYTYEylC49gTU X-IPAS-Result: AuIDAFKuMVNZELGagGdsb2JhbABZg0GrHpgmgTEOAQELFAc+giUBAQEDATo0CwULC0ZXBhOHcQwJz00XjgwRAVAHgySBFASYTYEylC49gTU X-IronPort-AV: E=Sophos;i="4.97,728,1389740400"; d="scan'208";a="54078540" Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) ([89.16.177.154]) by mail3-smtp-sop.national.inria.fr with SMTP; 25 Mar 2014 17:29:55 +0100 Received: (qmail 27394 invoked by uid 634); 25 Mar 2014 16:29:54 -0000 X-Spam-Level: * X-Spam-Check-By: dark.recoil.org Received: from cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net (HELO [192.168.1.110]) (86.30.244.239) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Tue, 25 Mar 2014 16:29:53 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Anil Madhavapeddy In-Reply-To: <20140325161648.GG10374@annexia.org> Date: Tue, 25 Mar 2014 16:29:52 +0000 Cc: Goswin von Brederlow , caml-list@inria.fr Content-Transfer-Encoding: 7bit Message-Id: References: <20140321222842.GA10374@annexia.org> <4C341FFE-FDF2-4EA3-B056-D4F658641E4C@math.nagoya-u.ac.jp> <20140322071508.GB10374@annexia.org> <20140325154958.GA20202@frosties> <20140325161648.GG10374@annexia.org> To: "Richard W.M. Jones" X-Mailer: Apple Mail (2.1874) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Subject: Re: [Caml-list] Trivial compiler patches On 25 Mar 2014, at 16:16, Richard W.M. Jones wrote: > I have to say that a number of projects I've been involved with have > rejected github pulls as a method of working on patches. I think the > main reasons are: > > - A mailing list allows you to use your regular editor when > commenting. > > - A mailing list provides a text-based, open archive of historical > discussions of patches. These two are definitely useful, although it substantially increases the amount of incoming email for all developers (especially with large, repeated patchsets that are being iterated over). > - github pulls always(?) turn into merge commits, instead of a > linear history. Only if they're merged via the web interface. They can be rebased and pushed directly as usual from the command line. > - github is closed source Certainly a concern. > > - AFAIK github is not integrated into any CI system (compare, say, > Gerrit + Jenkins -- although Gerrit + Jenkins have their share of > problems as well). GitHub has fantastic CI support via Travis -- easily the best of anything I've used in the past, and particularly so because it's free and hosted elsewhere. See: http://anil.recoil.org/2013/09/30/travis-and-ocaml.html for an overview of getting started with it. In general, the GitHub API support makes it sufficiently easy to hook in third-party workflows that the OCaml GitHub mirror will continue to be useful even if Gabriel's experiment with pull requests doesn't work out. > Personally I don't think that patch review is anywhere close to being > a solved problem. It's an important area requiring much more > research! I spent a while trying these out for Real World OCaml, and noted that all of the existing tools only support *patch* review, but not general *code* review. Consider, for example, someone reading a book chapter, or the 4.01.0 x86_64 code generator and wanting to leave comments on the whole tree, not just on a specific isolated patch. An odd omission in the space, or I just missed an area of tooling that deals with this... -anil