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

[Mehdi AMINI via llvm-dev]

On Wed, Jun 24, 2020 at 2:31 AM Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

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

This can be addressed by going to a professional hosting for Phabricator
though.


>
> 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'm sympathetic and in general supportive of standardizing our workflows
and tools on what's the most common in the industry (GitHub for example),
but I'm also cautious about preserving the quality of our workflow:
code-review is a key part of the development and one of the difficult
things to handle in general. I consider the review to be quite a critical
part and sensitive part of the development process and I would expect very
strong consideration before settling for an inferior solution.

The past thread on Pull-request led us to discuss asking GitHub for missing
features we have in Phab and ask for a roadmap on implementing them before
commiting to a migration.

When I looked into this possibility (GitHub PR) when we merged MLIR in the
monorepo: just Herald rules was already a blocker and I couldn't find a
replacement readily available on GitHub. The handling of stack of revisions
on GitHub was another problem mentioned.

Best,

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200624/d5b3ba5a/attachment.html>