[llvm-dev] Target Acceptance Policy

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 26 17:44:39 PDT 2016


I expected the "this can take a while" to be the hint. You may have read it
as "we will accept anything" but I certainly didn't write it.

My answer to Hal should provide you with the context you need. I'll try to
reword that point a bit better tomorrow.

On 27 Jul 2016 1:31 a.m., "Mehdi Amini" <mehdi.amini at apple.com> wrote:

>
> On Jul 26, 2016, at 4:36 PM, Renato Golin <renato.golin at linaro.org> wrote:
>
> I'm most certainly not. Just because I didn't write something, that I
> means I have written the opposite.=
>
> I’m failing to reconcile what you’re claiming above with the following
> that is in your proposal:
>
> "The target's code must have been adapted to the developers policy as well
> as the coding standards. This can take a while and it should be fine to
> accept external
>  code into LLVM as experimental”
>
> I interpret this as "code that does not respect policy and/or coding
> standards should be fine to be committed as experimental”, how should I
> read that?
>
>> Mehdi
>
>
> I could perhaps add "fully adapted" on point 6, to help make it clearer.
> Would that help?
>
> But as with what was said in the code of conduct, exhausting all
> possibilities is not only exhausting, but pointless.
>
> We know how to do code review, we know how to follow the policies, and we
> can collectively take decisions without needing to resort to rules and
> regulations.
>
> This piece is just the last resort, minimum requirements. Not a complete
> description of everything we do.
>
> I really thought this would be a no brainer, that every was on board with
> what everyone already does. Seems I was, again, wrong.
>
> Cheers,
> Renato
>
> On 26 Jul 2016 10:32 p.m., "Mehdi Amini" <mehdi.amini at apple.com> wrote:
>
>>
>> On Jul 26, 2016, at 12:16 PM, Renato Golin <renato.golin at linaro.org>
>> wrote:
>>
>> On 26 July 2016 at 20:07, Hal Finkel <hfinkel at anl.gov> wrote:
>>
>> I think there are different kinds of inflexibility. We will use our
>> collective professional judgment. There are some large-scale design changes
>> that we might decide can happen over time. Whatever we decide to accept,
>> however, needs to be in good shape for what it is and follow our coding
>> conventions.
>>
>>
>> Absolutely. There is a large range of solutions, and we have been most
>> successful on the ones we picked over the years. I think we should
>> continue with the trend.
>>
>> What (I think) I have proposed is nothing different than what we've
>> been doing (ie. I'm not trying to change the status quo).
>>
>> So, if that's not what's coming out, my wording is wrong, please
>> advise. If it is, than I don't think we should argue *now*.
>>
>> I just want to encode what is, and then, once we have something in,
>> working and actively helping people add their targets, we can discuss
>> (in separate) the merits of our current policies.
>>
>>
>> IIUC you are writing specifically that an experimental backend can be
>> integrated without conforming to
>> http://llvm.org/docs/DeveloperPolicy.html#quality ; I don’t think this
>> is a current “policy” but your writing is making it a policy AFAICT.
>>
>>>> Mehdi
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160727/5f5d0777/attachment.html>


More information about the llvm-dev mailing list