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

[Fangrui Song via llvm-dev]

On 2020-06-30, James Y Knight via llvm-dev wrote:
>On Tue, Jun 30, 2020 at 5:28 PM Mehdi AMINI via cfe-dev <
>cfe-dev at lists.llvm.org> wrote:
>
>>
>>
>> On Tue, Jun 30, 2020 at 1:38 PM Chris Lattner via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> I want to bubble out of this discussion, because most of the conversation
>>> has been about merit of various tools, how much the cloud license costs,
>>> etc.
>>>
>>>
>>> In my opinion, none of this actually matters.  There are much larger
>>> strategic questions that we should be talking about instead:
>>>
>>> 1) Why is LLVM special?  We are a tiny community compared to the larger
>>> GitHub community - anything that makes us “weird” (even if weird is better
>>> in some ways) increases impedance mismatch, reduces collaboration with
>>> other communities etc.  Many users of LLVM are already using GitHub for
>>> code reviews and PRs etc.
>>
>>
>>> 2) Why should compiler nerds :-) be working on this sort of
>>> infrastructure?  We have many talented people who are capable of doing many
>>> impressive things, why spent that energy on this?
>>>
>>> 3) Even if someone is willing to keep this going, what ongoing liability
>>> is this for the project as a whole?  Phabricator was done for the weekend,
>>> did someone’s pager go off?  What is the SLA/SLO for the new system?
>>>
>>> As I mentioned upthread, I like Phabricator and its workflow from a
>>> personal perspective, but from a project perspective, I can’t see any
>>> reason to defend bespoke infra like this.
>>>
>>
>> From a project point of view: the productivity of the developers on the
>> project seems like a major reason to support this infra.
>> I'd rather work on writing compiler infra than dev infra, but I still
>> spent a few hours this week-end on setting up a cloud VM to migrate our
>> Phab to it ; because until we have a good story for Phab features we rely
>> on today it does not seem reasonable to me to *rush* the migration to
>> GitHub.
>> That said I'm interested to hear how Swift developers (or Rust, or...) are
>> adjusting their workflow to not depend on Herald for example? What about
>> the review dashboard that you have as a landing page on Phab (and that is
>> customizable)?
>> Having an answer to all these would help planning a timely migration to
>> GitHub PRs.
>>
>> As of the current Phab instance: it has been running for 6 years and we
>> did pretty well with the current setup. It does not seem like an urgent
>> problem to address SLA/SLO just right now. We actually know why the system
>> has some issues like this Saturday: the root partition has 10GB and the
>> apache2 logs can get quite large (I zipped a log file on the server this
>> weekend when folks reported trouble on Saturday, and I'm looking into more
>> maintenance on this topic next weekend).
>>

There have been many complaints about Github's code review system.
(dependant patches are hard to organize, incorrectly "Resolved"
comments, comment on a line which is not part of the PR, , etc).

Beside that, there are non-review related issues. Things I recall:

* Subscription via Herald.
   > Yes, but this part of the problem is trivial to solve. We can add a
   > github workflow which triggers on pull-requests being uploaded or
   > modified, which will @ people who ask to be, based on a
   > configuration file matching commit paths/descriptions. There may
   > even be something existing which does this, but even if not, it
   > should be no more than a week to fully implement.
* Github provides no .patch attachment in email notification. This was raised in a
   previous discussion thread. Some folks rely on this feature to help
   filtering patches.

>I very much appreciate everyone who has volunteered to keep the existing
>tooling on a stable footing. Until we actually *do* manage to switch to
>something else, keeping Phabricator running is extremely important. So,
>thank you for taking this task on, and thanks to everyone else who has run
>it before!
>That said...I do hope that having new volunteers to maintain it, for now,
>isn't going to stop us from working towards being able to migrate away. I
>believe that is the sense in which Chris's mail is intended: while Phab may
>soon no longer be at high risk of falling over dead from lack of attention
>-- which is great -- that doesn't necessarily mean we should keep using it
>forever.

Agreed. The main pain point migrating to Github is degraded review
experience. We don't necessarily keep Phabricator forever[1] When the
review system gets improved that people are happy with it, and
potentially a few other items get addressed, we can consider migrating
to Github. Before that happens, there is a lot value keeping Phabricator
alive and stable.

[1]: Note that at the point we consider abandoning it, we should
consider how to make a read-only archive. There are numerous
reviews.llvm.org D rL rC rG rLLD rCTE references in git messages.