<div dir="ltr">Andrey,<div><br></div><div>I may have misunderstood Chandler, but I think it would be good to house libomptarget together with SE in the new project. I suspect he means to leave the option open for the libomptarget developers to choose the best option as they see fit.</div><div><br></div><div>In terms of organization, I would expect the project initially to contain a StreamExecutor directory and a libomptarget directory where each project could work separately.</div><div><br></div><div>When it comes to the difference in review process between the two projects, I don't know the answer. I would expect the new project to handle reviews similar to the way they are handled in the LLVM project itself, so I don't know if there would be any difference compared to what is happening now with libomptarget.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 27, 2016 at 9:32 AM C Bergström <<a href="mailto:openmp-dev@lists.llvm.org">openmp-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I respect Hal's more tactful approach and response..<br>
<br>
Let me play devils advocate for a minute<br>
<br>
1) Yet another programming model - Is the advantage spelled out<br>
somewhere? (I know there are reasons, but I'd like to see a FAQ or<br>
this clearly documented. Examples pretty please.. More for long term<br>
than my own selfish benefit)<br>
2) Is this an "open standard" - If I wanted to propose a major change<br>
to SE - how would I or someone else go about it? OpenMP/ACC have more<br>
or less clearly defined paths for new features.. What's the governing<br>
policy here.. Bug fixes are easy to deal with, but does Google have<br>
final say on the roadmap..<br>
3) When the project is created - will it include lots of good tests?<br>
4) It's probably used internally @google - who else will be using<br>
this? Is the target HPC, Android.. etc<br>
<br>
Lastly - sorry, but I don't like this kick-the-can approach to what<br>
should be proper engineering and planning upfront. Can someone @google<br>
gentleman's promise to actively work on playing nice with other<br>
projects, specifically OpenMP and Intel. From my perspective nothing<br>
stops Google from tossing it up on github or google code and letting<br>
it stay there until all the pieces are in the correct place. Why it<br>
*must* be an llvm project now doesn't make sense to me. When the shoe<br>
was on the other foot (OpenMP) there was all sorts of shit and redtape<br>
Intel (and others) had to jump around to get it included. Google has a<br>
lot of good karma in the llvm community and maybe that's the<br>
difference..<br>
_______________________________________________<br>
Openmp-dev mailing list<br>
<a href="mailto:Openmp-dev@lists.llvm.org" target="_blank">Openmp-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a><br>
</blockquote></div>