caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: "Richard W.M. Jones" <rich@annexia.org>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Trivial compiler patches
Date: Thu, 27 Mar 2014 10:34:21 +0100	[thread overview]
Message-ID: <20140327093420.GA19960@frosties> (raw)
In-Reply-To: <20140325161648.GG10374@annexia.org>

On Tue, Mar 25, 2014 at 04:16:48PM +0000, 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.

And makes it hard to follow or later trace the developement due to the
amount of intermixed mails.

Rebasing a patch set for every change also makes it hard to follow
since rebase destroys history. So far revision control systems lack
that extra dimension needed to track the developement of a patch set
over time.

So overall there is no ideal solution yet. As you say below it is
still an unsolved problem.

>  - github pulls always(?) turn into merge commits, instead of a
>    linear history.

That happens when you merge pull requests via the web interface. You
don't have to.

Also does that realy hold true if the pull request is based on the
HEAD of the main branch and only has one commit (only one patch in the
set)? That would create a merge with 2 parents that are both the same.
 
>  - github is closed source

I don't mind. It is free as in beer, it works and it doesn't poison
your project (no lock in). You can always just use plain git at any
time, which is free.
 
>  - AFAIK github is not integrated into any CI system (compare, say,
>    Gerrit + Jenkins -- although Gerrit + Jenkins have their share of
>    problems as well).
> 
> Now this is not to say that github will not work well for the OCaml
> community.
> 
> 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!
> 
> Rich.

Maybe once it is solved someone will implement a nice free platform
for it. Till then lets see what other people come up with, free or not.

MfG
	Goswin

  parent reply	other threads:[~2014-03-27  9:34 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
2014-03-27  9:34           ` Goswin von Brederlow [this message]
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=20140327093420.GA19960@frosties \
    --to=goswin-v-b@web.de \
    --cc=caml-list@inria.fr \
    --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).