> 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>
I expected the "this can take a while" to be the hint. You may have read it as "we will accept anything" but I certainly didn't write it. My answer to Hal should provide you with the context you need. I'll try to reword that point a bit better tomorrow. On 27 Jul 2016 1:31 a.m., "Mehdi Amini" <mehdi.amini at apple.com> wrote:> > 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> wrote: > >> >> On Jul 26, 2016, at 12:16 PM, Renato Golin <renato.golin at linaro.org> >> wrote: >> >> On 26 July 2016 at 20:07, Hal Finkel <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 ; 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/20160727/5f5d0777/attachment.html>
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