Outdated Phabricator version on reviews.llvm.org breaks Google authentication since today

Hi all,

I’m using my Google account to log into my Phabricator account on reviews.llvm.org . Since today that no longer works as I don’t seem to get any reply from reviews.llvm.org when I’m logged into my account. It tried logging out which fixes the issue of reviews.llvm.org not loading, but when I try to login I just get the following error:

Expected to retrieve an "account" email from Google Plus API call to identify account, but failed.

After some searching it seems that this error is due to the Google Plus API being shutdown and the Phabricator folks replaced that logic (including this error message string) a year ago here [1]

I assume we haven’t updated reviews.llvm.org to whatever latest Phabricator release contains that patch.

Not sure who’s currently responsible for updating reviews.llvm.org so I thought I’ll just drop a mail to the list (and maybe save someone else from figuring out why their login is suddenly broken).

[1] https://secure.phabricator.com/D20030

hey Manuel - are you/do you know who’s likely to be doing any upkeep on Phabricator these days? Might need an update for this…

  • Dave

cc Paul / MyDeveloperDay

Envoyé : April 8, 2020 10:21 PM

Friendly ping

Hi folks,

phabricator maintenance is a topic that has been lying dormant for a while now.

That subsequently creates a non-optimal user experience.
For me personally, given that github provides a secure PR infrastructure, the additional effort required to keep Phab going is not an investment I’m personally willing to make. I understand that there are unique selling points for Phab in its UI compared to github PRs, but there are also significant downsides in the effort to integrate with Phab that github PRs make easier.

Thus, I see two options:

  1. somebody volunteers to take on Phabricator maintenance and figures out a way to fund it, either through the LLVM foundation or some other means (I’d love for us at Google to pay for it directly and give folks outside Google access, but that is unfortunately a hard problem for a variety of reasons). I’d be happy to help to provide a DB snapshot for the migration, of course.

  2. We switch to github PRs

Thoughts?
/Manuel

-Chris’ outdated email, +Chris’ correct email :slight_smile:

Just my 2 cents here: we are working on enabling this as a part of
bugzilla migration as PRs and issues are very tied inside GitHub. Stay
tuned for updates!

Just my 2 cents here: we are working on enabling this as a part of
bugzilla migration as PRs and issues are very tied inside GitHub. Stay
tuned for updates!

I am not aware that the previous long thread about usage of GitHub PRs in place of Phabricator reviews got anywhere near the point where the option of Phabricator reviews was being dropped. The original post on this thread indicated interest in not maintaining Phabricator. How does that affect the availability of Phabricator? Does this mean that the community is going to move to GitHub PRs because the choice of Phabricator is being taken away?

Just my 2 cents here: we are working on enabling this as a part of
bugzilla migration as PRs and issues are very tied inside GitHub. Stay
tuned for updates!

I am not aware that the previous long thread about usage of GitHub PRs in place of Phabricator reviews got anywhere near the point where the option of Phabricator reviews was being dropped. The original post on this thread indicated interest in not maintaining Phabricator. How does that affect the availability of Phabricator? Does this mean that the community is going to move to GitHub PRs because the choice of Phabricator is being taken away?

I don’t think the choice is being taken away, but somebody who believes the cost is worth it has to be willing and able to take on the cost. I can see that that might feel the same if you’d prefer phab but can’t shoulder the investment, but I think it’s an important difference.

