[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