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

Tue Dec 8 19:19:24 PST 2020

On Tue, Dec 8, 2020 at 7:09 PM Tom Stellard <tstellar at redhat.com> wrote:

> On 12/8/20 5:46 PM, Mehdi AMINI wrote:
> >
> >
> > On Tue, Dec 8, 2020 at 12:40 PM Eric Christopher <echristo at gmail.com
> > <mailto:echristo at gmail.com>> wrote:
> >
> >     +Geoffrey Martin-Noble <mailto:gcmn at google.com>  and +Tom Stellard
> >     <mailto: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.
> >
> >
> > I still have strong concerns here: "he disagrees with adding unsupported
> > build systems to llvm".
> > It seems that you're going for a pitch which is 1) not about this
> > proposal in particular and 2) about a point that has been explicitly
> > discussed and written down in the "community support policy".
> >
> > This also somehow does not align with Tom's last email in this thread:
> >
> >  > My understanding of the policy is that these categories of things
> > still need to be approved in order to be added to the tree.
> >
> > This acknowledged the policy, and I believe acknowledged that each
> > individual proposal is discussed on its own merits. The opposition
> > solely based on the principle of disagreeing "with adding unsupported
> > build systems to llvm" is completely off here. Why are we writing our
> > community policy as a guideline of what is/isn't OK if we have to
> > escalate continuously?
> > I still strongly believe that this is not an OK strategy here.
> >
>
> I don't think we should have alternative build systems in tree.  I am
> not the only one who has expressed concerns about this.  I also don't
> think me or anyone else should be able to unilaterally NAK a proposal.
> This is why I am suggesting that we use the LLVM Proposal Process.
>
> I really don't want to spend any more time debating this on the mailing
> list, because I don't think we are making any forward progress.  If you
> believe my objections are not in line with the existing policy, then
> feel free to move forward with this as an RFC.
>

I believe the policy is *very explicit* and leaves no doubt on the topic
right now, it explicitly mentions alternative build systems.
I don't understand why you didn't raise your concern with respect to the
policy.

I mostly object to the fact that this proposal can't be discussed on it's
own because you're addressing your disagreement with the policy in this
thread and in the context of this proposal.
If you think that we shouldn't have any alternative build systems in tree,
then I believe that you should start an RFC (/proposal) to amend the policy
instead.
I also believe that it is also perfectly fine to put this current RFC on
hold in order to address your more general objection (if you want to pursue
such a proposal). This seems like it would have to address the existence of
GN build files.

Best,

-- 
Mehdi

>
> In the end, I'm just giving my opinion on what I think is in the best
> interest of the community.  It is OK with me if other people disagree or
> the community decides to go another direction.  I know not everyone has
> the same perspective as me, and different perspectives are what make
> communities strong.
>
> -Tom
>
>
>
>
>
> > Best,
> >
> > --
> > Mehdi
> >
> >
> >     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
> >     <mailto:rengolin at gmail.com>> wrote:
> >
> >         On Sun, 6 Dec 2020 at 04:38, Mehdi AMINI <joker.eph at gmail.com
> >         <mailto: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/20d54803/attachment-0001.html>