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

[Renato Golin via llvm-dev]

On Mon, 7 Dec 2020 at 18:26, Chris Tetreault <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/81d24453/attachment.html>