From: Anil Madhavapeddy <anil@recoil.org>
To: "Richard W.M. Jones" <rich@annexia.org>
Cc: Goswin von Brederlow <goswin-v-b@web.de>, caml-list@inria.fr
Subject: Re: [Caml-list] Trivial compiler patches
Date: Tue, 25 Mar 2014 16:29:52 +0000 [thread overview]
Message-ID: <CBFDD06B-4834-425F-9756-83DC81545E7E@recoil.org> (raw)
In-Reply-To: <20140325161648.GG10374@annexia.org>
On 25 Mar 2014, at 16:16, Richard W.M. Jones <rich@annexia.org> 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
next prev parent reply other threads:[~2014-03-25 16:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-21 22:28 Richard W.M. Jones
2014-03-22 0:46 ` Jacques Garrigue
2014-03-22 7:15 ` Richard W.M. Jones
2014-03-22 8:28 ` Gabriel Scherer
2014-03-25 15:49 ` Goswin von Brederlow
2014-03-25 16:01 ` Daniel Bünzli
2014-03-25 16:16 ` Richard W.M. Jones
2014-03-25 16:29 ` Anil Madhavapeddy [this message]
2014-03-27 9:34 ` Goswin von Brederlow
2014-03-27 11:22 ` Anil Madhavapeddy
2014-03-27 11:28 ` Thomas Gazagnaire
2014-03-27 12:23 ` François Bobot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CBFDD06B-4834-425F-9756-83DC81545E7E@recoil.org \
--to=anil@recoil.org \
--cc=caml-list@inria.fr \
--cc=goswin-v-b@web.de \
--cc=rich@annexia.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).