[kde-community] What is a GitHub pull request exactly?

[Kevin Krammer]

On Saturday, 2015-09-19, 20:56:31, Eike Hein wrote:
> On 09/19/2015 08:43 PM, Kevin Krammer wrote:
> > Well, the github side review will make the job of the KDE contributor who
> > brings the patch into KDE a lot easier, because when they put the patch up
> > for review as "their" contribution, most of the things that the
> > contributor knew about will already have been fixed.
> 
> No, it won't make it easier. It will busy up KDE contributors
> with process snags instead of actual work - now they don't
> just have to review, they also have to file requests for work
> not their own. It makes stepping up to becoming a regular
> contributor less desirable, because it means taking on duties
> like this.

I didn't mean easier than when the author of a patch initiated the actual 
review themselves.
Of course doing only the actual review that counts is a lot easier than doing 
a preliminary one and then doing the actual one, but sometimes doing a 
preliminary one is a nice gesture [1].

Since the goal of any established contributor will be to get the new 
contributor to work on their own as soon as possible, they will not likely do 
that proxying for long.

> The purpose of code review tools is to facilitate review by
> making the process sufficiently tenable. Chaining two of them
> and creating additional work items does not aid in that
> purpose.

Exactly.
So why would one continue to do the prelimiary review in addition to the 
required one?
As soon as there is a stream of patches from a new contributor, that 
contributor will be asked to get an account of their own.
Need for preliminary review or patch proxying removed, ideal situation 
established.

> It'll also create social tensions of various kinds:
> 
> * Developers not participating in GitHub review and only
>   seeing a patch once it makes it to Phab will feel
>   pressured to accept something because part of the
>   discussion has already happened elsewhere, vastly in-
>   creasing the conviction required to don the cap and
>   baton of the Bad Cop at that point.

Developers cooperating on a patch or patchset before review submission is 
nothing new.

> * Developers will have opinions on whether it's OK for
>   other developers to tell requestees to use Phab next
>   time.

I am afraid I didn't get that one.

> Really, the only way we can enable GitHub for code
> review is if we can work up a community consensus
> that it will a full alternative to Phan because it's
> worth it to us.

I don't think this would be a good idea.
The only review that counts in the end is the one all KDE developers have 
access to. Which is Phab.

Using any other tool before review submission is a developer's personal 
choice. If it helps them to gather confidence for the review, why not.
See also [1].

Cheers,
Kevin

[1] I've done plenty of these with new contributors, e.g. GSoC students, so 
they can fix "embarrasing" things with only me seeing them and providing an 
already improved version for general review.

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20150919/ef00ebb2/attachment.sig>