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

Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes:
> Granted, GitHub's UI is much "simpler" than Phab, but to my
view, this
> is not a problem, but a benefit.
>
> If we moved to GitHub PRs today, I wouldn't miss a thing.
+1.

I still find Phab to be inscrutable.  I don't use any of its advanced
features.  I'm a long-time contributor.  I can't imagine how difficult
it is for folks new to the project.

For all of GitHub's many flaws, its very strong advantage is that it is
a de facto standard.  People understand it.

                   -David

On 01/14, David Greene via cfe-dev wrote:
> Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 
> > Granted, GitHub's UI is much "simpler" than Phab, but to
my view, this
> > is not a problem, but a benefit.
> >
> > If we moved to GitHub PRs today, I wouldn't miss a thing.
> 
> +1.
> 
> I still find Phab to be inscrutable.  I don't use any of its advanced
> features.  I'm a long-time contributor.
I asked a similar question in this thread in the very beginning: What
actual problems do you have with Phab? There might be usable solutions
out there already. The last time someone actually listed problems we got
a lot of good responses, some of which I will try out myself.

> I can't imagine how difficult it is for folks new to the project.
I am always in favor of improving the documentation. We need more
concrete problem descriptions though.

 
> For all of GitHub's many flaws, its very strong advantage is that it is
> a de facto standard.  People understand it.
I do not. Arguably because I have not yet used it. However, "it is a de
facto standard" is a weird argument for anything. People are advocating
to move away from mailing lists towards other system though mailing
lists are, or at least were, "de facto standard". Is the idea to keep
up
with the "de facto standard" or to improve the status quo (for group
X*)?

* Substitute X as you see fit.


Cheers,
  Johannes
-------------- 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/d716e94c/attachment.sig>

On Wed, 15 Jan 2020 at 10:47, Doerfert, Johannes <jdoerfert at anl.gov>
wrote:
> > I still find Phab to be inscrutable.  I don't use any of its
advanced
> > features.  I'm a long-time contributor.
>
> I asked a similar question in this thread in the very beginning: What
> actual problems do you have with Phab? There might be usable solutions
> out there already. The last time someone actually listed problems we got
> a lot of good responses, some of which I will try out myself.
This thread has fallen down to the following pattern:

1. I tell you what I don't like / can't stand
2. You tell me that's not a problem for you and why
3. You ask me to counter your argument

This is not a helpful way to conduct a fact checking exercise.

I respect the opinion of both sides, and I know some people have
gotten to like Phab and others to hate.

I ask that people refrain from attacking others for not engaging in
tit-for-tat "my fact is better than yours" discussion.

Phab is good for some things, Github is good for others. People are
allowed to like either.
> I am always in favor of improving the documentation. We need more
> concrete problem descriptions though.
More documentation or tooling won't fix the fact that much more people
know about GitHub PR than Phab.

It's the same reason why we moved to monorepo GitHub, because everyone
had their own tooling to handle multi-repo Git-SVN hybrid.

If we change the process to be more in tune with GitHub, then their PR
system will (obviously) be far more suitable.

What I'm asking is that we review both together. Current process with
Phab versus a GitHub process with GitHub PR.
> > For all of GitHub's many flaws, its very strong advantage is that
it is
> > a de facto standard.  People understand it.
>
> I do not. Arguably because I have not yet used it.
He said "most people". He is right, even if you don't, personally.
Git
PR (GitHub, GitLab, Gerrit) is indeed the de facto standard.
> However, "it is a de facto standard" is a weird argument for
anything. People are advocating
> to move away from mailing lists towards other system though mailing
> lists are, or at least were, "de facto standard". Is the idea to
keep up
> with the "de facto standard" or to improve the status quo (for
group X*)?
That's the very definition of "de facto". The vast majority of
people
use Git, and of those, GitHub/GitLab, and of those, Git PRs.

Phab is niche compared to GitHub. It doesn't make it worse, but that is a
fact.

"Doerfert, Johannes" <jdoerfert at anl.gov> writes:
>> I still find Phab to be inscrutable.  I don't use any of its
advanced
>> features.  I'm a long-time contributor.
>
> I asked a similar question in this thread in the very beginning: What
> actual problems do you have with Phab? There might be usable solutions
> out there already. The last time someone actually listed problems we got
> a lot of good responses, some of which I will try out myself.
I just posted a few I've run into over the years.
>> I can't imagine how difficult it is for folks new to the project.
>
> I am always in favor of improving the documentation. We need more
> concrete problem descriptions though.
Hopefully my post will help.
>> For all of GitHub's many flaws, its very strong advantage is that
it is
>> a de facto standard.  People understand it.
>
> I do not. Arguably because I have not yet used it. However, "it is a
de
> facto standard" is a weird argument for anything. People are
advocating
> to move away from mailing lists towards other system though mailing
> lists are, or at least were, "de facto standard". Is the idea to
keep up
> with the "de facto standard" or to improve the status quo (for
group X*)?
>
> * Substitute X as you see fit.
I guess I see the goal being integrating new contributors as easy as
possible.  Now I know that many people argue that keeping existing
contributors happy is more important and I can appreciate that
viewpoint.  It is a difficult balance to strike.  I am trying to think
about solutions that lower the barrier to new contributors while letting
existing contributors still get work done, though with workflow changes.

If moving away from mailing lists makes it significantly easier for new
contributors then I will very seriously consider that.  I like e-mail
for a lot of reasons and would be sad to see it go but I'm willing to
make that sacrifice if needed to keep the project strong.

I feel like we are also discounting the possibility that GitHub can
improve.  We have evidence that they will respond to requests for
features.

IME every project eventually dies because it is no longer useful or
because it becomes too difficult to attract/integrate new contributors.
gcc almost died in the '90's and it was only because the issue was
forced via a fork that the project finally opened up to new
contributors.  I have seen projects in the private sector die because it
was too much work to teach new employees about them.  So to me,
attracting new contributors to the LLVM project is vitally important.

                       -David