Hong, Thanks for the long-list advice. About style. It is more than simple pg style or indent issue. It should include more: e.g. naming convention, at least I have saw two naming style in a file I just happen to check, cdbpartition.c selectHashPartition() build_rename_part_recurse() Line limit. tab or space for #define, lines with function arguments? enforce { or } or not for branch with even single clause? return type of a function in separate line? .......
I suspect pgindent is not enough. 2016-12-01 15:33 GMT+08:00 Hong Wu <xunzhang...@gmail.com>: > Hi HAWQ developers and users, > > This thread means to collect ideas and suggestions for the improvement of > code quality of Apache HAWQ. Although some work might be trivial, I think > they are super important to the future development of HAWQ project. > > There are some of finished works related to this purpose, but we need to do > this in a more clear way with long goal and benefits. I try to list some of > the aspects for this in my mind: > > - Fix compiling warnings under Osx and Linux. Whether it is safe to open > the "-Werror" is another story, but we need to fix compiling warnings > firstly for HAWQ to minimize the potential bugs. This week, I met a > time-consuming bug in HAWQ which can be pre-detected with compiling > warning. > (related JIRAs: HAWQ-1043 <http://issues.apache.org/jira/browse/HAWQ-1043 > >, > link thread: "enforce -Werror (if gcc) in hawq") > > - Unify the coding style of HAWQ. We might write hawqdev.vim or > hawqdev.emacs for developers to use. Also, we should honor the tools inside > our CI system to check the coding style of pull requests such as pgindent > <https://github.com/apache/incubator-hawq/blob/master/ > src/tools/pgindent/pgindent> > and > pgcppindent > <https://github.com/apache/incubator-hawq/blob/master/ > src/tools/pgindent/pgcppindent> > . > > - Improve code coverage rate, open source coverage report for community > users. Let them feel more comfortable to use HAWQ. > > - Fix static checking defects such as from Clang Analyzer report > <http://xunzhangthu.org/tmp/hawq_check/> or Coverity report > <https://scan.coverity.com/projects/apache-incubator-hawq>. For Coverity, > we should mark the known defect at very first use. The current status for > Coverity check is manually built and uploaded, we need to make it > auto-triggered in a certain branch with batch of commits every time. > (related JIRAs: HAWQ-939 <https://issues.apache.org/jira/browse/HAWQ-939>, > HAWQ-599 <https://issues.apache.org/jira/browse/HAWQ-599>, HAWQ-506 > <https://issues.apache.org/jira/browse/HAWQ-506>, HAWQ-508 > <https://issues.apache.org/jira/browse/HAWQ-508>, HAWQ-393 > <https://issues.apache.org/jira/browse/HAWQ-393>, HAWQ-263 > <https://issues.apache.org/jira/browse/HAWQ-263>, HAWQ-264 > <https://issues.apache.org/jira/browse/HAWQ-264>) > > - Improve Travis CI scripts(for example add running feature test), deliver > concourse scripts inside HAWQ repo, let HAWQ users feel the magic pipeline. > (related JIRAs: HAWQ-597 <https://issues.apache.org/jira/browse/HAWQ-597>, > HAWQ-873 <https://issues.apache.org/jira/browse/HAWQ-873>, HAWQ-1150 > <https://issues.apache.org/jira/browse/HAWQ-1150>) > > - Refactor HAWQ with separate modules to help developers write painless > unit tests when checking in codes. This work could also help HAWQ apply new > features from upstream Postgres. It's very difficult to do, but I think it > is necessary and we need discuss more. > > - Replace Autotool build system with others. For example, Cmake or Bazel. > Autotool is against its original design and HAWQ's current build system is > kind of chaotic. I think the reason for this is the bad implementation > building system of Postgres itself, but we could to improve this. Our > purpose is letting the system simple to use/debug. > > The thread is a little bit broad, we can also discuss detailed aspects with > separating threads while this one might be a good start. > > Thanks, > Hong >