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

Wed Dec 9 21:40:54 PST 2020

Agreed. As a practical point of human dynamics, my view is that as a group
diversifies in its membership, perspective and motivations, it becomes
increasingly impractical for peer-to-peer consensus to be the only way to
resolve discussions. As a relatively new member of the community, I find it
comforting to know of the existence of such a process and the fact that the
community feels that they can use it/trust it prior to the point that real
damage gets done.

Mehdi: I don't think there is any problem continuing to discuss those
technical points. In fact, it may be easier to do so now that we are making
a point to move past there being two sides to the debate that may feel a
bit entrenched. If any further clarity emerges, that seems like it would
enhance the proposal.

On Wed, Dec 9, 2020 at 3:26 PM Chris Lattner <clattner at nondot.org> wrote:

> I don’t think there is any negative connotation to escalating to the
> proposal process.  We should do this more often to make progress on things
> like this.
>
> -Chris
>
> On Dec 9, 2020, at 8:45 AM, Mehdi AMINI via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Stella,
>
> I don't understand why this would be a deadlock here: the thread has been
> mostly centered around the fact of "having a pitch or not having a pitch",
> as well as a meta-point covered in the policy. Escalating to the “LLVM
> Proposal Process” (pitch) for these reasons sets a really bad precedent in
> my opinion. If you move into the “LLVM Proposal Process”, I'll insist that
> the pitch is clearly centered about the merits and technicality of this
> proposal itself and *not* about the meta-point that is explicitly covered
> by the policy. We shouldn't have to revisit the entire policy every time
> there is any addition to the project.
>
> --
> Mehdi
>
>
>
> On Tue, Dec 8, 2020 at 11:21 PM Stella Laurenzo via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> +1 to making this a pitch - This thread seems deadlocked to me (with
>> plenty of evidence that everyone is acting in what they see is in the best
>> interests of the community and having a legitimate disagreement). In my
>> experience, as well, when a discussion gets to this phase and there is
>> still a strong objection by one or two parties still willing to make it
>> (which can be exhausting to hold such lines), there are almost always more
>> people who share the viewpoint but don't want to get involved. Best to
>> follow a real process towards resolution when things get to that level. I
>> dislike discussions of attrition and would welcome a process for resolving
>> this one. We feel uncomfortably close to attempting to "get this through on
>> a technicality" (full disclosure: I would benefit from such an outcome),
>> and I don't think that would be a success -- it is alienating. We've got a
>> process for deciding such things. Let's use it and then live with the
>> outcome.
>>
>> On Tue, Dec 8, 2020 at 4:01 PM Geoffrey Martin-Noble via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> 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
>>>>>
>>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201209/f3f32cc4/attachment-0001.html>