Thanks for your interest in contributing to RisingWave! We welcome and appreciate contributions.
This document describes how to submit your code changes. To learn about the development process, see the developer guide. To understand the design and implementation of RisingWave, refer to the design docs listed in docs/README.md.
If you have questions, you can search for existing discussions or start a new discussion in the Discussions forum of RisingWave, or ask in the RisingWave Community channel on Slack. Please use the invitation link to join the channel.
To report bugs, create a GitHub issue.
Before submitting your code changes, ensure you fully test them and perform necessary checks. The testing instructions and necessary checks are detailed in the developer guide.
As described in here, a valid PR title should begin with one of the following prefixes:
feat
: A new featurefix
: A bug fixdoc
: Documentation only changesrefactor
: A code change that neither fixes a bug nor adds a featurestyle
: A refactoring that improves code styleperf
: A code change that improves performancetest
: Adding missing tests or correcting existing testsbuild
: Changes that affect the build system or external dependencies (example scopes:.config
,.cargo
,Cargo.toml
)ci
: Changes to RisingWave CI configuration files and scripts (example scopes:.github
,ci
(Buildkite))chore
: Other changes that don't modify src or test filesrevert
: Reverts a previous commit
For example, a PR title could be:
refactor: modify executor protobuf package path
feat(execution): enable comparison between nullable data arrays
, where(execution)
means that this PR mainly focuses on the execution component.
You may also check out previous PRs in the PR list.
- If your PR is small (such as a typo fix), you can go brief.
- If it is large and you have changed a lot, it's better to write more details.
Contributors will need to sign RisingWave Labs' CLA.
We have a GitHub Action to help cherry-pick commits from main
branch to a release candidate
branch, such as v*.*.*-rc
where *
is a number.
Checkout details at: https://github.com/risingwavelabs/risingwave/blob/main/.github/workflows/cherry-pick-to-release-branch.yml
To trigger the action, we give a correct label to the PR on main
branch :
https://github.com/risingwavelabs/risingwave/blob/main/.github/workflows/cherry-pick-to-release-branch.yml#L10
It will act when the PR on main
branch merged:
-
If
git cherry-pick
does not find any conflicts, it will open a PR to therelease candidate
branch, and assign the original author as the reviewer. -
If there is a conflict, it will open an issue and make the original author the assignee.