Skip to content

Latest commit

 

History

History
100 lines (63 loc) · 2.73 KB

pull_request.rst

File metadata and controls

100 lines (63 loc) · 2.73 KB

Submit a Pull Request

This gives a brief and necessary PR flow that a newer developer should follow before starting any task.

This is a reference to submit a CVM pull request. Before submit or development, please ask your leader for the base branch of the project starting from, which is the branch you need to diverse via the git checkout command, such as master, etc.

Then what's your job is:

  1. Checkout your base branch(almost other's branch that have
    existed) to migrate the newest source code.
git checkout [base branch]
git pull
  1. After that, verify
  • Before submit or development, please synchronize your code on the most recent version of your branch, you can do it by

    git checkout [your branch]
    git pull
  • Also, please keep up with the [base branch] and merge if needed by

    git merge origin/[master branch]
  • If conflicts occur after merge, fix them before submit.

  • After development, make sure code style check pass by typing the following command, and all the existing test-cases pass.

    # Reformating python modules
    pylint [your python file]
  • Add test-cases to cover the new features or bugfix the patch introduces, the locations of test files are enumerated as follows:
Module Name Test File Directory
cvm-runtime ./test
CVM python interface ./test/python
MRT ./test/mrt
  • Push your code to the remote repo by:

    # Set upstream if it's first time to push [your branch]
    git push --set-upstream origin [your branch]
    git push
  • Send the pull request and fix the problems reported by automatic checks (if existed).

  • Request code reviews from other contributors and improves your patch according to feedbacks.

    • To get your code reviewed quickly, we encourage you to help review others' code so they can do the favor in return.
    • Code review is a shepherding process that helps to improve contributor's code quality. We should treat it proactively, to improve the code as much as possible before the review. We highly value patches that can get in without extensive reviews.
    • The detailed guidelines and summarizes useful lessons.
  • The patch can be merged after the reviewers approve the pull request.