hawq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hong Wu <xunzhang...@gmail.com>
Subject Improve code quality of Apache HAWQ
Date Thu, 01 Dec 2016 07:33:06 GMT
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