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

[Geoffrey Martin-Noble via llvm-dev]

Thanks everyone. I will move forward with a pitch as part of the proposal
process.

The reason I reopened this as an RFC was because I thought the more general
questions should have been resolved as part of the discussion in Renato's
support policy RFC and that therefore this would not necessarily be
controversial to the point we couldn't resolve it as part of an RFC. (In
particular, some people said their objections were resolved by the
existence of an explicit policy). Apologies that that took this thread in a
direction that lost focus.

On Tue, Dec 8, 2020 at 12:40 PM Eric Christopher <echristo at gmail.com> wrote:

> +Geoffrey Martin-Noble <gcmn at google.com>  and +Tom Stellard
> <tstellar at redhat.com>
>
> In my effort to smooth the process out here I spoke with Tom offline and
> we've agreed that a pitch proposal seems to be the best way forward.  From
> our discussion I believe that he disagrees with adding unsupported build
> systems to llvm and what methodology we should use to determine their or
> similar multiple versions of functionality inclusion (please do correct me
> if I'm wrong here). I think it makes sense to limit the discussion in the
> pitch to adding unsupported build systems.
>
> My personal take on this and why I've been helping shepherd this along:
>
> I believe that we should be enabling other people to do work in llvm as
> long as
>
>  a) it doesn't impact maintainability of the core system (open to debate
> in some ways),
>  b) they have a history/desire to be responsible maintainers, and
>  c) it's easy enough to remove if it becomes an issue.
>
> and that doing this helps llvm be used more easily in other projects; thus
> helping see it's inclusion in more projects, a goal of the project as a
> whole.
>
> Thanks!
>
> -eric
>
> On Sun, Dec 6, 2020 at 7:07 AM Renato Golin <rengolin at gmail.com> wrote:
>
>> On Sun, 6 Dec 2020 at 04:38, Mehdi AMINI <joker.eph at gmail.com> wrote:
>>
>>> It isn't clear to me what makes you say that? You may not have been
>>> involved with it and you may haven't been paying attention at the time, but
>>> it seems unfair to claim that it didn't have scrutiny or it went in without
>>> the usual proper consideration.
>>> In particular it has been discussed on llvm-dev@ like any other
>>> proposal, and the thread was pretty long:
>>> http://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html ; it
>>> also went further with a lightning talk **and** a round-table during a llvm
>>> dev meeting.
>>>
>>
>> Sorry, scrutiny was the wrong word. I meant "trouble". This proposal
>> seems to be having a lot of trouble that GN should have had too. The
>> biggest push back is about adding new build systems, not Bazel versus GN
>> versus CMake.
>>
>> There seems to be a conflict here about adding a secondary build system.
>> The first could be always thought of as an exception, but the second looks
>> very much like a pattern. The way I see it, from one side there's people
>> worried about maintenance and proliferation of code that is not directly
>> related to the LLVM project (like build systems, editor files, etc) and
>> from the other side, there's people saying this has been happening for a
>> long time.
>>
>> I tried to solve that by starting the support policy, but not with the
>> intent to validate the inclusion of GN/Bazel, just to help the discussion
>> move to a consensus. I regret having written GN and Bazel by name, which
>> only now I realise they could be used as leverage for one side of the
>> discussion. It was not my intention, and I don't think we should ignore the
>> issues just because GN has been included already, either.
>>
>> My support for moving this to a document (not necessarily a proposal) is
>> because for most of the original discussion around Bazel, throughout the
>> discussion about the support policy and now the retake on Bazel's
>> inclusions, Tom's points haven't been addressed completely. There seems to
>> be more discussion around semantics, history and precedence than the actual
>> technical details. I'm guilty of that, too, while trying to solve the
>> conflict, and I apologise if the support policy has created more confusion
>> than it solved.
>>
>> I think laying out the issues in a document and discussing the technical
>> aspects over it would make things easier, not harder. If the support policy
>> needs to be amended to clarify that, so be it. We need to document what
>> happens and what we want to happen, not fix some version of the past as a
>> golden standard for the future.
>>
>> But as I always say: whatever works. If you want to continue discussing
>> in this thread, by all means, do go on.
>>
>> cheers,
>> --renato
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201208/7b2b3974/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3992 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201208/7b2b3974/attachment.bin>