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

Kevin Krammer krammer at kde.org
Sat Sep 19 20:32:24 UTC 2015


On Saturday, 2015-09-19, 22:11:10, Eike Hein wrote:
> On 09/19/2015 09:55 PM, Kevin Krammer wrote:
> > 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.
> 
> Except the pro-GitHub side specifically argues for
> GitHub as increasing the frequency of first patch
> submissions, so the total amount of work spent on
> dealing with them increases.

Yes, but those who argue for that are aware of the extra work that will cost.
Like Jaroslaw explained, he is fully aware of the extra work that this means, 
but he already has this extra work no matter which indirect submission forms 
he supports.

So in his experience it is worth it for him.

> This is on some level
> a "nice problem to have", but creates a pressure to
> drop two-stage review and use GitHub as a primary
> channel to optimize that channel.

I don't see there this github review is coming from.
A preliminary review on github is something the KDE contributor, who will then 
take the patch to KDE review, can do if they think it will make their review 
easier. Or to provide the patch author with confidence to do it themselves 
next time.

I would assume that in most case the patch from the first time contributor is 
just taken to KDE review and the author asked to submit directly next time.

Everything else is not "optimizing the channel", only direct submission to KDE 
review is optimal.

> I.e. once again
> leading me to the conclusion that two-stage review
> is simply not viable and runs counter to what the
> proposal wants to achieve.

Indeed. Somehow people bring up additional github review all the time. I doubt 
anyone would do that in practise.

> > Developers cooperating on a patch or patchset before review submission is
> > nothing new.
> 
> This sort of "we have a precedent for this" argument
> comes up a lot, but is often a really poor argument
> because it doesn't establish that precedent was
> actually a positive experience or a desirable
> situation.

I always found direct collaboration, e.g. at sprints, extremely desirable.
As a GSoC mentor I am also pretty confident that my students found our private 
reviews desirable, based on them asking for them.

Cheers,
Kevin
-- 
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/88558ffb/attachment.sig>


More information about the kde-community mailing list