Software development / quality assurance process

To foster code quality and reuse we have developed a Quality Assurance process outlined below. There are two levels. Each package has a process, and on top of the package review process is the Stack QA Process. This process is designed for Willow maintained code ros, ros-pkg, and wg-ros-pkg repositories. For people working in other repositories we suggest that this model is good however it is the choice of the maintainers what process to follow.

Stack QA Process

1. Create a new stack

   1. Have a clear definition of a stack including capabilities, scope, and dependencies.
   2. Accept packages which have become relatively stable and fall inside the definition of the stack.

2. Document your Stack according to the StackDocumentation guidelines.

3. Maintain all packages to work with the stack and ensure dependencies don't break with periodic releases.

4. Follow the Stack Version Policy

Package QA Process

1. Creating a new package
   1. proposal + specification (explain need, list critical features)

      • Package Proposal Process

2. API review

   1. API & architecture review (here's what I'll do, here's how I'll do it)

      • Please pay attention to the DevelopersGuide through this process.

      • API Review Process

3. Doc review
   1. Make sure that documentation for Users is sufficient

      • Doc Review Process

4. Code review
   • No review will occur until the previous steps are completed.
   • Review will cover all steps above (verify issues raised during design review, unit and integration tests, API, and documentation)

   • The review will test for compliance with the best practices outline in the DevelopersGuide

   • Code review process

5. Deletion/graveyard: packages that are deprecated or are otherwise not in use should be moved deleted or moved to the Graveyard

3rd-party packages

To be cleared a 3rd party package must go through the following process (VERY rough draft, not reviewed by anyone else)

1. Need review.
   • Evaluate need, and look for functionality elsewhere in system or in other package-managers)
   • Evaluate the package code quality and level of maturity
   • Evaluate package license
   • Review alternative packages for comparison (especially if they are available via other package-managers)
2. Package review
   • Make sure that downloads and build system are well behaved and follow all conventions
   • Make sure that manifest is proper
   • Code review of all patches (with tests)
   • Review tests (either 3rd party or Willow Garage)