llvm dev - Jan 2020 - [cfe-dev] Phabricator -> GitHub PRs?

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.
> Phab has a very complex UI with a lot of features that people have
> come to rely over the years. But it's far too complex for new people
> and requires specially crafted tooling to work with.
Can you at least try to make reasonable arguments without ridiculous
hyperbole? Using phabricator for the casual user requires no special
tooling. Patches can be easily submitted via patch upload. There are
better ways to integrate it into a workflow, arcanist and git-phab just
to mention two.

Joerg

On 2020-01-14, Joerg Sonnenberger via llvm-dev wrote:
>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.
Agree with Joerg here. And thanks for the recommendation
https://gregoryszorc.com/blog/2020/01/07/problems-with-pull-requests-and-how-to-fix-them/
It was a great reading!

We should find justifying reasons to migrate (it has a significant cost
for people used to the current system), not just for the sake of using
GitHub for everything.

Konrad Kleine's action is appreciated (contacted the Github Support
about a deficiency).
>> Phab has a very complex UI with a lot of features that people have
>> come to rely over the years. But it's far too complex for new
people
>> and requires specially crafted tooling to work with.
>
>Can you at least try to make reasonable arguments without ridiculous
>hyperbole? Using phabricator for the casual user requires no special
>tooling. Patches can be easily submitted via patch upload. There are
>better ways to integrate it into a workflow, arcanist and git-phab just
>to mention two.
>
>Joerg

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

Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> writes:
>> 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.
Let's try to assume good faith on the part of all parties.
>> Phab has a very complex UI with a lot of features that people have
>> come to rely over the years. But it's far too complex for new
people
>> and requires specially crafted tooling to work with.
>
> Can you at least try to make reasonable arguments without ridiculous
> hyperbole? Using phabricator for the casual user requires no special
> tooling. Patches can be easily submitted via patch upload. There are
> better ways to integrate it into a workflow, arcanist and git-phab just
> to mention two.
I for one cannot get arcanist to work because of its reliance on PHP
which for whatever reason refuses to install on my machine.  It it's
hard for me to do a simple install of a tool for code review, I can't
imagine the frustration of new people trying to get everything working.

I wasn't aware of git-phab and don't recall seeing it mentioned in the
LLVM documentation.  I just checked and there is no mention of it.  I'm
not sure how new people are supposed to know about it.  It does look
nice from a cursory review of its front page.  I'll give it a try!

I have never used Phab's more complex features.  There's nothing in the
LLVM documentation that talks about patch series or patch parents or
anything more advanced than "submit a patch and pick reviewers."  For
many people that is enough.  But if I were to run into a situation where
one of the reviewers asked to link my change to some other change, o
present things as a patch series I would have no idea how to do that.
If I were new to the project I would just give up at that point.

There's this bit in the documentation:

  Phabricator has many useful features, for example allowing you to
  select diffs between different versions of the patch as it was
  reviewed in the Revision Update History. Most features are self
  descriptive - explore, and if you have a question, drop by on #llvm in
  IRC to get help.

As has been noted in other threads, new users find IRC intimidating.  I
haven't used IRC since I don't know when.  I'm not even sure I *can*
given company policy.  It's another hurdle to getting things done.  And
important features are not "self descriptive" (see below).

The Phab instance has very little documentation and what there is is
difficult to find (I have to go to "More Applications" and click
"Guides" under "Utilities" -- really, does this organization
make any
sense at all?).  And then the guides seem limited to configuration, not
actual use-cases.

"More Applications" looks very intimidating with nonsensical names for
things I might want to do ("Harbormaster?"  "Drydock?").

GitHub uses Markdown, which is another de facto standard.  Phab uses
"Remarkup" which I guess is similar but different.

The front-page of Phab makes little sense to a new user.  What is
"Differential?"  What is "Diffusion?"  Do they both have
something to do
with diffs?  Oh wait, "Diffusion" brings me to a list of "Active
Repositories."  What?

Ok, let's try "Differential."  Looks promising.  There's a
list of "LLVM
Needs Review."  Looks like a code review tool.  But I just want to
create a patch and submit it.  Grumble, grumble, look back at the LLVM
documentation.  Oh, it's the tiny inconspicuous button on the very top
right corner "+ Create Diff."  The documentation told me about the
button but not where it's located.  Took me some time to find it.

The above journey to get a patch submitted was my actual first
experience with Phab.  It did not leave a good taste in my mouth.

                           -David

Fangrui Song via llvm-dev <llvm-dev at lists.llvm.org> writes:
> Agree with Joerg here. And thanks for the recommendation
>
https://gregoryszorc.com/blog/2020/01/07/problems-with-pull-requests-and-how-to-fix-them/
> It was a great reading!
It's a good read (I did not get through all of it yet) but I lost of bit
of interest when he talks about reviewing pull requests with multiple
commits.  Some of his arguments come down to, "people don't submit
clean
histories for merging" which is going to be a problem for any review
tool.  It isn't limited to GitHub.

