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

Wed Jan 15 09:47:55 PST 2020

Hi Renato,

I really did try to be constructive in these discussions. If my email
was conceived otherwise I'm sorry about that.

On 01/15, Renato Golin wrote:
> 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

I think this is an oversimplification to paint things black and white.
People did offer solutions (tips, workflows, scripts, ...) as a response
to actual problems (on both sides of the 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'd say that helping people to improve their environment is better than
forcing others to worsen theirs. Phab is, by many accounts, more
feature-rich, thus we might be able to actually work around the problems
people have reasonably if these are articulated.

I agree that there was communication of the kind "Phab is really bad, GH
are better because XXXX" with responses listing flaws in GH or saying
XXXX is not a problem. As I mentioned above, asking people to list
problems does actually result in solutions being offered, why is this
not good?

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

I don't disagree but I ask if that is what we want. If the answer is
"maybe" we should make that the discussion. So far, we are mainly
discussion replacing Phab with PRs and keeping the system otherwise
intact.

> What I'm asking is that we review both together. Current process with
> Phab versus a GitHub process with GitHub PR.

But for that we need to actually list the problems and benefits anyway.
Why not start with doing that.

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

Here and below I actually did not try question the statements made but
I try to determine what they mean for us.

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

I did not argue anything else. I asked if we are trying to keep up with
the de facto standard for the sake of it, to improve the situation for a
certain group, or (implicitly) if the move would be generally speaking good.

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/cfe-dev/attachments/20200115/03f732e8/attachment-0001.sig>