Re: Reviews on mailing-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Nov 11, 2012 at 2:09 PM, Thiago Farina <tfransosi@xxxxxxxxx> wrote:
> On Sun, Nov 11, 2012 at 10:14 AM, Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
>> Requiring everyone to use a web browser would limit the amount of ways
>> people can review patches.
> I don't see that as a limitation as I think everyone has access to a
> web browser these days, don't have?
>
>>> How come that can
>>> be an impediment to move forward way of this awkward way of reviewing
>>> patches through email?
>>
>> It's not awkward, it's the most sensible way.
>>
> The most harder way I think?
>
> Look at this:
> https://gerrit.chromium.org/gerrit/#/q/status:open+project:chromiumos/platform/power_manager,n,z
>
> There I can go and see many informations that through this mailing
> list I can't or have to do much more work in order to archive this.

That information has nothing to do with reviews. That's patch state-tracking.

> If you open one of the 'patches' you can see some relevant information:
> - Who is the owner/author
> - Was it verified?
> - Is it ready for landing?

Irrelevant for git.

> - If I click on Side-by-side I get a nice diff view interface that
> plan text email does NOT give me.

Not useful.

> - Was it reviewed/approved (+1, +2)?

You can see the same in a mail thread.

> - It can be merged by one click.

Irrelevant for git.

> - The interface also provide the command line to download/apply the
> patch for me.

Not useful.

> - Isn't there a reason (implicit there) for Google being using tools
> like Gerrit/CodeReview(rietveld)/Mondrian for handling his code
> reviews rather than solely by 'email'?

Who knows And if there is, who knows if it's valid.

And none of those points has anything to do with code *review*.

All these points are about state-tracking, and that can be implemented
*on top* of the mailing list, for example through patchwork:

http://patchwork.newartisans.com/patch/1531/

That's if somebody actually cared about that, but that doesn't seem to
be the case.

>> You just replied to my mail the same way I would reply to a patch.
>>
> I replied through a web browser by the Gmail interface. ;)

Indeed, Gmail is one of the many ways you can review a patch.

You clik reply, you add the comments in line, and click send. Couldn't
be easier.

>>> There are a lot of issues of having to use email for reviewing patches
>>> that I think Gerrit is a superior alternative.
>>
>> There are no issues. It works for Linux, qemu, libav, ffmpeg, git, and
>> many other projects.
>>
>>> And many people are arguing for it!
>>
>> Nope, they are not.
>>
> If they weren't then nobody would be suggesting to use Gerrit for
> handling the review of git patches.

Except you, of course.

> But I think the big resistance comes from the fact that the core
> developers handle/review the git patches through Gnus/Emacs, so that
> is enough for them and they don't want to make the switch because of
> that?

gnus/emacs/notmuch/thunderbird/Gmail, and pretty much every mail
client out there.

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]