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

[Mehdi AMINI via llvm-dev]

On Sat, Dec 5, 2020 at 10:15 AM Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Sat, 5 Dec 2020 at 05:48, Eric Christopher via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> No. I meant every word that I said. The policy encoded existing practice
>> and exactly how we've handled things for years. I'm sorry if this hasn't
>> matched your experiences, as I said, but there's nothing new or radical
>> with what we wrote down. It's what we've intended and how we've meant to
>> act.
>>
>
> Precisely.
>
> I'm not taking personally the statement that "[the policy's] only purpose
> is to provide cover for the existing fact". I have no reason to provide
> cover for Bazel, Geoffrey or Google. I didn't mean to create precedent for
> anything and just wanted to make sure we discuss the technical details with
> the background of how we decide things covered in a policy that would only
> describe what we've done in the past.
>
> I also don't think the inclusion of GN is prior-art. It had a lot less
> scrutiny than the current discussion and it has been largely ignored
> (because nothing wrong happened so far). There are lots of little things
> like that in LLVM that go unnoticed, it's really hard to control such a
> large project without adding unreasonable constraints to the development
> process.
>

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.



> It's exactly because this discussion is again moving into personal remarks
> and making use of "facts" and policies that I'm sure this won't go
> anywhere, again. And this is why I support Tom's idea to turn this into a
> pitch: there are no personal opinions on the document, just facts and
> solutions to problems.
>

I'll repeat myself but: escalating an RFC into a  “LLVM Proposal Process”
requires being able to "describe the controversy" and summarize both sides
of the discussion. I don't see how this is possible without having the
objections being restated.
So far Chris withdrawn his objection in light of the policy you drove:
"Since this is being added within the bounds of a now-existing policy, I
will withdraw my objections".
Stefan reiterated his objection, but I read it as in bound for the policy
rather than really about this proposal (I may be wrong, that's just how I
understand it).

Another issue I see with escalating, is that while the “LLVM Proposal
Process” seems like a way to unblock deadlocks, it isn't clear to me that
it is the best way to find tradeoff and compromise that can be reached
through discussions.
For example there are very good technical questions raised by Tom in the
bullet points in the second part of this email:
http://lists.llvm.org/pipermail/llvm-dev/2020-November/146671.html ; I'm
afraid that these wouldn't be addressed the same way if we just moved on
with a more formal decision process. I don't understand why we shouldn't
make a genuine effort to address the practical aspects here?
-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201205/1e9dce6d/attachment-0001.html>