[llvm-dev] Target Acceptance Policy

[Mehdi Amini via llvm-dev]

> On Jul 26, 2016, at 2:58 AM, Renato Golin <renato.golin at linaro.org> wrote:
> 
> On 26 July 2016 at 04:46, Mehdi Amini <mehdi.amini at apple.com> wrote:
>> I don’t make sense of this, so I guess we are not talking about the same
>> thing.
> 
> I think I know what it is... :)
> 
> 
>> Moving from experimental to non-experimental is a one-line patch
>> while all the pieces are glued together in-tree, and I don’t see any
>> practical way to have some modular review of a backend *after* this
>> happened.
> 
> You're assuming there will be no code review on the back-end and we'll
> accept spaghetti code because the "policy" doesn't say anything about
> it. I understand why you see it that way, as it's not explicit.

No, the problem is that your writing is making an exception to the developer policy, and I don’t think it is a good thing.

> 
> But as with all policies, we'd better encode the bare minimum than the
> most complete picture, as there will always be edge cases we can't
> predict.

There is no edge cases in question here.

> What *normally* happens is that, during the first review (bulk
> import), people point out several problems with the code. Style
> issues, bad tests, bad patterns, misconceptions, etc. All of those are
> generally fixed pre-import, if they're simple, or marked as FIXME if
> more elaborate.

What kind of conformance to "developers policy as well as the coding standards” is too elaborate to be fixed pre-import?
I don’t think any, so I don’t see why this should be deferred.


> There is no ratio for that, it can be all easy, or
> many hard, and it will depend on the case. If we make all rules fixed
> at maximum, we will lose the ability to import code and evolve with
> time.
> 
> One of the key points, and the first one indeed, is that the community
> has to be pro-active and nice. If we request a bunch of changes, they
> don't change and request to be made official

I have a totally different opinion: they submit a patch, we request changes, and if they don’t the code never gets in tree in the first place.

> , then they have failed
> the first and most important rule.
> 
> OTOH, if we failed to spot the problems in the first bulk, and later
> accept a bad target as official, than it would be our own fault.

Asking as much separate patches as possible is part of making sure it does not happen.

— 
Mehdi


> 
> We can add a note describing the FIXME approach if people think it
> will make things more clear, but essentially, the intent is in there
> already. I'm ok with being more explicit, though, just not more
> strict.
> 
> cheers,
> --renato