-
Notifications
You must be signed in to change notification settings - Fork 132
Code submission
Since NIPAP is hosted on GitHub, the most common method for sending code is through a pull request (PR). We have not principal problem with PRs - it's just that they tend to
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.
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.
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.