Suggestions for easier deployment, adoption and quality

[LowLevelMahn]

only ideas i found in other projects i use and like - i think some of these points are already in work or were discussed on the user meeting

-CMake only builds (try to get rid of Make in the start) - CMake build should be equally easy
-github auto build for Windows/Linux/Macos, clang, gcc, MSYS2/gcc/clang (see dosbox staging or apache arrow)
-clear build instruction for the major operating systems/distributions - package builder of debian,ubuntu,etc. love well prepared stuff :)
building needs to be a finger-snap thing on every major platform

-prepared binary builds for all major platforms
-vcpkg/conan package - to ease the deployment even further
-coverity/PVS statical checks
-auto runs with ASAN/TSAN
-some project even test the build and stuff for the 3-4 major platforms (to be safe that everything is working on a real debian, ubuntu, macos VM installation etc.)
-maybe a docker image with command line playground
-a web kuzu-playground for playing around

https://github.com/dosbox-staging/dosbox-staging is doing parts of that very good

-auto generated Benchmarks (charts on the github page) for usual use cases - i don't know if there is a property graph dabase benchmark suite available for a more "accepted" collection of use cases
speed is definitly a concern right after code quality and functionality

[mewim]

Hi @LowLevelMahn,

Thanks for the suggestions.

CMake only builds (try to get rid of Make in the start) - CMake build should be equally easy

When we added Apache Arrow as a dependency, we actually tried to add it as a CMake external project, but unfortuantely we were not able to get it work, so we switched to use Makefile to build Arrow first and then our project. I agree that this approach is not as elegant as only using CMake. Currently, we are only using Arrow to ingest data and in longer term we plan to replace Arrow with our own CSV and Parquet implementation, which would hopefully get rid of Makefile.

github auto build for Windows/Linux/Macos, clang, gcc, MSYS2/gcc/clang (see dosbox staging or apache arrow)

We do have automatic build pipelines for Windows, Linux and macOS. However, currently we only trigger them manually for releases. We have a plan to also publish nightly builds in our longer term roadmap once the codebase becomes more stable.

clear build instruction for the major operating systems/distributions

Good suggestion. We will add more detailed documentations for dependency installation and build steps.

prepared binary builds for all major platforms

We provide pre-compiled binaries for each of our release for all major platforms, e.g. https://github.com/kuzudb/kuzu/releases/tag/v0.0.4

vcpkg/conan package - to ease the deployment even further

This is not currently on our roadmap, but we can try to provide them if there is an interest.

coverity/PVS statical checks

Good suggestion. We will look into it.

auto runs with ASAN/TSAN

We test each commit using ASAN (e.g. https://github.com/kuzudb/kuzu/actions/runs/5418159709). I think we had a problem configuring TSAN though.

some project even test the build and stuff for the 3-4 major platforms

For our CI we currently test on Ubuntu LTS and Windows for each commit. We do have a plan to test each commit on more platforms in #1699. For each pre-compiled binary, we test on Windows 10 and 11, macOS ARM64 and X86-64, and many popular Linux distros.

maybe a docker image with command line playground

Since our pre-compiled CLIs should work on most of the platforms, we think that the users can simply download the CLI for their platform and start playing with it, which should hopefully be easier than using Docker. We do have download section on our website.

auto generated Benchmarks (charts on the github page) for usual use cases

We run a benchmark suite for each commit and we publish the results to https://benchmark.kuzudb.com/, but since we are still in early stage, we have decided to keep the charts and reports private for now.

[ray6080]

The issue had been inactive for a while. I'm turning this into discussion for now.