Ming's comment makes sense, but I think it is another thread. I have already tried those[1] but there are some further works need to do[2].
[1] - clang analysis scan report: I uploaded the result of not that fresh HAWQ in my personal link, please check the report out here <http://xunzhangthu.org/tmp/hawq_check> if you are interested. - coverity scan: the latest reported is here <https://scan.coverity.com/projects/apache-incubator-hawq>. If you want to see the defects in detail, you need to submit a permission request. [2] - Make clang analysis scan reported generating periodically and publishing to the public automatically. I suggest we donate a domain such as hawq.io and a host for it, also for automatically publishing the report, we need to write a web service to reply the requests and transmitting html data. - Travis CI script have already integrated the coverity scan service using github webhook. we need to create a coverity_scan branch for hawq and then modify the .travis.yml file. I have done that under Redhat environment. While the only environment Travis server supports for Linux is Ubuntu/Debian. Although hawq could be built under Ubuntu, it needs extra effort to extend the .travis.yml script to support that. For osx environment, I am not sure what the problem is, the issue is that the report could not be sent to the coverity scan server automatically. ps: I think Chunlin <https://github.com/wcl14> is starting working on the defects generated by coverity. Back to main thread mentioned by Paul, I think we should just try to open the flag and discuss errors after opening -Werror. Best Hong 2016-09-05 21:51 GMT+08:00 Ming Li <[email protected]>: > Good suggestion. > > However, IMHO, we may need to firstly enable coverity scan check or clang > analysis scan. Also we should make the output of these check on a public > server so that all contributor can access them. > > On Mon, Sep 5, 2016 at 6:05 PM, Paul Guo <[email protected]> wrote: > > > -Werror > > Make all warnings into errors. > > I've seen many cases (not just hawq) before that ignoring gcc warning > leads > > to bugs. I'm wondering we should add the option for the gcc case. Given > > there may be a lot of warnings when building the common postgres code in > > hawq, we could at least enforce it in our own code at first > > (src/backend/cdb, src/backend/resourcemanager, src/test/feature, other > > directories?)? Any suggestion? > > >
