[llvm-dev] Target Acceptance Policy

[Renato Golin via llvm-dev]

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.

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.

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. 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, 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.

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