-
Notifications
You must be signed in to change notification settings - Fork 131
Code submission
Since NIPAP is hosted on GitHub, the most common method for sending code is through a pull request (PR). We have no principal problem with PRs - it's just that they tend to become cluttered with changes in a number of commits as feedback is given on the initial patch. We want PRs with a clean commit history.
Please try to create an issue here on GitHub to track the problem you are seeing. The PR is your proposed solution to the problem. If your PR is rejected, we can still keep track of the problem if there is an issue opened for that.
It is better discussing potential solutions in an issue than in PRs as PRs are commonly closed and another PR is opened with an updated patch. The issue can keep it all in one place.
Use descriptive names for your branches like 'cli/123-fix-traceback' and not something like 'my-fixes'. See branch names for more details.
Travis-CI is a continuous integration platform that tests the codebase of a project every time a new commit is pushed to GitHub. NIPAP uses Travis-CI to prevent unwanted side-effects of code changes.
Make sure that the unittests run fine (you can do this locally) and that Travis-CI runs fine with your patch (this will be visible at the bottom of the PR page on GitHub).
A PR is submitted for implementation of X. Feedback is left in the form of comments on the PR. Author updates patch according to feedback and pushes updated code to the PR. Git log is now filled with crap.
We strive to keep a clean git log and so instead of just updating the PR, rebase to squash out intermediate commits and write one commit message that makes sense for the patch. See git rebase for more information.
If you are submitting a very large patch, possibly affecting multiple components, it might we worthwhile to consider splitting the patch into several pieces (several PRs). It is important though that each PR handles a distinct change on its own. There is no point in splitting a patch into smaller ones if the smaller pieces do not, on their own, bring any benefit.
Try not to bump version numbers in your patch to add functionality X. By the time your PR is accepted, we might already have increased the version number (making your patch obsolete) or there is a need to commit more new features before releasing a new version OR your new version is so cool that it requires a major version bump. Anyway, please let the project maintainers handle the versioning and instead focus on your code :)