This corresponds to the RFC posted to Discourse proposing changes for code ownership in both Clang and clang-tidy, which can be found at: https://discourse.llvm.org/t/rfc-proposed-changes-to-clangs-code-ownership/64813.
Details
Details
Diff Detail
Diff Detail
Event Timeline
| clang-tools-extra/CODE_OWNERS.TXT | ||
|---|---|---|
| 8 | As LLVM is officially hosted on GitHub now, I wonder whether a new field should be introduced for GitHub handles. This can be also handy to assign bugs to people, and in the future, add reviewers to PRs. But feel free to ignore this for now. | |
| clang-tools-extra/CODE_OWNERS.TXT | ||
|---|---|---|
| 8 | FWIW, I thought of that as well and I think it's a great idea if/when we switch to GitHub PRs. But for the moment, I worry that putting GH handles might implicitly encourage people to try filing a GH PR instead of Phab and I didn't want new folks to get frustrated by that. But once we're closer to switching (or starting to trial GH PR alongside Phab reviews), I definitely think we should add GitHub handles here (and if/when we drop Phab, we can drop the phab handles at that time). | |
| clang/CODE_OWNERS.TXT | ||
|---|---|---|
| 30 | N: Matheus Izvekov | |
| clang/CODE_OWNERS.TXT | ||
|---|---|---|
| 10 | I can also help with Modules & Serialization. Maybe more with deserialization and incorporating the deserialized AST with existing AST. | |
Comment Actions
Moving to GitHub PRs is the path forward. Let's save ourselves some work and add GitHub usernames now.
Comment Actions
Because I'm touching this file so much anyway to add the GitHub handles, I had some ideas I wanted to float to see if others thought they were worthwhile:
- I'd like to rearrange the file so that we don't organize it by surname (slightly problematic given that not everyone has a surname or goes by their given name anyway) but instead organize it by component. I think most of the people who are going to be interested in the contents of this file are going to be looking for a component to find a name instead of looking for a name to find a component.
- I'd like to convert the file to RST format. This not only gives us some nicer ways to categorize the file contents, but it also makes it easier to publish this file on the website along with our other developer policy documentation.
- It gives us a nice way to organize former code owners without making it more difficult to find active code owners (I did not try to find all former code owners)
This latest patch shows you what I have in mind for the changes. I'm not strongly tied to making the file into RST as that does reduce the readability of the text file somewhat, but I think the benefits to making this documentation more public outweigh the downsides to using markup.
(If someone knows of a way to get RST to style headings that are cut off the local table of contents due to the :depth: annotation, that would be lovely. Right now, the third level headings are as visually distinct as I'd like because the local table of contents is limited to two levels of nesting.)
| clang/CodeOwners.rst | ||
|---|---|---|
| 226 | ||
As LLVM is officially hosted on GitHub now, I wonder whether a new field should be introduced for GitHub handles. This can be also handy to assign bugs to people, and in the future, add reviewers to PRs. But feel free to ignore this for now.