[llvm-dev] Target Acceptance Policy

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 26 17:31:15 PDT 2016


> 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 <mailto:mehdi.amini at apple.com>> wrote:
> 
>> On Jul 26, 2016, at 12:16 PM, Renato Golin <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote:
>> 
>> On 26 July 2016 at 20:07, Hal Finkel <hfinkel at anl.gov <mailto: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 <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/20160726/d4b28b47/attachment.html>


More information about the llvm-dev mailing list