[RFC] AI-assisted Bazel Fixer Bot

[nikic]

@asb

I think it doesn’t require two humans in the loop - as you say in the second part of the message this is only the case if you have different expectations/criteria for a commit where the first iteration was LLM originated. But practically speaking these two scenarios have the same level of human review, no?

Yes. But at the same time, I feel like scenario two is not actually better than scenario one, except that it does not require a policy exception. The first scenario represents what is actually going on more faithfully. An AI bot opens a PR, then someone reviews it and maybe pushes additional changes or updates the commit description. We have history of all of these actions.

It’s possible to move these steps before the PR is opened and immediately merged, but it’s not clear to me what the benefit of that approach is (for either the Bazel maintainers or the LLVM project).

Now, I don’t think scenario two is particularly bad either. If we can’t reach an agreement here, then following that process should also be adequate.

@AaronBallman

There’s a fair amount of discussion about whether Bazel should be peripheral or main tier, but I’d like to ask a different question: why should Bazel be in-tree in the first place? CMake is the official way to configure the project to build and is the only thing our community actually supports (we have no community documentation for how to use Bazel with our project); we already removed autoconf support. Bazel seems to be in a similar situation: it’s not required to be maintained by anyone, the need for it seems to predominately exist in a downstream rather than more broadly by our contributors, and it’s now asking for more community input and resources. I think the same question applies to GN. However, maybe I’m missing something – can someone explain to me the community benefit to supporting Bazel in-tree?

I think the answer here is basically the same as for why anything should be in-tree: Being in-tree allows other parties to collaborate. I expect the main user of Bazel is Google, but they are not the only one. If Google just kept this in their downstream fork of LLVM, other people would not be able to make use of that work and would have to duplicate it instead, which is a bad outcome for everyone involved.

(Conversely, I would consider making the Bazel build main-tier completely out of the question, but I think that discussion is off-topic to this thread.)