[m-rev.] Handling pull requests

Julien Fischer jfischer at opturion.com
Mon Jan 7 12:31:52 AEDT 2013


On Mon, Jan 7, 2013 at 12:15 PM, Julien Fischer <jfischer at opturion.com> wrote:
> On Mon, Jan 7, 2013 at 12:09 PM, Peter Wang <novalazy at gmail.com> wrote:
>> On Mon, 7 Jan 2013 11:39:12 +1100, Julien Fischer <jfischer at opturion.com> wrote:
>>> On Mon, Jan 7, 2013 at 11:14 AM, Paul Bone <paul at bone.id.au> wrote:
>>>
>>> > I think the bit that needs discussion is how we do code reviews now that
>>> > we're using git and github.  What I'd like to acheive here is a way that any
>>> > of us can do code reviews, with any tools we like (eg vim and diff/patch or
>>> > github or git & vim).  And that the process should be simple regardless of
>>> > which tools we want to use.  Eg: I do not want to "force" github usage onto
>>> > anyone.
>>>
>>> The existing process, i.e. send the log message + patch to the mailing list,
>>> is fine IMO.
>>
>> Agreed.  That pull request emails don't contain the diff is a huge step
>> backwards.  Email + vim is better than any web interface.
>>
>> Non-core developers may prefer to send pull requests, but their changes
>> won't likely be very big anyway so not much to review.
>
> That's fine.  One of us can post the diffs corresponding to the pull
> request to the
> list.  (Most of the pull requests I've seen so far certainly require
> some discussion.)

For instance, Michael Richter's README.bootstrap change, that Paul
just committed
is wrong in number of respects and *should* have been reviewed before
it was commited.
(For example, configuring the bootstrap compiler with
--enable-libgrades=asm_fast.gc
will result in a broken installation on Mac OS X; the correct option
to use would be
--disable-most-grades.)

Cheers,
Julien.



More information about the reviews mailing list