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

[Michael Pyne]

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!

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"?

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.

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.

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.

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

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?

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).

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?).

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...

Regards,
 - Michael Pyne