We sincerely appreciate your contribution. This document explains our workflow and work style.
PaddlePaddle uses this Git branching model. The following steps guide usual contributions.
-
Fork
Our development community has been growing fastly; it doesn't make sense for everyone to write into the official repo. So, please file Pull Requests from your fork. To make a fork, just head over to the GitHub page and click the "Fork" button.
-
Clone
To make a copy of your fork to your local computers, please run
git clone https://github.com/your-github-account/paddle cd paddle
-
Create the local feature branch
For daily works like adding a new feature or fixing a bug, please open your feature branch before coding:
git checkout -b my-cool-stuff
-
Commit
Before issuing your first
git commit
command, please installpre-commit
by running the following commands:pip install pre-commit pre-commit install
Our pre-commit configuration requires clang-format 3.8 for auto-formating C/C++ code and yapf for Python.
Once installed,
pre-commit
checks the style of code and documentation in every commit. We will see something like the following when you rungit commit
:➜ git commit CRLF end-lines remover...............................(no files to check)Skipped yapf.................................................(no files to check)Skipped Check for added large files..............................................Passed Check for merge conflicts................................................Passed Check for broken symlinks................................................Passed Detect Private Key...................................(no files to check)Skipped Fix End of Files.....................................(no files to check)Skipped clang-formater.......................................(no files to check)Skipped [my-cool-stuff c703c041] add test file 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 233
-
Build and test
Users can build PaddlePaddle natively on Linux and Mac OS X. But to unify the building environment and to make it easy for debugging, the recommended way is using Docker.
-
Keep pulling
An experienced Git user pulls from the official repo often -- daily or even hourly, so they notice conflicts with others work early, and it's easier to resolve smaller conflicts.
git remote add upstream https://github.com/PaddlePaddle/Paddle git pull upstream develop
-
Push and file a pull request
You can "push" your local work into your forked repo:
git push origin my-cool-stuff
The push allows you to create a pull request, requesting owners of this official repo to pull your change into the official one.
To create a pull request, please follow these steps.
If your change is for fixing an issue, please write "Fixes " in the description section of your pull request. Github would close the issue when the owners merge your pull request.
Please remember to specify some reviewers for your pull request. If you don't know who are the right ones, please follow Github's recommendation.
-
Delete local and remote branches
To keep your local workspace and your fork clean, you might want to remove merged branches:
git push origin :my-cool-stuff git checkout develop git pull upstream develop git branch -d my-cool-stuff
-
Please feel free to ping your reviewers by sending them the URL of your pull request via IM or email. Please do this after your pull request passes the CI.
-
Please answer reviewers' every comment. If you are to follow the comment, please write "Done"; please give a reason otherwise.
-
If you don't want your reviewers to get overwhelmed by email notifications, you might reply their comments by in a batch.
-
Reduce the unnecessary commits. Some developers commit often. It is recommended to append a sequence of small changes into one commit by running
git commit --amend
instead ofgit commit
.
Our C/C++ code follows the Google style guide.
Our Python code follows the PEP8 style guide.
Our build process helps to check the code style. In build.sh
, the entry point of our builder Docker image, the CMake argument WITH_STYLE_CHECK
is set to ON
by default. This flag is on
Please install pre-commit, which automatically reformat the changes to C/C++ and Python code whenever we run git commit
. To check the whole codebase, we can run the command pre-commit run -a
, as in the check_style.sh
file, which is invoked by our Travis CI configuration.
Please remember to add related unit tests.
-
For C/C++ code, please follow
google-test
Primer. -
For Python code, please use Python's standard
unittest
package.
We use glog for logging in our C/C++ code.
For general information, please use LOG
. For debug information, please use VLOG
. The reason is at here.
VLOG
requires a verbose level parameter. For example:
VLOG(3) << "Operator FC is taking " << num_inputs << "inputs."
When we run a PaddlePaddle application or test, we can specify a verbose threshold. For example:
GLOG_vmodule=buddy_allocator=2 \
GLOG_v=10 \
python \
../python/paddle/v2/framework/tests/test_recurrent_op.py
This will enable VLOG messages generated by buddy_allocator.{h,cc}
and in the verbose range of 0 to 3, so you will see above example VLOG message, which is in level 3. This suggests that we output overall messages in lower verbose levels, so they display with higher probability. When coding C++, please follow the verbose level convention as follows: