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

[Kevin Krammer]

On Saturday, 2015-09-19, 18:44:24, Martin Graesslin wrote:
> On Saturday, September 19, 2015 6:40:47 PM CEST Kevin Krammer wrote:
> > On Saturday, 2015-09-19, 17:47:38, Martin Graesslin wrote:
> > > On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> > > > If the problem is somewhere in (a), where is it?
> > > 
> > > I'm afraid of code review happening through the pull request instead of
> > > our
> > > infrastructure. To me github pull requests are not just the "here's the
> > > patch", but also the code review.
> > 
> > But wouldn't that be just additional code review?
> > 
> > Either on top of no code review or on before actual code review for
> > projects that require it?
> 
> do you really think that it would be reviewed again on KDE code review after
> it has gone through github review?

If it has gone through peer review or github review or if two developers were 
doing pair programming, a project that requires pre-push review will still 
need that patch to go through reviewboard/phabricator.

git enables tons of ways developers can cooperate on a patchset without 
involving the official repository, the review process is to get feedback from 
developers who have not been part of the patch development.

We don't enforce review by technical means but we still all do it when we know 
a project requires it.

We also deal with pre-review developer cooperation all the time:
- people sitting in the same office or working for the same company
- people attending the same sprint
- people using a "private" review request
- people working together on a branch
- people working together on a personal clone

Yet, I'd say that in a significant majority of cases the rest of the community 
is still be asked for input via a review request of the collaboration result.

> How would that process look like? Maintainer playing proxy by passing back
> the requested changes to the github developer?

I doubt that.
The developer taking over the patch would be the one modifying it.
Like then they receive the patch via email.

Which should be enough burden to not do it for prolonged periods of time, at 
some point the developer in question will ask the new contributor to get a KDE 
account and do that work themselves.

> No reality would be that it slowly moves code review from KDE to github. And
> I think we have here quite some people in the discussion who would love to
> see that :-(

I am afraid my understanding of the technical background of this is still too 
hazy.
How would review "move" from KDE to github?
If review on reviewboard is required (per project's unwritten social 
contract), it cannot not happen.
If it is not required, better have a patch reviewed elsewhere than not at all.

Are you suggesting we switch to a technically enforced review system, like Qt?

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/42eb7327/attachment.sig>