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

[Kevin Krammer]

On Saturday, 2015-09-19, 12:06:18, Michael Pyne wrote:
> On Sat, September 19, 2015 17:32:33 Kevin Krammer wrote:
> > So (a) and (b) workflows differ in that in (a) github mirror and
> > git.kde.org have the same state, while in (b) the mirror is for a period
> > of time not actually a mirror, but "ahead".
> > 
> > Where "ahead" could also mean wrong if "klmn" needs to be modified or gets
> > rejected.
> > 
> > Is (b) the problem people keep discussing about?
> 
> Kevin, first off thanks for taking all the time to diagram this in an email!

:-)
Since I haven't had to deal with these pull requests in any form yet, I wasn't 
sure I understood the implications.

Git is already highly distributed, each developer has a full clone of whatever 
repository they work on and already have options of sharing "remotes".

A clone on github is, as far as I understand, just a publically visible 
"remote" of one developer's state of the repository.

And a pull request is just a formal notification that a certain commit, patch 
set or branch could be interesting for upstream.

> I think some of us are seeing this as simply an administrative or technical
> discussion of how we merge changes into git.kde.org in the presence of
> Github. I don't think it's really that at all, but instead a question of
> "where is the development happening" and "how is KDE [the community]
> staying involved/up-to- date with that development"?

Yes, good point. I just wanted to make sure I have the techical aspects sorted 
out correctly before making predictions or assumptions based on 
misunderstanding of how things work.

> So I understand that from the perspective of "I already take patches by
> email, this is just another way of accepting new patches" this whole
> discussion might seem incredibly overdone. But there's another perspective
> of "how do we [KDE] ensure that our community values around common
> development are still maintained?", and that is the perspective from which
> many of us have questions.

For that is mostly an artifact of git, only a non-distributed VCS can 
"enforce" centralized development.

> If the whole question were just a matter of s/emailed patch/pull request/
> and *nothing else* I think I'd agree that there's no problem. The questions
> that are popping up are coming instead from trying to envision the next few
> steps out from "We started accepted pull requests on Github", i.e. the
> developer pressure on the rest of us to conform, "where will we do the code
> reviews", or the fear that development would naturally shift over to
> Github.

I understand and agree with the concern regarding social pressure to allow 
this form of patch submission on a global basis once it is allowed by some 
projects.

But I am still unsure on the "development will happen at github" part.

Development happens on the developers machine which, due to git, can be done 
without any server after the initial clone.

If developers want to cooperate on some work, they have, again due to git, 
several options, where using the original server (either as a branch or a 
personal clone on the server) is only one.

They could allow one to access the other's machine, or use a private server or 
use any of the git hosting providers.

What makes cloning from KDE's github mirror repository so different than 
uploading the code on your own?

> Because after all if you can now contribute to KDE *just* by submitting pull
> requests on your Github fork, then why bother getting a KDE development
> account? This is something we didn't really have to worry about with
> Bugzilla or emailed-patches because no one's masochistic enough to sustain
> extended development that way.

Well, when I started contributing to KDE, mailing patches was the only option.
And I would have easily continued doing that if my counterpart, the already 
accredited KDE developer, wouldn't have told me to basically either get a CVS 
account or get lost ;-)

Sure, the pull request is easier than to write a mail, but not a lot (sending 
a patch via email to the same recipient is easily scriptable).

The burden in either case is on the receiving KDE developers.
They become responsible for the patch, they either need to clean it up before 
pushing (on projects without review) or put it up for review and address all 
comments (for projects with review).

How likely is a developer going to do that longer than accepting patches via 
email.
For them this is almost the same overhead (almost since saving a patch and 
calling git am is slighlty more work than calling git pull on an already 
established remote).

> But on Github that workflow is already the default, it would be more work to
> go further and request a KDE identity.

Sure, for the new person that is true. But the "receivers" have to do more 
work than they would have if the new person would just simply get a KDE 
account.

Why burden yourself with extra work, potentially repeating extra work, if the 
other person only needs to do extra work once?

I don't see that happening beyond a handful of patches per new contributor. 
Like in the old days the KDE developer will ask the new contributor to "get an 
account or get lost".

> That wouldn't be a big problem for developers who were only going to toss us
> a patch or two anyways--no big loss in that department. But what about the
> developers might have joined but now see no need to?

This is highly hypothetical IMHO.
That would mean the work of that developer is so great that the KDE 
contributor who manages that developer is OK with continuing the additional 
burden and responsibilty indefinitely.

Especially with review based workflow becoming more and more common (and 
somewhat "mandatory"), that burden even increases.

How long are developers going to do all the integration work for unwilling 
contributors?
Is it expected to be really that much longer than in an email based patch 
submission scenario?

> That would lead us, eventually, into one of two situations:
> 
> a) Having to post developers to watch all of our Github mirrors and bring
> back pull requests, and eat the loss in possible KDE community
> contributors, and run the risk of increased reliance on Github infra for
> meaningful development. b) Having to move official development closer to
> Github itself to be closer to where the new developers are (with the same
> risk of reliance).
> 
> There are ways around this, we could run concerted recruiting efforts to
> remind those submitting pull requests that there's a wider community behind
> the mirror and try to recruit that way, but that would have to be done *in
> concert* (and therefore, be discussed beforehand).

I am not so sure.
At first all new contributions go through an established contributor, even if 
the new contributor uploads to reviewboard.
At some point that established contributor will ask the new contributor to 
take more responsibility (and the final part of the work) and get a commit 
account, verfying to sysadmins that the new person should get one.

Would the established developer really be content to hold out significantly 
longer just because the new contributor would additionally have to create a 
KDE identity account?

> And none of that addresses things like ensuring that review happens in spots
> available to the KDE community (are you **really** going to re-review a
> pull request that had been reviewed on Github over on reviewboard.kde.org?
> Every time? Same for every developer?).

I am not sure what you mean with that.
A project that does not require reviews will get stuff merged without review 
anyway.
A project that requires review will only accept merge after review.

If want developer cooperate before the review to submit a as-good-as-possible 
candidate, they can do that already in various ways, aided by how git works.

If you and me were to work cooperatively on a patch for KWin, by one of the 
many means that git allows us to, wouldn't we put that patch up for review no 
matter of whether we had to? (we could both directly push it at any time).

For me that would be a clear No, I have no prior experience with KWin 
development and would even for an IMHO perfect patch have KWin developer 
feedback.

Would it matter for the KWin developers if we had used github for our 
collaboration?

> So when I say I'm opposed to this kind of thing it's not because I think the
> idea is completely stupid or that it's so off base, but rather that there
> *are* implications to this which we'd need to think through, especially in
> relation to the expected positive gain. It's not simply a flip the switch,
> allow pull requests, and it acts just like emailed patches...

Absolutely.
I see the "social pressure to allow it by default" problem as significant 
enough, but I really don't understand (yet?) the scare of "development will 
move away".

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