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

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.

-Chris



> On Jun 29, 2020, at 4:11 AM, Nicolai Hähnle via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On Fri, Jun 26, 2020 at 9:54 AM James Henderson via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> 2) Typically in our Phabricator, the description and summary of a patch
is considered to be roughly what goes in the final commit message (same with
Github). However, updating said commit message isn't possible to my
knowledge without force-pushing in Github (which as discussed elsewhere in the
thread causes other problems).
> 
> Rebasing _should_ be how commit messages are changed. Ideally, we'd
> treat commit messages as part of the artefact under review, since good
> commit messages matter. Phabricator isn't ideal here either: by
> default, updating a patch doesn't update its commit message.
> 
> On the GitHub side, the real problem here is how easily it loses the
> plot when you rebase.
> 
> 
>> 3) Marking comments as "Done" in Phabricator does not
auto-hide them, whereas in Github marking a comment as "Resolved"
does. Spoken from experience, this leads to situations in Github where a
developer thinks they've resolved a reviewers comments, marks them as
Resolved, but actually they weren't. The reviewer in turn then has to browse
the comments in the summary page, to see if they have any unaddressed comments
that were supposedly resolved, which given the limited context available there
is a non-trivial task sometimes.
> 
> Ideally, the "Resolved" state should be per-user. When multiple
people
> review a patch, I might not want to duplicate a comment that another
> reviewer made, but I would like to confirm for myself whether an issue
> was resolved or not.
> 
> 
>> P.S. Thanks Mehdi/Fangrui for stepping up! Whilst I'm not opposed
to working with Github towards getting the feature parity with Phabricator
sorted, I don't want to switch until the two are on a par with each other,
which in my opinion is not yet, so being forced to do so prematurely due to lack
of maintainers would have made me very sad (P.P.S thank you Manuel for
Phabricator in the first place!).
> 
> Seconded on all counts!
> 
> Cheers,
> Nicolai
> 
> -- 
> Lerne, wie die Welt wirklich ist,
> aber vergiss niemals, wie sie sein sollte.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

-- 
Mehdi





>
> -Chris
>
>
>
>
> > On Jun 29, 2020, at 4:11 AM, Nicolai Hähnle via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > On Fri, Jun 26, 2020 at 9:54 AM James Henderson via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >> 2) Typically in our Phabricator, the description and summary of a
patch
> is considered to be roughly what goes in the final commit message (same
> with Github). However, updating said commit message isn't possible to
my
> knowledge without force-pushing in Github (which as discussed elsewhere in
> the thread causes other problems).
> >
> > Rebasing _should_ be how commit messages are changed. Ideally,
we'd
> > treat commit messages as part of the artefact under review, since good
> > commit messages matter. Phabricator isn't ideal here either: by
> > default, updating a patch doesn't update its commit message.
> >
> > On the GitHub side, the real problem here is how easily it loses the
> > plot when you rebase.
> >
> >
> >> 3) Marking comments as "Done" in Phabricator does not
auto-hide them,
> whereas in Github marking a comment as "Resolved" does. Spoken
from
> experience, this leads to situations in Github where a developer thinks
> they've resolved a reviewers comments, marks them as Resolved, but
actually
> they weren't. The reviewer in turn then has to browse the comments in
the
> summary page, to see if they have any unaddressed comments that were
> supposedly resolved, which given the limited context available there is a
> non-trivial task sometimes.
> >
> > Ideally, the "Resolved" state should be per-user. When
multiple people
> > review a patch, I might not want to duplicate a comment that another
> > reviewer made, but I would like to confirm for myself whether an issue
> > was resolved or not.
> >
> >
> >> P.S. Thanks Mehdi/Fangrui for stepping up! Whilst I'm not
opposed to
> working with Github towards getting the feature parity with Phabricator
> sorted, I don't want to switch until the two are on a par with each
other,
> which in my opinion is not yet, so being forced to do so prematurely due to
> lack of maintainers would have made me very sad (P.P.S thank you Manuel for
> Phabricator in the first place!).
> >
> > Seconded on all counts!
> >
> > Cheers,
> > Nicolai
> >
> > --
> > Lerne, wie die Welt wirklich ist,
> > aber vergiss niemals, wie sie sein sollte.
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200630/437c04cc/attachment-0001.html>

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).
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200630/95a604f9/attachment.html>