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

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>

> On Jun 24, 2020, at 9:28 AM, Mehdi AMINI <joker.eph at gmail.com>
wrote:
> 
> 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.
Yes, I agree, if there is a credible option for professional hosting of
Phabricator, we should definitely consider that.  Does Phabricator have a
committed path and long term engineering group backing it?
> 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.
Fair enough - I haven’t investigated the technical issues with adopting GitHub
PRs for LLVM.  My experience with the Swift community has been extremely
positive though, I’d be surprised if there is something particularly crazy that
only LLVM needs that GitHub hasn’t encountered.  That said, again, I don’t have
any practical experience with this part of the stack,

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

On Wed, Jun 24, 2020 at 10:42 PM Chris Lattner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> > 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.
>
> Fair enough - I haven’t investigated the technical issues with adopting
GitHub PRs for LLVM.  My experience with the Swift community has been extremely
positive though, I’d be surprised if there is something particularly crazy that
only LLVM needs that GitHub hasn’t encountered.  That said, again, I don’t have
any practical experience with this part of the stack,
This may be one of those vicious cycles where people who haven't
experienced the alternative simply don't realize what they're missing.
If you don't know how patch series work in practice, you don't realize
that GitHub lacks the tooling to deal with them. If you're stuck on
GitHub, you will never start working in patch series because the
tooling doesn't support it.

Perhaps one perspective on this that may help understanding is that
there are conflicting goals when it comes to review granularity. There
are forces that make small commits / small reviews desirable, but
there are also forces that make big reviews desirable. Working with
patch series makes multiple "levels of review detail" visible
simultaneously, which is a significant win for the review workflow.
I've written up those ideas in a bit more detail [0]. Phabricator's
Stack UI for this isn't great, but it's much better than what GitHub
has, which is basically nothing. (We try to do patch series in LLPC
sometimes, which uses GitHub PRs, but it really doesn't work well.)

Cheers,
Nicolai

[0]
http://nhaehnle.blogspot.com/2020/06/they-want-to-be-small-they-want-to-be.html

>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.

On 6/24/20 3:41 PM, Chris Lattner via llvm-dev wrote:
>> 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.
> Fair enough - I haven’t investigated the technical issues with adopting
GitHub PRs for LLVM.  My experience with the Swift community has been extremely
positive though, I’d be surprised if there is something particularly crazy that
only LLVM needs that GitHub hasn’t encountered.  That said, again, I don’t have
any practical experience with this part of the stack,
I am very much relying on Herald rules to filter patches (=PRs).

We need some replacement, IMHO, as we have many more patches/commits 
than swift and the mono-repo is more diverse (I would imagine).


~ Johannes

>
> -Chris
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200625/5d0efc30/attachment.html>