Re-cap, after reviews. Main changes: * Making it clear that the "active community" behaviour is expected to continue throughout the target's lifetime. * Making it clear that only a reduced set of violation will be allowed in the experimental phase, providing the maintainers are taking the cost to move it to full compliance. * Trust, but verify: If the target's community doesn't follow these assumptions, the target will be removed. Must haves to be accepted upstream as experimental: 1. There must be an active community behind the target. This community will be the maintainers of 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 behaviour is expected to continue throughout the lifetime of the target's code. 2. The code must be free of contentious issues, for example, large changes in how the IR behaves or should be formed by the front-ends, unless agreed by the majority of the community via refactoring of the (LangRef) *before* the merge of the new target changes, following the IR backwards compatibility described in the developer's policy document. 3. The code has a compatible license, patent and copyright statements, or can be converted to LLVM's own. 4. The target should have either reasonable documentation on how it works (ISA, ABI, etc.) or a publicly available simulator/hardware (either free or cheap enough), so that developers can validate assumptions, understand constraints and review code that can affect the target. Preferably both. To be moved as an official target: 5. The target must have been in the tree for at least 6 months, with active contributions including: adding more tests conforming to the documents, fixing bugs reported by unrelated/generic changes, providing support to other members of the community. 6. The target's code must have been completely adapted to the developers policy as well as the coding standards. Any exceptions that were made to move into experimental mode must have been fixed to become official. 7. The test coverage needs to be broad and well written (small tests, well documented). The build target ``check-all`` must pass with the new target built, and where applicable, the ``test-suite`` must also pass without errors, in at least one configuration (publicly demonstrated, ex. via buildbots). 8. Public buildbots need to be created and actively maintained, unless the target requires no additional buildbots (ex. ``check-all`` covers all tests). The more relevant and public CI infrastructure a target has, the more the LLVM community will embrace it. To continue as a supported and official target: 9. The target maintainer must continue following these rules throughout the lifetime of the target. Violations of the policy will be treated on a case by case basis, but several and continuous violations could be met with complete removal of the target from the code base. I hope that's better. To me, it feels a bit pushy, but people seemed to prefer a bit more rigorous text. We can always change it in the future, of course, and reiterating, this is not intended to change the behaviour of the community (which is already good), but to encode it and show others what do we mean by "target responsibility". cheers, --renato
On Wed, Jul 27, 2016 at 6:25 PM, Renato Golin via llvm-dev < llvm-dev at lists.llvm.org> wrote:> To be moved as an official target: > > 5. The target must have been in the tree for at least 6 months, with > active contributions including: adding more tests conforming to the > documents, fixing bugs reported by unrelated/generic changes, > providing support to other members of the community. >...and this requirement pushes conversion of Lanai back-end to an official target status to Sep 28th as earliest. Just saying. [Personally, I believe that given the level of support, Lanai is already ready for an official status. But if we codify "must have" rules, they should be obeyed by everyone, no? Otherwise, we are setting a very dangerous precedent.] Yours, Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160729/ef6f8f3f/attachment.html>
On 29 Jul 2016 12:00 p.m., "Andrey Bokhanko" <andreybokhanko at gmail.com> wrote:> ...and this requirement pushes conversion of Lanai back-end to anofficial target status to Sep 28th as earliest. Just saying.> > [Personally, I believe that given the level of support, Lanai is alreadyready for an official status. But if we codify "must have" rules, they should be obeyed by everyone, no? Otherwise, we are setting a very dangerous precedent.] I'm not hung up on the fixed number of months. I don't even think it's the best idea, but I was expecting people to give their own ideas... :-) But saying "as soon as they are ready" may be hard to assess. And writing it specific for the Lanai back end would not be appropriate. I'm open to ideas... Please share! :-) --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160729/bafcf53c/attachment.html>
On Fri, Jul 29, 2016 at 2:08 PM, Renato Golin <renato.golin at linaro.org> wrote:> I'm not hung up on the fixed number of months. I don't even think it's the > best idea, but I was expecting people to give their own ideas... :-) > > But saying "as soon as they are ready" may be hard to assess. And writing > it specific for the Lanai back end would not be appropriate. > > I'm open to ideas... Please share! :-) >Well, It's easy to criticize, but much harder to create new ideas... So I specialize in former. :-) I have only two suggestions: 1) Leave the wording as is, and make Lanai an official back-end no earlier than Sep 28th. 2) Downgrade the wording from "must have" to "suggested" and add something like "can be transformed to official status earlier if there is enough support from LLVM maintainers". We can even formalize what "enough support" means -- say, at least three maintainers employed by other companies LGTMed this. Yours, Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160729/3500a1d5/attachment.html>
On 27 July 2016 at 16:25, Renato Golin <renato.golin at linaro.org> wrote:> 5. The target must have been in the tree for at least 6 months, with > active contributions including: adding more tests conforming to the > documents, fixing bugs reported by unrelated/generic changes, > providing support to other members of the community.Trying to re-write based on Andrey's response: 5. The target must have been stable in the tree and have addressed every other minimum requirement for at least 2 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. I think that's better than 6 months because it makes it explicit what is the need for this (cool down period, demonstration of stability), which I personally think it's a very important one and we shouldn't get away with it. It also changes from "landing in tree" to "having addressed all points", so if the back-end lands in tree already fully conforming, there's no point in waiting another 4 months just because. Does that look better? Also, "having addressed the minimum requirements" may end up being subjective, but I think we should keep it that way on purpose. I don't want to have to come up with a "committee of target approval" or anything like that. We're doing well as we do. cheers, --renato