Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 26 additions & 5 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,18 +10,33 @@ with `git commit -s`.

## Contribution Flow

### Forking

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is kind of redundant, since forking is the standard way to contribute for external contributors, but I'm ok with being verbose.


We recommend forking the dbsp repository and contributing from a fork.
This [page](https://docs.github.com/en/get-started/quickstart/fork-a-repo)
has instructions on how to fork a repository. After forking do not
forget to add dbsp as a remote repository:

```shell
git remote add upstream https://github.com/feldera/dbsp.git
```

### Workflow

This is a rough outline of what a contributor's workflow looks like:

- Create a topic branch from where you want to base your work
- Make commits of logical units
- Make sure your commit messages are in the proper format (see below)
- Push your changes to a topic branch in the repository or a fork if you don't have commit access to (the reason that pushing directly to the repo is preferred is because then CI will be able to add benchmark results to the PR in the comments).
- Push your changes to a topic branch in the repository (push to your fork if
you don't have commit access to the dbsp repository --- pushing directly
to the repo is preferred because then CI will be able to add benchmark
results to the PR in the comments).
- Submit a pull request

Example:

``` shell
git remote add upstream https://github.com/feldera/dbsp.git
git checkout -b my-new-feature main
git commit -a
git push origin my-new-feature
Expand All @@ -35,6 +50,12 @@ When your branch gets out of sync with the feldera/main branch, use the followin
git checkout my-new-feature
git fetch -a
git pull --rebase upstream main
git push --force-with-lease upstream my-new-feature
```

If you don't have permissions replace the last command with

```
git push --force-with-lease origin my-new-feature
```

Expand All @@ -47,15 +68,15 @@ If your pull request contains a single commit or your changes are related to the
amend the commit.

``` shell
git add .
git add <files to add>
git commit --amend
git push --force-with-lease origin my-new-feature
```

If you need to squash changes into an earlier commit, you can use:

``` shell
git add .
git add <files to add>
git commit --fixup <commit>
git rebase -i --autosquash main
git push --force-with-lease origin my-new-feature
Expand All @@ -67,7 +88,7 @@ notification when you git push.
### Merging a pull request

Since we run benchmarks as part of CI it's good practice to preserve the commit IDs of the feature branch
we've worked on (and benchmarked). Unfortunately, [the github UI does not have support for this](https://github.com/community/community/discussions/4618)
we've worked on (and benchmarked). Unfortunately, [the github UI does not have support for this](https://github.com/community/community/discussions/4618)
(it only allows rebase, squash and merge commits to close PRs).
Therefore, it's recommended to merge PRs using the following git CLI invocation:

Expand Down
2 changes: 1 addition & 1 deletion demo/project_demo04-SecOps/simulator/src/main.rs
Original file line number Diff line number Diff line change
Expand Up @@ -522,7 +522,7 @@ fn main() {

println!("Generating repositories");
let repositories = generate_repositories(NUM_REPOSITORIES);
println!("repos: {repositories:#?}");
// println!("repos: {repositories:#?}");
producer.send_to_topic(TOPIC_REPOSITORY, &[repositories]);

println!("Generating commits");
Expand Down