[cfe-dev] [llvm-dev] Phabricator Maintenance

[Chris Lattner via cfe-dev]

> On Jun 23, 2020, at 10:56 AM, Philip Reames via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> On 6/22/20 2:34 AM, Manuel Klimek via llvm-dev wrote:
>> On Sat, Jun 20, 2020 at 1:45 AM Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 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
>> 
>> Are you volunteering to drive Phab maintenance and keep it up & running?
> This really seems like a question for the board, rather than any individual.  If you're resigning and the community values phab, having the board weigh in on cost to support the tool seems worthwhile.  I suspect that cost will be high enough that we will migrate to something free, but we should at least have an informed discussion.  
> 
> (In case it's not clear, "cost" above is specifically meant in both the financial and non-financial sense.  This might be a case where a contractor is worth considering instead of relying solely on volunteer labor.)
> 
I’m not speaking on behalf of the board, I am just sharing my personal opinion here:


I *really* like the Phabricator workflow in practice - I feel like it fits very nicely with the LLVM development model and aside from some super minor UI squabbles, it seems to work great in practice.  I am really thankful that Manuel and others made this happen over the years, it was a huge step up from where we were.

That said, I can’t see a world in which it makes sense to maintain this, particularly in the absence of a dedicated team that will do ongoing security and other maintenance.  Having such critical project infrastructure on shaky maintenance grounds is a huge liability, and we’ve had Phab go down briefly in the past.

Furthermore, LLVM having bespoke infra like this is a burden for new people and contributors, because they have to learn our way of doing things.  The Github workflows (particularly PRs and the review workflow) are widely adopted across a ton of projects, including those that are larger than LLVM and have a dedicated team (GitHub) that maintain and evolve them.  While using GitHub loses us the ability to have full control over the stack, we gain by focusing our limited admin cycles on other infra that is more important to us.

I fully support the move to GitHub PR flow.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200623/fe1a4588/attachment-0001.html>