I do agree that pull requests should group review comments by commit.  I
certainly don't claim that GitHub is perfect.

I can't really speak to the scalability arguments against the pull
request model other than to say that we haven't had any issues
downstream with our repositories.
> We should find justifying reasons to migrate (it has a significant
> cost for people used to the current system), not just for the sake of
> using GitHub for everything.
People have posted multiple reasons so it's not fair to say that people
are pushing the move just for the sake of using GitHub.  It is true that
current users of Phab would have to change workflows.  That's the nature
of change.  If the benefit is moving to something more universally
understood that is much easier and welcoming for new contributors, I am
all for it.

                         -David

On 01/15, David Greene via llvm-dev wrote:
> Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 
> >> 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.
> 
> Let's try to assume good faith on the part of all parties.
That is a very good point, thanks :)

> >> Phab has a very complex UI with a lot of features that people have
> >> come to rely over the years. But it's far too complex for new
people
> >> and requires specially crafted tooling to work with.
> >
> > Can you at least try to make reasonable arguments without ridiculous
> > hyperbole? Using phabricator for the casual user requires no special
> > tooling. Patches can be easily submitted via patch upload. There are
> > better ways to integrate it into a workflow, arcanist and git-phab
just
> > to mention two.
> 
> I for one cannot get arcanist to work because of its reliance on PHP
> which for whatever reason refuses to install on my machine.  It it's
> hard for me to do a simple install of a tool for code review, I can't
> imagine the frustration of new people trying to get everything working.
Mozilla developed phab tools w/o PHP. I'll actually going to give them a
try soon. (Came up in this thread somewhere).

> I wasn't aware of git-phab and don't recall seeing it mentioned in
the
> LLVM documentation.  I just checked and there is no mention of it.  I'm
> not sure how new people are supposed to know about it.  It does look
> nice from a cursory review of its front page.  I'll give it a try!
We need to add more documentation, true.
We also need to openly discuss problems people face and look for ways to
remedy them.

> I have never used Phab's more complex features.  There's nothing in
the
> LLVM documentation that talks about patch series or patch parents or
> anything more advanced than "submit a patch and pick reviewers." 
For
> many people that is enough.  But if I were to run into a situation where
> one of the reviewers asked to link my change to some other change, o
> present things as a patch series I would have no idea how to do that.
> If I were new to the project I would just give up at that point.
I would really hope that people would ask the reviewer how to do that if
the reviewer explicitly requests it. This should not only be true for
Phab related questions but also for questions on code comments,
etiquette, process ...

If people do not ask questions, that is a different problem.
If questions are not answered, that would be the worst.

> There's this bit in the documentation:
> 
>   Phabricator has many useful features, for example allowing you to
>   select diffs between different versions of the patch as it was
>   reviewed in the Revision Update History. Most features are self
>   descriptive - explore, and if you have a question, drop by on #llvm in
>   IRC to get help.
> 
> As has been noted in other threads, new users find IRC intimidating.  I
> haven't used IRC since I don't know when.  I'm not even sure I
*can*
> given company policy.  It's another hurdle to getting things done.  And
> important features are not "self descriptive" (see below).
> 
> The Phab instance has very little documentation and what there is is
> difficult to find (I have to go to "More Applications" and click
> "Guides" under "Utilities" -- really, does this
organization make any
> sense at all?).  And then the guides seem limited to configuration, not
> actual use-cases.
> 
> "More Applications" looks very intimidating with nonsensical
names for
> things I might want to do ("Harbormaster?" 
"Drydock?").
> 
> GitHub uses Markdown, which is another de facto standard.  Phab uses
> "Remarkup" which I guess is similar but different.
> 
> The front-page of Phab makes little sense to a new user.  What is
> "Differential?"  What is "Diffusion?"  Do they both
have something to do
> with diffs?  Oh wait, "Diffusion" brings me to a list of
"Active
> Repositories."  What?
> 
> Ok, let's try "Differential."  Looks promising.  There's
a list of "LLVM
> Needs Review."  Looks like a code review tool.  But I just want to
> create a patch and submit it.  Grumble, grumble, look back at the LLVM
> documentation.  Oh, it's the tiny inconspicuous button on the very top
> right corner "+ Create Diff."  The documentation told me about
the
> button but not where it's located.  Took me some time to find it.
> 
> The above journey to get a patch submitted was my actual first
> experience with Phab.  It did not leave a good taste in my mouth.
What if we take these points and act on them?
 It should be "fairly simple" to simplify the interface by hiding less
 often used apps.
 While writing documentation is not easy, it would also help I guess.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200115/a7471998/attachment.sig>