The problem is that once it’s in community LLVM, it becomes the community’s problem. The expectation is that individual contributors do not break anything in upstream. Why else would you contribute it to the LLVM monorepo? If the goal is just to enable external-to-google orgs to collaborate on it, why not contribute it as a new repo separate from LLVM? You wouldn’t need to ask anybody’s permission to do this.
The problem is that once it’s in community LLVM, it becomes the community’s problem. The expectation is that individual contributors do not break anything in upstream.
I would expect that the community by now has concrete experience with gn gained over a few years demonstrating that this hasn’t been a problem to have this in-tree, without a burden of support on the community.
In particular, I think that a salient point is the guarantee that no public bot would be testing it (I mean here by “no public bot” that no bot would email you when you break it).
Why else would you contribute it to the LLVM monorepo? If the goal is just to enable external-to-google orgs to collaborate on it, why not contribute it as a new repo separate from LLVM? You wouldn’t need to ask anybody’s permission to do this.
Yes, we could do this, and you are correct that in many cases a motivation to upstream a component is to make sure it is maintained by the community and works out of the box.
In this case it is slightly different: we are OK with people to break this. We are already maintaining these files out-of-tree for our own purposes, and this has been the case for years as Sterling mentions. I would even suspect that for Google internal build integration, it is actually easier to have these files internal only rather than unsupported upstream.
So why are we doing it? I mentioned this in another answer: this is mainly to provide a collaboration space for the support of OSS projects using Bazel interested to use LLVM (and some subprojects).
Having them in-tree means that we can publish every day (or more) a git hash that we validate with Bazel on private bots (like gn) and every project can use to clone the LLVM monorepo and integrate in their build flow easily. Another repo, submodules, etc. are not making this possible / practical.