-
Notifications
You must be signed in to change notification settings - Fork 11
Overview
We don't like process, but it's necessary for coordinating a development team. We have multiple goals for our developer process:
- Ensure the proposed changes are maintainable
- designed properly
- uses consistent coding style
- documented
Issues should be focused and have limited scope. Each issue should conceptually be one thing. It is common for a project to spawn multiple issues. It is also common to have to start work on one issue and then generate multiple issues. Use your best judgement, but in most cases, smaller issues are better than bigger issues.
Create a fork of the latest master branch of the repo. It is absolutely essential that you create a fork of the repository and not clone it since you'll not be able to push the changes you have made in case you have cloned the repository.
If you have an existing fork, we recommend updating it to the current master branch of fmm3dbie or creating a new fork. In order to update your existing fork:
a. Add fmm3dbie and call it upstream
git remote add upstream https://github.com/fastalgorithms/fmm3dbie.git
b. Fetch all branches of remote fmm3dbie
git fetch upstream
c. Rewrite your master using fmm3dbie's master using git's rebase
git rebase upstream/master
d. Push updates to your master or other branches
git push origin master --force
Note that this may overwrite local changes you have on your fork. In case you have local changes, creating a new fork may be a safer alternative.
In your local fork of the fmm3dbie repo, create a branch from master. Replace the # below with the issue number from above.
- If the issue is a bug, then name the branch: bugfix/issue-#-short-description.
- If the issue is a feature, then name the branch: feature/issue-#-short-description.
This should look like:
> git checkout -b feature/issue-#-short-description
Fix the issue on the branch that was created. This branch will be used to create a pull request.
Please limit the fixes on the branch to the issue. If you find yourself fixing other things on the branch: stop, create a new issue, and follow the process to fix that separate issue. Multiple conceptual fixes together on one branch will slow down the time it takes for it to get into the code base and may not get in as-is.
If you're fixing a bug, first create a test that demonstrates the bug. Commit that test (git commit so it gets added to the history). Then fix the issue. The test failure should go away. This test is a necessary condition for getting the patch in.
If you're creating a new feature, then every new piece of code should be tested (with exceptions). Any sections that touch existing code should be tested.
Tip: The commit message for the final commit for the issue should have fixes #N where N is the issue number; that will make sure the issue is closed when the pull request is merged (you can also use closes or resolves in place of fixes).
Before a pull request can make it into the fmm3dbie, it needs to be up to standards. Not all of these apply for every pull request, but for most, it does:
- New / changed code must be tested. There should be new tests.
- All existing tests must pass:
> make test - All new / changed code must be documented.
- Code should adore to the requirements listed in Code quality
Once all of these are taken care of, create a Gitlab pull request. using the Gitlab web interface. You will have to push your branch to origin (Gitlab) first in order for the web interface to know about your branch. Fill out the Pull Request Template. Then hit submit.
Someone on the fmm3dbie development team will look at the code for all of the parameters above.
That should be pretty straightforward.
Before merging, make sure:
tests pass someone on the core team has reviewed the pull request thoroughly someone on the core team has approved of the pull request