llvm dev - Dec 2020 - RFC: Contributing Bazel BUILD files in the "peripheral" support tier

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201209/4276bf81/attachment.html>

Mehdi, you are welcome to your opinion, just like I and the others.

Fwiw, I think there is daylight between the viewpoint that policies need to
be authoritative and the fact that the very first use of this policy
continues to be controversial in a way that would be good to settle -- both
on the technical and community merits (which are one and the same when it
comes to support costs).

Being perfectly honest, I wrote one of the emails that set us down that
policy path, and I felt that equating editor configs and build systems in a
similar fashion might have been just sightly too far (and relatedly, Renato
also admitted that he regretted listing specifics here). But as I
mentioned, I benefit from this being decided in favor of bazel, and I kept
silent on that feeling.

Now, in this thread, I find that others had the same concern and were also
silent (and felt that the policy may have been a backdoor to approve this
thing).

I still think it's the right thing overall, but build system proliferation
does, historically on many projects, induce creeping support needs. If we
had been able to converge on that point in an RFC, fine. But I'd far prefer
the use of a process to facilitate than a continuing discussion on a
fractious issue that has legitimate, continuing differences of opinion with
respect to the application of a brand new policy whose development was
co-mingled with this one.

Contrary to worrying about too much use of the pitch process, I think it is
incredibly valuable to use it when needed. Decision making processes help
people know that they have a place in the community, and judicious use of
them shows a willingness to engage to a resolution without needing to
one-person-army a force of resistance. Like everything, if later we find
that it is getting used too much or is causing harm, we fix it
incrementally then. For this issue, I think it would help.


On Wed, Dec 9, 2020, 8:46 AM Mehdi AMINI <joker.eph at gmail.com> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201209/c871dffe/attachment.html>

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 <mailto: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 <mailto: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
<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.
> 
> 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
<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 <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/67941681/attachment-0001.html>