LLVM contributor since 2017 (4900+ commits), ld.lld and Clang Driver code owner, maintainer of a bunch of components
🛠 toolchain
DWARF Standards Committee
Contributed to AArch64, RISC-V, and x86-64 psABIs
---
## 基础设施迁移
大型项目，基础设施很重要
* 2007-06, [CVS => Subversion](https://lists.llvm.org/pipermail/llvm-dev/2007-June/009575.html)
* 2012-10, [Phabricator for code reviews](https://groups.google.com/g/llvm-dev/c/SdcRu4RnqgY/m/VF89M6VfULEJ)
* 2014-04, [http://reviews.llvm.org enabled](https://discourse.llvm.org/t/code-reviews-now-at-http-reviews-llvm-org/31696)
* 2015-08, [lists.cs.uiuc.edu => lists.llvm.org](https://groups.google.com/g/llvm-dev/c/vArHhq9qjvc/m/qBFrfP7yAwAJ)
* 2019-10, [self-hosted Subversion to GitHub](https://llvm.org/docs/Proposals/GitHubMove.html)
* 2021-12, [bugzilla to GitHub issues](https://discourse.llvm.org/t/llvm-bugzilla-migration-is-complete/59445)
* 2022-02, [mailing lists to Discourse](https://blog.llvm.org/posts/2022-01-07-moving-to-discourse/)
* 2023-09, self-hosted Phabricator to GitHub Pull Requests
2019年前的若干年，LLVM社区的基础设施较为风平浪静。最近几年重要迁移工作相继发生
---
## Code review
* Self-hosted
+ Phabricator, Gerrit, Review Board, etc
* Code hosting provider
+ GitHub, Bitbucket, Gitea, GitLab, etc
个人感觉：提供代码托管服务的平台code review服务做得都不太好
---
## Phabricator to GitHub Pull Requests?
* Phabricator
+ 66万行PHP
+ database schema很复杂
+ "Effective June 1, 2021: Phabricator is no longer actively maintained."
+ LLVM's instance, self-hosted, ~500GiB MySQL
* GitHub
+ 用于软件仓库
+ 用于issue tracker
+ 用于code review？
---
## 最有争议性的基础设施迁移工作
* November 2019 [Enable Contributions Through Pull-request For LLVM](https://discourse.llvm.org/t/enable-contributions-through-pull-request-for-llvm/53627)
* January 2020 [Phabricator -> GitHub PRs?](https://discourse.llvm.org/t/phabricator-github-prs/54145)
* November 2020 [Notes from GitHub Pull Requests round table](https://discourse.llvm.org/t/notes-from-github-pull-requests-round-table/56952)
* August 2021 [Phabricator Creator Pulling the Plug](https://discourse.llvm.org/t/phabricator-creator-pulling-the-plug/58775)
* June 2022 [Update on GitHub pull requests](https://discourse.llvm.org/t/update-on-github-pull-requests/71540)
* November 2022 [Pull Request Progress Update](https://discourse.llvm.org/t/pull-request-progress-update/66790)
我相信大多数贡献者都认为GitHub提供了更好的可访问性，不过不少意见指出GitHub明显不如Phabricator。
---
## 易用性
* 我为200多个项目贡献了补丁(许多一次性的)。我感谢使用GitHub的项目，因为我已经熟悉这个系统了。
* 如果一个项目依赖于自托管的系统，我需要投入时间熟悉系统，得在永远不会再次访问的网站上注册用户名。
许多贡献者之前没有使用过 Phabricator，并且会认为该网站和命令行工具arc使用起来具有挑战性。
LLVM社区不缺乏贡献者，缺乏审阅者。决策过少考虑审阅者感受让人感到不适。
Pull Requests推动者向GitHub提交了feature requests以期改进。
---
## 决策透明性
很多人拥护GitHub
2023年6月，LLVM foundation board决定即日起实验GitHub Pull Requests，9月1日只允许Pull Requests。没有讨论这些feature requests的进展
Mailing lists -> Discourse时，有过关于决策透明性的讨论，[LLVM Discourse migration: goals justify means?](https://discourse.llvm.org/t/llvm-discourse-migration-goals-justify-means/59629)
---
## Pull Requests启用啦
因为缺乏演习，有短暂的混乱。
补丁订阅机制是在Pull Requests启用后才引入的。
---
## 补丁订阅机制
每天超过100个commits，任何人几乎不可能监控每一个新的提交。尽管如此，许多人希望随时了解特定组件的变化，因此补丁订阅至关重要。
实现此目的的一种方法是通过邮件列表，例如llvm-commits。该列表包含有关新拉取请求、编辑、GitHub 操作、标签、已解决问题等的电子邮件，使其变得相当嘈杂。
另一种方法是利用代码审查工具。使用 Phabricator，用户可以设置相当复杂的订阅规则，称为 Herald。当补丁标题、描述、受影响的文件或代理用户符合特定条件时，您可以采取一些操作，例如将自己添加为审阅者/订阅者或发送一次性电子邮件。
GitHub不灵活。可以选择查看所有pull requests，但不能选择性地查看。
---
## 定制GitHub Actions提供订阅机制
`.github/workflows/new-prs.yml`
给每个pull request打标签，这些标签用于通知对应的`pr-subscribers-*` team。
需要订阅的人加入team。
谁来处理成员批准请求？Team maintainer or admin。
(假如你错过了成员加入的邮件提醒，除非你访问，其他页面不会提醒。)
---
## 为什么说GitHub Code Review很糟糕
分支对应patch是一个的失败的设计
在email-based system/Phabricator中，代码审阅单元是diff with a tracking tag。你可以任意rebase。Patch的演化检查diff的差异即可。
GitHub围绕分支构建pull requests的概念，并强制执行以分支为中心的工作流程。Base branch和feature branch之间的差异即为pull request的内容。
GitHub 不使用稳定的标识符来进行pull request跟踪。如果commits被rebase、重新排序或合并，GitHub很容易变得混乱。
当rebase后force push时，用户界面会显示一行"force-pushed the BB branch from X to Y"。
单击GitHub中的“compare”按钮会显示`git diff X..Y`的内容，包含上游的不相关的提交。
理想情况下，GitHub应像Phabricator那样仅显示两个补丁文件之间的差异。
对于提交频率较低的项目来说，这些不相关的中间提交可能是可以接受的，但对于每天提交代码频率超过100次的项目来说可能具有挑战性。
在force push后内嵌评论的保真度一直是一个弱点。这些评论可能会被视为“outdated”。
过去有一个臭名昭著的丢失内嵌评论问题。如今，情况有所改善，但仍有一些用户反映内嵌评论有时可能会错位。
---
在大型项目中，避免拉取上游提交可能不现实，因为其他提交经常修改附近的行。有些人使用远程分支来保存他们的工作。必须担心rebase是否会导致邮件提醒噪音使得分支更难以使用。
当处理多个pull requests时，频繁git switch会导致大量浪费的重建。
此外，许多 LLVM 贡献者的一个流行惯例是在实现功能更改之前预先commit改进测试，这也要求force push。有时，只有通过rebase才能注意到补丁由于与另一个已登陆补丁的交互而需要调整更多代码或测试：
* 另一个登陆的补丁添加了一些测试，这些测试将被当前补丁更改。
* 另一个登陆的补丁添加了该功能的新用途，该功能已由当前补丁重命名。
---
## getcord/spr拯救我们！
spr提供了类似arc的功能。
> The principle behind spr is one commit per logical change. Each commit should be able to stand on its own: it should have a coherent thesis and be a complete change in and of itself. It should have a clear summary, description, and test plan. It should leave the codebase in a consistent state: building and passing tests, etc.
```
% spr diff # a PR is created in llvm/llvm-project and the commit message contains "Pull Request" now
% edit ...
% git commit --amend # feel free to amend!
% spr diff
```
开发者可以在 llvm/llvm-project 上创建`users/$username/spr/`分支
---
## GitHub Pull Requests其他缺点
* Fetching a pull request at an old revision can be challenging.
* The narrow display can be somewhat inconvenient.
* Viewing diff and conversations requires switching between tabs.
* Collapsed comments are challenging to locate and often require multiple clicks, makeing it difficult for reviewers to confirm whether a comment has been resolved.
* One cannot comment on a source line a few lines out of the affected lines.
* The inability to search for lines in nearby context when they are not displayed.
* A contributor without write access cannot add reviewers for a pull request.
* A merged pull request cannot be reopened. Let's say the patch has been reverted. In contrast, a closed pull request can be reopened.
* The commit message template does not contain an URI pointing to the pull request. Feature request
---
## Read-only archive
* 2023年12月，我制作了(爬虫timeout导致不完整的)只读归档
* 不可抗力导致Phabricator实例下线
* 小部分 https://reviews.llvm.org/Dxxxxx 页面不可访问。是个替代品，如果你不需要获取讨论。
* 不提供Embedded images
如果有机会重新访问Phabricator，考虑把归档弄得完整些。