We got Phab back in the day when I started to work on clang and decided that it’s not a good use of my time to do email code reviews (and I had to fight a cultural battle to get it :slight_smile: if somebody thinks the diff of GitHub PR to Phab is worth the ongoing investment & security risks, I’m very happy to hand it over.

Just my 2 cents here: we are working on enabling this as a part of
bugzilla migration as PRs and issues are very tied inside GitHub. Stay
tuned for updates!

I am not aware that the previous long thread about usage of GitHub PRs in place of Phabricator reviews got anywhere near the point where the option of Phabricator reviews was being dropped. The original post on this thread indicated interest in not maintaining Phabricator. How does that affect the availability of Phabricator? Does this mean that the community is going to move to GitHub PRs because the choice of Phabricator is being taken away?

I don’t think the choice is being taken away, but somebody who believes the cost is worth it has to be willing and able to take on the cost. I can see that that might feel the same if you’d prefer phab but can’t shoulder the investment, but I think it’s an important difference.

We got Phab back in the day when I started to work on clang and decided that it’s not a good use of my time to do email code reviews (and I had to fight a cultural battle to get it :slight_smile: if somebody thinks the diff of GitHub PR to Phab is worth the ongoing investment & security risks, I’m very happy to hand it over.

Thanks for having fought that cultural battle and your work since. I was responding mainly to say that we should not proceed with just assuming that Phabricator does not warrant further investment because GitHub PRs exist.

Just my 2 cents here: we are working on enabling this as a part of
bugzilla migration as PRs and issues are very tied inside GitHub. Stay
tuned for updates!

I am not aware that the previous long thread about usage of GitHub PRs in place of Phabricator reviews got anywhere near the point where the option of Phabricator reviews was being dropped. The original post on this thread indicated interest in not maintaining Phabricator. How does that affect the availability of Phabricator? Does this mean that the community is going to move to GitHub PRs because the choice of Phabricator is being taken away?

I don’t think the choice is being taken away, but somebody who believes the cost is worth it has to be willing and able to take on the cost. I can see that that might feel the same if you’d prefer phab but can’t shoulder the investment, but I think it’s an important difference.

We got Phab back in the day when I started to work on clang and decided that it’s not a good use of my time to do email code reviews (and I had to fight a cultural battle to get it :slight_smile: if somebody thinks the diff of GitHub PR to Phab is worth the ongoing investment & security risks, I’m very happy to hand it over.

Thanks for having fought that cultural battle and your work since. I was responding mainly to say that we should not proceed with just assuming that Phabricator does not warrant further investment because GitHub PRs exist.

I do agree. I would urge everyone to look at the incremental benefit as well as the incremental cost though. Phab being better overall (while also clearly being worse in some aspects) doesn’t automatically imply that it’s a good idea to keep it, given the cost & risk it poses.

That’s my impression as well, I find GitHub review is frustrating in comparison to phab, in particular the way comments are handled across updates, unless you stick to never rebase and only append commits and merges from master. This is unfortunately not compatible with the LLVM repo history right now.

https://www.phacility.com offers hosting for Phabricator, could we look into this instead?

FWIW GitHub’s code review tools have improved significantly in the past few years. At this point with reviews and manual control over resolving / unresolving comments I think many previous complaints I’ve seen about GitHub vs Phabricator have been alleviated.

I also believe there’s significant value for newcomers and casual contributors (like myself) in using the same tool as so many other major open source projects.

FWIW GitHub’s code review tools have improved significantly in the past few years. At this point with reviews and manual control over resolving / unresolving comments I think many previous complaints I’ve seen about GitHub vs Phabricator have been alleviated.

To be clear: this wasn’t an outdated comment here, I’m using GitHub very frequently right now as I’m reviewing contributions to TensorFlow.

I use GH daily at my current employer and i can tell you that the issues with rebasing are very real. Unless you only use merge commits you are going to have a very bad time

I use GH daily at my current employer and i can tell you that the issues with rebasing are very real. Unless you only use merge commits you are going to have a very bad time

Would it be practical to use merge commits during review (never
rebasing) & then rebasing/squashing to commit to the main line?
(guessing that might still make looking back at the history of the
review difficult?)

- Dave

Yes GH has a Squash & Merge option that works well. It’s what we use. We use the GH web interface for all of this though, if you’re supporting command line you may need some custom tooling to support this.

The biggest thing is that it requires a lot of mental retraining to get out of the rebasing mindset for daily development

There’s also some feature regressions in GH vs Phab.

You must initiate a review via a pull request, and pull request by definition compares your working copy against master.

This is not very compatible with LLVMs approach to incremental development. For example, if you ask someone to break a large patch into 5 smaller patches, with Phab this is very easy because you can upload the diff between N and N+1, then N+1 and N+2, etc.

But with the GH workflow in order to get a review on N+4 you have to include all the changes from all the earlier revisions as well.

The way around this is to fork and make 5 branches in your fork, then base each branch off the previous one. But now what do you do if someone requests a change on the first one?

Overall it’s a pretty serious limitation if you’re used to Phab, and I would evaluate very carefully if you’re thinking of going this route

I use GH daily at my current employer and i can tell you that the issues with rebasing are very real. Unless you only use merge commits you are going to have a very bad time

Would it be practical to use merge commits during review (never
rebasing) & then rebasing/squashing to commit to the main line?
(guessing that might still make looking back at the history of the
review difficult?)

A merge appears in the UI as introducing many, many commits. Also, a key method of progressing reviews on Phabricator (for me) is to go through the differences between the updates. If there is a merge in between on GitHub, I don’t want to see all the changes that come from the merged commits.

Just my 2 cents here: we are working on enabling this as a part of
bugzilla migration as PRs and issues are very tied inside GitHub. Stay
tuned for updates!

I am not aware that the previous long thread about usage of GitHub PRs in place of Phabricator reviews got anywhere near the point where the option of Phabricator reviews was being dropped

That’s my impression as well, I find GitHub review is frustrating in comparison to phab, in particular the way comments are handled across updates, unless you stick to never rebase and only append commits and merges from master. This is unfortunately not compatible with the LLVM repo history right now.

https://www.phacility.com offers hosting for Phabricator, could we look into this instead?

Last time I checked, they basically said they didn’t want us (no customizations, which LLVM folks still wanted).
Whatever we do, we need some volunteer who’s willing to spend multiple days on this (and potentially more going forward).
I’m currently trying to find a volunteer more than solutions.