[llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier
Tom Stellard via llvm-dev
llvm-dev at lists.llvm.org
Tue Dec 8 19:31:19 PST 2020
On 12/8/20 7:19 PM, Mehdi AMINI wrote:
>
>
> On Tue, Dec 8, 2020 at 7:09 PM Tom Stellard <tstellar at redhat.com
> <mailto: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>
> > <mailto:echristo at gmail.com <mailto:echristo at gmail.com>>> wrote:
> >
> > +Geoffrey Martin-Noble <mailto:gcmn at google.com
> <mailto:gcmn at google.com>> and +Tom Stellard
> > <mailto:tstellar at redhat.com <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.
>
I'm not going to write my own RFC/proposal, so you don't need to put
this RFC on hold.
-Tom
> 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>
> > <mailto: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>
> > <mailto: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
> >
>
More information about the llvm-dev
mailing list