Pull Request Walkthrough¶
If you would like to submit a patch, especially if you have a major change, it is recommended that you chat with us before you get started.
Add unit tests where appropriate.
Update relevent Documentation. Please build the docs to test!
If your change would benefit from integration testing, write a pulp smash issue.
Add a changelog update.
Rebase and squash to a single commit, if appropriate.
Write an excellent Commit Message. Make sure you reference and link to the issue.
Push your branch to your fork and open a Pull request across forks.
Add GitHub labels as appropriate.
Change the status of the redmine issue to “POST”.
Add a link to the pull request in a comment on the issue.
Make sure the tests are passing.
If the change requires a corresponding change in pulp-cli, open a PR against the pulp-cli or file an issue.
To the community: The Pulp Team is very grateful for your contribution and values your involvement tremendously! There are few things in an OSS project as satisfying as receiving a pull request from the community.
We are very open and honest when we review each other’s work. We will do our best to review your contribution with respect and professionalism. In return, we hope you will accept our review process as an opportunity for everyone to learn something, and to make Pulp the best project it can be. If you are uncertain about comments or instructions, please let us know!
Reviewing a Pull Request¶
When reviewing a PR, it is important to consider where the change ought to land. If you are reviewing a bug fix that might be released as part of a z-stream release, you should add the “Needs Cherry Pick” label to the PR. Otherwise the label should be removeed. PR authors can also add or remove this label if they have write access.