[LLVM] Update cmake maintainer #120542
[LLVM] Update cmake maintainer #120542
Conversation
|
It's a bit weird that I'm still here... I thought @llvm-beanz had taken this over officially some time ago? Maybe I'm mis-remembering? I definitely am not in a good position to be a CMake maintainer as I have very little familiarity with that at this point. Not sure who is in the best position to help here other than Petr though if you don't... One thing that probably would be good to separate from CMake maintenance is the library layering side of this. Historically, this was about helping resolve how dependencies should or shouldn't work and keeping appropriate layering separation from major components of LLVM. That's much less diffuse and heterogeneous than CMake stuff, but not sure who is really active in thinking about those challenges these days? |
I agree that CMake and library layering don't have to go together. In this PR I just dropped the layering part entirely, as I'm not sure it really needs a dedicated maintainer nowadays. The layering is pretty fixed, and the prevalence of non-cmake build systems makes sure that violations are found quickly. If I remember correctly, @chapuni is the person who usually flags and reverts layering violations. |
|
@nikic I can find layering issues since I am watching both cmake and bazel at least in clang-selfhosting related components. I wanted to be a CMake man no longer, though. |
nikic
force-pushed
the
cmake-maintainer
branch
from
68bbd67 to
071cc73
Compare
chapuni
left a comment
chapuni
left a comment
There was a problem hiding this comment.
I could resign if any objections would be there.
| Chandler Carruth \ | ||
| [email protected], chandlerc@google.com (email), [chandlerc](https://github.com/chandlerc) (GitHub) | ||
| Petr Hosek \ | ||
| phosek@google.com (email), [petrhosek](https://github.com/petrhosek) (GitHub) |
There was a problem hiding this comment.
@petrhosek is a fantastic choice for CMake maintainer, but I actually think we probably need more than one maintainer for CMake. LLVM's CMake has really become extremely complex and varied, and there are a lot of changes that go into it (big and small).
I had started and never followed through on creating a set of code owners for CMake which at the time was @petrhosek, @compnerd, @smeenai, @ldionne, @tstellar, and myself. I'd probably add @MaskRay to that list too.
There was a problem hiding this comment.
I agree that we need more CMake maintainers. I'd also include @mstorsjo in your list.
For historical context, even though I was doing all that work to kill autoconf, I deliberately did not want to be the owner. I really enjoyed being able to tell people ether @chandlerc was the code owner so when they had problems they could blame him 😝. Clearly people kept blaming me, so my strategy didn't work. |
chandlerc
left a comment
chandlerc
left a comment
There was a problem hiding this comment.
All of this LGTM -- anything blocking landing it?
Doesn't look like it, I think it's fine to merge! |
9 participants
Currently @chandlerc is listed as the maintainer for "CMake and library layering", but I don't think he has been active in that area in while, so I'd like to find a new maintainer for CMake.
However, I'm not entirely sure who to nominate as a replacement, as CMake changes tend to be very heterogeneous and I'm not sure anyone is really keeping an eye on the big picture. My best guess here is @petrhosek as the person I'd be most likely to add on a cmake review. Feedback welcome!