[llvm-dev] [RFC] AAP Backend
Renato Golin via llvm-dev
llvm-dev at lists.llvm.org
Fri Aug 26 09:09:54 PDT 2016
On 26 August 2016 at 16:58, Mehdi Amini <mehdi.amini at apple.com> wrote:
> This was addressed in Alex’s email: " In the past, the only exception I can think of is the Lanai backend, but in that case we have a strong commitment of multiple employees at a major corporation committed to that target's maintenance.”.
So, are we picking features based on company size, now? That doesn't
make much sense in an open source project...
The current policy states:
"There must be an active community behind the target. This community
will help maintain the target by providing buildbots, fixing bugs,
answering the LLVM community’s questions and making sure the new
target doesn’t break any of the other targets, or generic code. This
behavior is expected to continue throughout the lifetime of the
target’s code."
No mention about the size or the amount of money their companies have,
nor demands it to be a company at all.
> I don’t think the 3 months cool down period replaces in any way this pre-evaluation.
> If a single developer / single user of a virtual architecture is active enough for 3 months that nothing really breaks, it does not make it an “active community”.
Er... This is what the current policy states:
"The target must have addressed every other minimum requirement and
have been stable in tree for at least 3 months. This cool down period
is to make sure that the back-end and the target community can endure
continuous upstream development for the foreseeable future."
If everyone else's code don't break their stuff, or if every breakage
is met with prompt fix and improvement on the test suite, it doesn't
matter how many people, who or how many they are.
If nothing really breaks after 3 months it means that their back-end
is really pretty well isolated and hardened to cope with most
front-end and middle end changes that will be thrown at them at
considerable volumes. That sounds pretty good to me.
cheers,
--renato
More information about the llvm-dev
mailing list