[llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier

[Chris Tetreault via llvm-dev]

Don’t let Them keep you down. There will always be detractors, but you took concrete action to remove a roadblock to consensus, and I feel that this should be commended. Especially since you did so by writing a bunch of documentation, and I’m sure you had things you’d rather be doing.

I think the policy is pretty good, regardless of the outcome for Bazel.

Thanks,
   Christopher Tetreault

From: Renato Golin <rengolin at gmail.com>
Sent: Monday, December 7, 2020 10:54 AM
To: Chris Tetreault <ctetreau at quicinc.com>
Cc: Mehdi AMINI <joker.eph at gmail.com>; LLVM Dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier

On Mon, 7 Dec 2020 at 18:26, Chris Tetreault <ctetreau at quicinc.com<mailto:ctetreau at quicinc.com>> wrote:
Renato,

   I feel that adding the support policy was useful. The policy documents expectations, and consequences for non-compliance. This eliminates a whole class of objections that, for the most part, are no longer being made. Honestly, I feel like the support policy settled most of the technical arguments. It requires that the Bazel build files be supported, that they not impact the rest of the codebase, and documents at what point they will be removed. I suppose it should go without saying that they should be high quality. All that remains is semantics, history, and precedence.

Thanks Chris! I appreciate the feedback. For a moment there I thought I had made things worse.

   As for escalating to the LLVM proposal process, it seems to me that we have reached an impasse. Stefan seems to be strongly opposed, and as far as I can tell, so are you. I’m not in love with the plan either, though I am prepared to accept any outcome of this RFC at this point. I think Stefan’s objection is valid. Just because we have a policy that enumerates the basic requirements for some non-essential thing to be added, and lists conditions for removal, does not mean that all things that meet the basic requirements should be added. I mean, if “because it meets the basic criteria per the support policy” is enough, then I might as well add an MSBuild project because the one CMake generates isn’t ideal. I’m sure the MS folks that work with LLVM wouldn’t mind a hand-rolled MSBuild project being in tree. I’m sure Apple would like their hand-rolled XCode project back. Maybe the GHC folks want a Shake based build system? There needs to be limits.

Open question: has there?

If (there are a sizable part of the community that uses it) and if (they have substantial cost in maintaining it off-tree) and if (the cost of maintaining it in-tree is very low - or it gets kicked out), then (why not?).

To me, the only final question is backports. My answer to that is two-way:
 1. If this is a standard release, the delta is really low and we can pull those files to fix bugs in code that touches it. This will mainly be a problem in build files, not editor configuration or other scripts.
 2. If this is a point release (backports), then we may decide to not backport if it gets muddy. The risk of having a conflict just because of a build file is really really low, and if it does happen, it will be one fix, not all fixes.

In both cases, if this keeps happening, and a sizable sub-community gets angry about it, then it breaks the contract and needs to be refactored to not break as often, or be removed. Note that "keeps happening" spanning across releases could take years.

Tom, does that answer the questions you had?

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201207/c7b5e88f/attachment.html>