Re: [llvm-dev] Phabricator Creator Pulling the Plug
On 10/1/21 2:59 PM, Josh Stone wrote: > On 9/30/21 4:15 PM, Mehdi AMINI via llvm-dev wrote: >> On Thu, Sep 30, 2021 at 4:09 PM Brian Cain wrote: >>> >>> >>> >>> On Thu, Sep 30, 2021, 6:04 PM Brian Cain wrote: Does something like Rust's "bors" bot satisfy the herald rules need? >>> >>> >>> >>> sorry, maybe I was thinking of the high-five bot. And it looks like that's >>> not quite a match for herald. >> >> Actually high-five may be a good starting point! >> In practice it may still be a bit limited by the GitHub integration: >> for example I suspect you may not be able to "subscribe" someone to a >> pull-request? >> Also what the user will receive as an email may be quite unhelpful >> (you have been subscribed to "" instead of the >> current more comprehensive emails). > > You can configure path-based "mentions" like these: > https://github.com/rust-lang/highfive/blob/6e2c21639aaeafaeae423b244d353247c507d46a/highfive/configs/rust-lang/rust.json#L129 > > It will mention those users in a comment, which subscribes them, like: > https://github.com/rust-lang/rust/pull/89266#issuecomment-927275025 > > That one demonstrates both an individual and an org team, and note that > people can choose whether their team membership is publicly visible. Hmm, maybe you can only choose your org visibility, not each team. ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
On 9/30/21 4:15 PM, Mehdi AMINI via llvm-dev wrote: > On Thu, Sep 30, 2021 at 4:09 PM Brian Cain wrote: >> >> >> >> On Thu, Sep 30, 2021, 6:04 PM Brian Cain wrote: >>> >>> Does something like Rust's "bors" bot satisfy the herald rules need? >> >> >> >> sorry, maybe I was thinking of the high-five bot. And it looks like that's >> not quite a match for herald. > > Actually high-five may be a good starting point! > In practice it may still be a bit limited by the GitHub integration: > for example I suspect you may not be able to "subscribe" someone to a > pull-request? > Also what the user will receive as an email may be quite unhelpful > (you have been subscribed to "" instead of the > current more comprehensive emails). You can configure path-based "mentions" like these: https://github.com/rust-lang/highfive/blob/6e2c21639aaeafaeae423b244d353247c507d46a/highfive/configs/rust-lang/rust.json#L129 It will mention those users in a comment, which subscribes them, like: https://github.com/rust-lang/rust/pull/89266#issuecomment-927275025 That one demonstrates both an individual and an org team, and note that people can choose whether their team membership is publicly visible. ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
Hi folks, Arcanist not working any longer is really unfortunate. Phroge also has a fork of Arcanist, however I haven't seen any SSL-related patches: https://we.phorge.it/source/arcanist/browse/master/ 1) Replacement for Herald rules. I suppose the notification problem is solvable. I just took a quick look at the GitHub APIs and wrote a proposal for a quick-and-dirty solution: https://github.com/ChristianKuehnel/llvm-iwg/blob/gerald_design/pull_request_migration/gerald_design.md Concerning privacy and storing user emails this solution is less than ideal. However contributors are already sharing their email addresses in the git logs. If we want to hide all personal information, a simple config file is not enough, then we would need to have some UI where users configure their rules. However this would be an even larger effort (web UI, database, user authentication, Github SSO, ...). I just checked GitHUb's public roadmap and did not find anything that sounds like Herald: https://github.com/github/roadmap/projects/1 Best, Christian ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
I would like to add a third blocker to Mehdi's list: 3) We first would need to finish our ongoing Bugzilla to GitHub Issues migration: At the moment the plan is to use the old bug ID in bugzilla as issue ID on GitHub. However issues and Pull Requests share the same namespace. So once we start using Pull Requests this would eat up the numbers for the bugs/issues. This is certainly not a show stopper, but something to decide on. I see two options here: 1) We delay using Pull Requests until the Bugzilla to Issues migration is completed. 2) We give up the requirement to keep the bug IDs and assign the new IDs as they are available. Best, Christian On Fri, Oct 1, 2021 at 12:56 AM Mehdi AMINI via llvm-dev < llvm-...@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. > > Others may have other items to add! > > -- > Mehdi > > On Thu, Sep 30, 2021 at 3:39 PM Brian Cain via llvm-dev > 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-...@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 On Behalf Of > MyDeveloper Day via llvm-dev > >> Sent: Wednesday, August 18, 2021 10:17 AM > >> To: llvm-dev ; cfe-commits < > cfe-commits@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-...@lists.llvm.org > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > ___ > > LLVM Developers mailing list > > llvm-...@lists.llvm.org > >
Re: [llvm-dev] Phabricator Creator Pulling the Plug
On Thu, Sep 30, 2021, 6:04 PM Brian Cain wrote: > Does something like Rust's "bors" bot satisfy the herald rules need? > sorry, maybe I was thinking of the high-five bot. And it looks like that's not quite a match for herald. > 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 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 >> 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-...@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 On Behalf Of >> MyDeveloper Day via llvm-dev >> >> Sent: Wednesday, August 18, 2021 10:17 AM >> >> To: llvm-dev ; cfe-commits < >> cfe-commits@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-...@lists.llvm.org >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >> > ___ >> > LLVM Developers mailing list >> > llvm-...@lists.llvm.org >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >
Re: [llvm-dev] Phabricator Creator Pulling the Plug
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 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 > 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-...@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 On Behalf Of > MyDeveloper Day via llvm-dev > >> Sent: Wednesday, August 18, 2021 10:17 AM > >> To: llvm-dev ; cfe-commits < > cfe-commits@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-...@lists.llvm.org > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > ___ > > LLVM Developers mailing list > > llvm-...@lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
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-...@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 *On Behalf Of *MyDeveloper > Day via llvm-dev > *Sent:* Wednesday, August 18, 2021 10:17 AM > *To:* llvm-dev ; cfe-commits < > cfe-commits@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-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RE: [llvm-dev] Phabricator Creator Pulling the Plug
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 On Behalf Of MyDeveloper Day via llvm-dev Sent: Wednesday, August 18, 2021 10:17 AM To: llvm-dev ; cfe-commits 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 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
+1 to the review experience in Github being far worse than Phabricator, with basically all my specific concerns already being covered in this thread. I just wanted to add that our downstream LLVM port is based in a local Github Enterprise instance, and I find it far harder to review and respond to reviews there, compared to Phabricator. I'm not just opposed to change because I fear something new - I have active day-to-day experience with the something new, based on several years of experience, and I don't like it! I do acknowledge however, that some things have improved (e.g. multi-line commenting is now a thing, when it didn't used to be), so it's not an "absolutely never" from me, if the issues can be solved. James On Fri, 1 Oct 2021 at 04:11, Mehdi AMINI via llvm-dev < llvm-...@lists.llvm.org> wrote: > On Thu, Sep 30, 2021 at 8:05 PM Hubert Tong > wrote: > > > > On Thu, Sep 30, 2021 at 6:56 PM Mehdi AMINI via cfe-commits < > cfe-commits@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. > > This isn't compatible with stacked commits / stacked PR unfortunately. > Also while merging main back into a branch of commits is "OK", > rebasing multiple commits is much less friendly (the same conflict may > have to be fixed over and over in each commit). > > > 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. > > Thanks! I have the same feeling, but I didn't have anything specific > to point to and figured that this is in the scope of "I'll get used to > it", but you mention some good points here. > > Best, > > -- > Mehdi > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
On Thu, Sep 30, 2021 at 8:05 PM Hubert Tong wrote: > > On Thu, Sep 30, 2021 at 6:56 PM Mehdi AMINI via cfe-commits > 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. This isn't compatible with stacked commits / stacked PR unfortunately. Also while merging main back into a branch of commits is "OK", rebasing multiple commits is much less friendly (the same conflict may have to be fixed over and over in each commit). > 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. Thanks! I have the same feeling, but I didn't have anything specific to point to and figured that this is in the scope of "I'll get used to it", but you mention some good points here. Best, -- Mehdi ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
On Thu, Sep 30, 2021 at 6:56 PM Mehdi AMINI via cfe-commits < cfe-commits@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. ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
On Thu, Sep 30, 2021 at 4:09 PM Brian Cain wrote: > > > > On Thu, Sep 30, 2021, 6:04 PM Brian Cain wrote: >> >> Does something like Rust's "bors" bot satisfy the herald rules need? > > > > sorry, maybe I was thinking of the high-five bot. And it looks like that's > not quite a match for herald. Actually high-five may be a good starting point! In practice it may still be a bit limited by the GitHub integration: for example I suspect you may not be able to "subscribe" someone to a pull-request? Also what the user will receive as an email may be quite unhelpful (you have been subscribed to "" instead of the current more comprehensive emails). > > >> >> 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 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 >>> 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 >>> > 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 On Behalf Of >>> >> MyDeveloper Day via llvm-dev >>> >> Sent: Wednesday, August 18, 2021 10:17 AM >>> >> To: llvm-dev ; cfe-commits >>> >> >>> >> 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
Re: [llvm-dev] 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 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 > 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 On Behalf Of MyDeveloper >> Day via llvm-dev >> Sent: Wednesday, August 18, 2021 10:17 AM >> To: llvm-dev ; cfe-commits >> >> 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-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
On Tue, 24 Aug 2021 at 17:30, James Y Knight wrote:
> Yes, the Gerrit hosting which Go uses ("googlesource.com") only permits a
> google-account login as a matter of policy. But that's not a restriction of
> Gerrit itself -- it can perfectly well be configured to use a github login.
>
Ah, awesome!
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
On Tue, Aug 24, 2021 at 7:33 AM Renato Golin wrote:
> The main problem with that (Go) solution is that the Gerrit install
> doesn't single-sign-on with Github accounts, it asked me for my Google
> account. We shouldn't ask people to create more accounts if we want
> integration with Github. I guess this is just a configuration issue, right?
>
Yes, the Gerrit hosting which Go uses ("googlesource.com") only permits a
google-account login as a matter of policy. But that's not a restriction of
Gerrit itself -- it can perfectly well be configured to use a github login.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
On Tue, Aug 24, 2021 at 8:18 AM Renato Golin wrote: > > On Tue, 24 Aug 2021 at 12:49, Aaron Ballman wrote: >> >> > A minor issue is that the messages Gerrit sends to Github are a bit >> > pointless "Message from PersonA: (1 comment)". It would be better if the >> > integration either works (like adding comments to a specific line or >> > updating the commits) or not pollute. >> >> Also, the Gerrit review process uses a different workflow than the >> Phabricator review process, and we should make sure we're comfortable >> with that. My uses of Gerrit (which have been purely corporate in >> nature, so my experience may be with an older version of the tool) >> have run into some pretty big usability concerns -- like the fact that >> it only shows you the diff contents of one file at a time, lacks the >> ability to "stack" related patches, comments are easier to lose track >> of when updating a review, there's no way to mark comments as "done" >> or not, etc. > > > Right, my comment was about the integration, not Gerrit vs Phab vs Github. Ah, apologies! > Whatever integrates with Github should be more succinct, clearer and re-use > Github's ID. +1, that would be great. ~Aaron ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
On Tue, 24 Aug 2021 at 12:49, Aaron Ballman wrote: > > A minor issue is that the messages Gerrit sends to Github are a bit > pointless "Message from PersonA: (1 comment)". It would be better if the > integration either works (like adding comments to a specific line or > updating the commits) or not pollute. > > Also, the Gerrit review process uses a different workflow than the > Phabricator review process, and we should make sure we're comfortable > with that. My uses of Gerrit (which have been purely corporate in > nature, so my experience may be with an older version of the tool) > have run into some pretty big usability concerns -- like the fact that > it only shows you the diff contents of one file at a time, lacks the > ability to "stack" related patches, comments are easier to lose track > of when updating a review, there's no way to mark comments as "done" > or not, etc. Right, my comment was about the integration, not Gerrit vs Phab vs Github. Whatever integrates with Github should be more succinct, clearer and re-use Github's ID. ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
On Tue, Aug 24, 2021 at 7:33 AM Renato Golin via cfe-commits wrote: > > On Mon, 23 Aug 2021 at 18:56, James Y Knight wrote: >> >> If phabricator/phorge do turn out to be non-viable in the future, I think we >> may want to reopen the option of moving to Gerrit for the primary >> code-review platform. >> >> I'll note that the Golang folks are using Gerrit as their review platform, >> and they have a GitHub bot setup to translate GH pull-requests into a gerrit >> review, so as to be friendly to first-time or drive-by contributors. See >> e.g. https://github.com/golang/go/pull/47766 for an example. > > > Honestly, this is a thing we can do regardless of which tool we use. > > There are other tools that integrate with Github more closely that Anton was > looking at, but I think none of them had the functionality we needed (which > both Phab and Gerrit do). > > The main problem with that (Go) solution is that the Gerrit install doesn't > single-sign-on with Github accounts, it asked me for my Google account. We > shouldn't ask people to create more accounts if we want integration with > Github. I guess this is just a configuration issue, right? > > A minor issue is that the messages Gerrit sends to Github are a bit pointless > "Message from PersonA: (1 comment)". It would be better if the integration > either works (like adding comments to a specific line or updating the > commits) or not pollute. Also, the Gerrit review process uses a different workflow than the Phabricator review process, and we should make sure we're comfortable with that. My uses of Gerrit (which have been purely corporate in nature, so my experience may be with an older version of the tool) have run into some pretty big usability concerns -- like the fact that it only shows you the diff contents of one file at a time, lacks the ability to "stack" related patches, comments are easier to lose track of when updating a review, there's no way to mark comments as "done" or not, etc. ~Aaron > > Same goes for bug tracker... > > cheers, > --renato > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
On Mon, 23 Aug 2021 at 18:56, James Y Knight wrote: > If phabricator/phorge do turn out to be non-viable in the future, I think > we may want to reopen the option of moving to Gerrit for the primary > code-review platform. > > I'll note that the Golang folks are using Gerrit as their review platform, > and they have a GitHub bot setup to translate GH pull-requests into a > gerrit review, so as to be friendly to first-time or drive-by contributors. > See e.g. https://github.com/golang/go/pull/47766 for an example. > Honestly, this is a thing we can do regardless of which tool we use. There are other tools that integrate with Github more closely that Anton was looking at, but I think none of them had the functionality we needed (which both Phab and Gerrit do). The main problem with that (Go) solution is that the Gerrit install doesn't single-sign-on with Github accounts, it asked me for my Google account. We shouldn't ask people to create more accounts if we want integration with Github. I guess this is just a configuration issue, right? A minor issue is that the messages Gerrit sends to Github are a bit pointless "Message from PersonA: (1 comment)". It would be better if the integration either works (like adding comments to a specific line or updating the commits) or not pollute. Same goes for bug tracker... cheers, --renato ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
If phabricator/phorge do turn out to be non-viable in the future, I think we may want to reopen the option of moving to Gerrit for the primary code-review platform. I'll note that the Golang folks are using Gerrit as their review platform, and they have a GitHub bot setup to translate GH pull-requests into a gerrit review, so as to be friendly to first-time or drive-by contributors. See e.g. https://github.com/golang/go/pull/47766 for an example. On Mon, Aug 23, 2021 at 1:38 PM Renato Golin via llvm-dev < llvm-...@lists.llvm.org> wrote: > On Wed, 18 Aug 2021 at 18:17, MyDeveloper Day via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> 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 >> > > I think we have our own self-hosted version and enough local people that > has hacked on it to "maintain" it, but we'd stop getting the updated from > upstream, which have been substantial over the years. > > I don't think this should be a rush to replace with an alternative, as > there is no imminent peril, but it is an additional important point for the > ongoing discussion of potential transition. > > 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. >> > > IMO, it would have to be seriously active upstream, understand our > existing database "as is" and import without problems, and interface with > Github more closely to be worth the hassle of migration. > > Github pull requests don't seem to be improving a lot, so "phorge" may be > the right answer sooner than they catch up... > > cheers, > --renato > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Phabricator Creator Pulling the Plug
On Wed, 18 Aug 2021 at 18:17, MyDeveloper Day via llvm-dev < llvm-...@lists.llvm.org> wrote: > 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 > I think we have our own self-hosted version and enough local people that has hacked on it to "maintain" it, but we'd stop getting the updated from upstream, which have been substantial over the years. I don't think this should be a rush to replace with an alternative, as there is no imminent peril, but it is an additional important point for the ongoing discussion of potential transition. 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. > IMO, it would have to be seriously active upstream, understand our existing database "as is" and import without problems, and interface with Github more closely to be worth the hassle of migration. Github pull requests don't seem to be improving a lot, so "phorge" may be the right answer sooner than they catch up... cheers, --renato ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
