NetBSD Commit Guidelines

If you are not sure if the code you plan to commit is acceptable (e. g. when taking code that was submitted with a problem report), ask a developer who is familiar with that part of the system for review. If you're new to the Project, check with your sponsor.

If you commit code that was not written by yourself, double check that the license on that code permits import into the NetBSD source repository, and permits free distribution. Check with the author(s) of the code, make sure that they were the sole author of the code and verify with them that they did not copy any other code.

Make sure that your code actually works as expected, by compiling and running the code that is affected by your change with your system's tools. If you changed a man page, make sure that groff/nroff creates the formatted man page you expect.

For normal commits (to the trunk), test that your code works on -current. Prior to reqesting a pull-up to a branch, test the very changes you will request from releng on the respective release branch.

Rototilling a make variable that affects 50 Makefiles should get one commit for all of them together.

Don't fix 3 bugs with the same commit and roll that into "Fixed some bugs". Fix one, test, commit, rinse, repeat. This makes life infinitely easier for releng to pull up fixes since often not everything applies to a given branch.

Do those separately (apart from the general requirement that changes be made in such a way that it is easy to discern what each fix did, as described in item 6, there will be pullup issues with largely changed files from trunk->branch when mixing whitespace with functionality fixes).

Detail to some degree what was changed and why. Doesn't need to be a code review/walkthrough but it should be informative to someone reading the log and looking over the diff in 6 months. Again "fixed some stuff" or "cvs-1.10.0" isn't acceptable whereas the following example is:

If your change fixes a PR, document this:

If your code has been reviewed by someone else, document this:

(Please note that a good commit log doesn't relieve the need for good documentation in the program itself.)

If you commit code that had been submitted in a PR, give proper credit, like:

Since the commit messages will eventually appear on the source-changes mailing list which is also available via web, specifying the e-mail addresses of the PR submitter should generally be avoided.

If you took code from an other Open Source Project, give credit, like:

If you do not agree with another developer's commit, do not revert it on your own. Contact the other developer and explain to him or her the issues you have with his commit. Ask him or her to backout his changes himself.

If no agreement can be reached, contact the Technical Executive Committee <technical-exec@NetBSD.org>, which will serve as mediation authority.