hawq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Guo <paul...@gmail.com>
Subject Re: Improve code quality of Apache HAWQ
Date Fri, 02 Dec 2016 03:11:08 GMT
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 <xunzhangthu@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message