OS Group Software Development Guidelines#

The OS group supports the QNX software development process and standards; QNXCodingStandard, QNXBestPractices, etc. The OS team has also tailored the software development process to manage the unique challenges of the micro-kernel and system library development. Here's a summary:

Code review requirements#

Peer Code Review is recommended before code is checked in to the source repository. We ask that there be at least one code reviewer for any change.

 Code changes to critical parts of the OS core are treated with higher rigor; this applies to procnto, libc, pipe, mqueue, startup lib, and
 all system headers. Code review by two developers is mandatory and the code cannot be checked in unless both code reviewers agree. 
 For new features, we will decide (on a case-by-case basis) whether code will get reviewed piecemeal as it is developed or whether the 
 feature (when completed) will get reviewed in a single pass. In most cases, group code reviews are mandated for new major features. 

SVN commit log#

The commit log should include at least the following items:

• PR or CR number (ie PR:12345)
• Name of code reviewer (ie CI:dtdodge)
• Brief desciption of the code change and/or reason

Coding standard and warning free policy#

The code should conform to the QNXCodingStandard. The source code checked into svn should also compile warning warning free.

PR database and Unit tests#

All bugs should be recorded in PR database for tracibility. It is recomended to add in the projected impact and workarounds. A unit test case should be attached to the PR. The unit test case should be written in the regression test format to enable test automation.

 In the case of bugfixes procnto, libc, core headers, mqueue or pipe, a regression test (in the OS regression suite) must be provided.
 If an existing test exists to cover this issue, it should be referenced in the PR. If no test exists, a new unit test can 
 be developed (these should be put under the regress/deunit directory), or an existing regression test can be extended. 
 In either case, these should be referenced in the PR.

TODO: Add in Kernel Unit Test Guide