llvm dev - Oct 2021 - Phabricator Creator Pulling the Plug

We talked about this with the IWG (Infrastructure Working Group) just
last week coincidentally.
Two major blocking tracks that were identified at the roundtable
during the LLVM Dev Meeting exactly 2 years ago are still an issue
today:

1) Replacement for Herald rules. This is what allows us to subscribe
and track new revisions or commits based on paths in the repo or other
criteria. We could build a replacement based on GitHub action or any
other kind of service, but this is a bit tricky (how do you store
emails privately? etc.). I have looked around online but I didn't find
another OSS project (or external company) providing a similar service
for GitHub unfortunately, does anyone know of any?

2) Support for stacked commits. I can see how to structure this
somehow assuming we would push pull-request branches in the main repo
(with one new commit per branch and cascading the pull-requests from
one branch to the other), otherwise this will be a major regression
compared to the current workflow.

What remains unknown to me is the current state of GitHub management
of comments across `git commit --amend` and force push to update a
branch.

Others may have other items to add!

-- 
Mehdi

On Thu, Sep 30, 2021 at 3:39 PM Brian Cain via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> How far are we from a workflow that leverages Github's Pull Requests? 
Is there some consensus that it's a desired end goal, but some features are
missing?  Or do we prefer to use a workflow like this for the long term?
>
> On Thu, Sep 30, 2021, 4:54 PM Chris Tetreault via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> As I, and others have noticed, it seems that as of today, there’s some
certificate issue with arcanist. (See:
https://lists.llvm.org/pipermail/llvm-dev/2021-September/153019.html) The fix
seems simple, and a PR is up, but looking through the PR activity, it seems that
the PR will not be accepted because Phabricator is no longer being maintained.
It seems that arc has become the first casualty of the discontinuation of
maintenance of phabricator.
>>
>>
>>
>> I know that arc is not universally used, but I think it’s a serious
blow to many people’s workflows. I think that MyDeveloperDay’s question might
have just become a bit more urgent.
>>
>>
>>
>> I suppose in the short-term, we could fork the phabricator repos in
order to fix little issues like this. Alternately, we should probably stop
recommending arcanist (unless we want to provide instructions on how to fix any
breakages that come along).
>>
>>
>>
>> Thanks,
>>
>>    Chris Tetreault
>>
>>
>>
>> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of
MyDeveloper Day via llvm-dev
>> Sent: Wednesday, August 18, 2021 10:17 AM
>> To: llvm-dev <llvm-dev at lists.llvm.org>; cfe-commits
<cfe-commits at lists.llvm.org>
>> Subject: [llvm-dev] Phabricator Creator Pulling the Plug
>>
>>
>>
>> WARNING: This email originated from outside of Qualcomm. Please be wary
of any links or attachments, and do not enable macros.
>>
>> All
>>
>>
>>
>> I'm a massive fan of Phabricator, and I know there is often lots of
contentious discussion about its relative merits vs github,
>>
>>
>>
>> But unless I missed this, was there any discussion regarding the recent
"Winding Down" announcement of Phabricator? and what it might mean for
us in LLVM
>>
>>
>>
>> See:
>>
>>
https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/
>>
>> https://www.phacility.com/phabricator/
>>
>>
>>
>> Personally I'm excited by the concept of a community driven
replacement ( https://we.phorge.it/) .
>>
>> epriestley did a truly amazing job, it wasn't open to public
contributions. Perhaps more open development could lead to closing some of the
github gaps that were of concern.
>>
>>
>>
>> MyDeveloperDay
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Does something like Rust's "bors" bot satisfy the herald rules
need?

re: #2 I have done this on GHE and it's mildly awkward but it does work.

And yes normalizing force pushes is the unfortunate state of GitHub PRs.
Comments are preserved. Code-anchored comments like review comments are
marked as referring to out-of-date code, IIRC.

On Thu, Sep 30, 2021, 5:56 PM Mehdi AMINI <joker.eph at gmail.com> wrote:
> We talked about this with the IWG (Infrastructure Working Group) just
> last week coincidentally.
> Two major blocking tracks that were identified at the roundtable
> during the LLVM Dev Meeting exactly 2 years ago are still an issue
> today:
>
> 1) Replacement for Herald rules. This is what allows us to subscribe
> and track new revisions or commits based on paths in the repo or other
> criteria. We could build a replacement based on GitHub action or any
> other kind of service, but this is a bit tricky (how do you store
> emails privately? etc.). I have looked around online but I didn't find
> another OSS project (or external company) providing a similar service
> for GitHub unfortunately, does anyone know of any?
>
> 2) Support for stacked commits. I can see how to structure this
> somehow assuming we would push pull-request branches in the main repo
> (with one new commit per branch and cascading the pull-requests from
> one branch to the other), otherwise this will be a major regression
> compared to the current workflow.
>
> What remains unknown to me is the current state of GitHub management
> of comments across `git commit --amend` and force push to update a
> branch.
>
> Others may have other items to add!
>
> --
> Mehdi
>
> On Thu, Sep 30, 2021 at 3:39 PM Brian Cain via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > How far are we from a workflow that leverages Github's Pull
Requests?
> Is there some consensus that it's a desired end goal, but some features
are
> missing?  Or do we prefer to use a workflow like this for the long term?
> >
> > On Thu, Sep 30, 2021, 4:54 PM Chris Tetreault via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>
> >> As I, and others have noticed, it seems that as of today, there’s
some
> certificate issue with arcanist. (See:
> https://lists.llvm.org/pipermail/llvm-dev/2021-September/153019.html) The
> fix seems simple, and a PR is up, but looking through the PR activity, it
> seems that the PR will not be accepted because Phabricator is no longer
> being maintained. It seems that arc has become the first casualty of the
> discontinuation of maintenance of phabricator.
> >>
> >>
> >>
> >> I know that arc is not universally used, but I think it’s a
serious
> blow to many people’s workflows. I think that MyDeveloperDay’s question
> might have just become a bit more urgent.
> >>
> >>
> >>
> >> I suppose in the short-term, we could fork the phabricator repos
in
> order to fix little issues like this. Alternately, we should probably stop
> recommending arcanist (unless we want to provide instructions on how to fix
> any breakages that come along).
> >>
> >>
> >>
> >> Thanks,
> >>
> >>    Chris Tetreault
> >>
> >>
> >>
> >> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On
Behalf Of
> MyDeveloper Day via llvm-dev
> >> Sent: Wednesday, August 18, 2021 10:17 AM
> >> To: llvm-dev <llvm-dev at lists.llvm.org>; cfe-commits <
> cfe-commits at lists.llvm.org>
> >> Subject: [llvm-dev] Phabricator Creator Pulling the Plug
> >>
> >>
> >>
> >> WARNING: This email originated from outside of Qualcomm. Please be
wary
> of any links or attachments, and do not enable macros.
> >>
> >> All
> >>
> >>
> >>
> >> I'm a massive fan of Phabricator, and I know there is often
lots of
> contentious discussion about its relative merits vs github,
> >>
> >>
> >>
> >> But unless I missed this, was there any discussion regarding the
recent
> "Winding Down" announcement of Phabricator? and what it might
mean for us
> in LLVM
> >>
> >>
> >>
> >> See:
> >>
> >>
>
https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/
> >>
> >> https://www.phacility.com/phabricator/
> >>
> >>
> >>
> >> Personally I'm excited by the concept of a community driven
replacement
> ( https://we.phorge.it/) .
> >>
> >> epriestley did a truly amazing job, it wasn't open to public
> contributions. Perhaps more open development could lead to closing some of
> the github gaps that were of concern.
> >>
> >>
> >>
> >> MyDeveloperDay
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> > _______________________________________________
> > 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/20210930/900402a1/attachment.html>

On Thu, Sep 30, 2021 at 6:56 PM Mehdi AMINI via cfe-commits <
cfe-commits at lists.llvm.org> wrote:
> We talked about this with the IWG (Infrastructure Working Group) just
> last week coincidentally.
> Two major blocking tracks that were identified at the roundtable
> during the LLVM Dev Meeting exactly 2 years ago are still an issue
> today:
>
> 1) Replacement for Herald rules. This is what allows us to subscribe
> and track new revisions or commits based on paths in the repo or other
> criteria. We could build a replacement based on GitHub action or any
> other kind of service, but this is a bit tricky (how do you store
> emails privately? etc.). I have looked around online but I didn't find
> another OSS project (or external company) providing a similar service
> for GitHub unfortunately, does anyone know of any?
>
> 2) Support for stacked commits. I can see how to structure this
> somehow assuming we would push pull-request branches in the main repo
> (with one new commit per branch and cascading the pull-requests from
> one branch to the other), otherwise this will be a major regression
> compared to the current workflow.
>
> What remains unknown to me is the current state of GitHub management
> of comments across `git commit --amend` and force push to update a
> branch.
>
Force pushing to a PR branch does make it harder for reviewers to see how
review comments were addressed or what was done since they last looked at
the PR. Are your use cases addressed if the workflow consists of pushing
additional commits to address comments or pushing a merge commit to refresh
the PR branch? When the PR is approved, the "squash and merge" option
can
be used to commit the patch as a single commit.

>
> Others may have other items to add!
>
I find the code review experience in GitHub to be a productivity drain
compared to Phabricator.

Older inline comments are much harder to find in GitHub.
Much more clicking needed in GitHub to actually load everything (blocks of
comments folded away, comments collapsed not because you want them
collapsed but because someone else or maybe just GitHub thought it should
be collapsed, source files not loaded).
GitHub does not allow inline comments further away than a few lines from a
change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210930/4c9a68d5/attachment.html>