[llvm-dev] [cfe-dev] Phabricator -> GitHub PRs?
Cranmer, Joshua via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 15 08:07:44 PST 2020
> On Tue, Jan 14, 2020 at 09:56:53PM +0000, Renato Golin via cfe-dev wrote:
> > GitHub PR is the "de facto standard", everyone knows, the entry cost
> > is practically zero. The UI is lean and missing features, but the
> > large availability of tooling (either targeting GitHub directly or
> > plain git) makes up for a lot of it.
>
> Just like with the "Everyone knows git", I call bullshit on this. Sorry, but the
> far majority of GitHub users know little more than the most barebone
> functionality of Pull Requests and the typical use case in most projects is to
> squash all changes. But at this point it seems clear that the real goal is to just
> move everything to GitHub just for the sake of it.
I recently had the task of explaining to some other people in my organization how to submit their changes using GitHub's pull request model. That experience indicates to me that this model is far from intuitive and easy for people to understand, especially if one is not terribly strong in git. I would concur that a decent fraction of people, probably a majority, are using magic git incantations to get their work done here.
Is the Phabricator process any better in this regard, though? I can't say for certain. For most of the history of open source projects, contribution has generally progressed by means of the "get a diff of your change and email/upload it somewhere" (and note that Phabricator is a variant on the "upload it somewhere" portion of the spectrum). Contribution in this manner is still the norm for several large, complex open-source projects, such as Linux, Firefox, GCC, or OpenJDK. Indeed, looking at our peer projects (those that are of similar complexity and scale, or also tackle compiler-related problems), contribution via a pull request model appears to be accepted by only a small few.
My experience of using GitHub PRs in the past is that different projects have different expectations for how contributors should update their changes during the review process. This makes me skeptical that even moving to GitHub PRs would meaningfully reduce the friction for new contributors, instead changing what and where the friction lands. So, to me, it seems hard to justify moving to GitHub PRs.
More information about the llvm-dev
mailing list