QAProcess: DevelopersGuide | Review Status | PackageProposalProcess | PackageDocumentation | APIReviewProcess | DocReviewProcess | CodeReviewProcess | StackDocumentation | StackVersionPolicy | AutomatedTesting | StackReleaseProcess | WritingTutorials | Graveyard
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
Create a new stack
- Have a clear definition of a stack including capabilities, scope, and dependencies.
- Accept packages which have become relatively stable and fall inside the definition of the stack.
Document your Stack according to the StackDocumentation guidelines.
- Maintain all packages to work with the stack and ensure dependencies don't break with periodic releases.
Follow the Stack Version Policy
Package QA Process
- Creating a new package
- proposal + specification (explain need, list critical features)
- API review
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.
- Doc review
- Make sure that documentation for Users is sufficient
- 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
Deletion/graveyard: packages that are deprecated or are otherwise not in use should be moved deleted or moved to the Graveyard
To be cleared a 3rd party package must go through the following process (VERY rough draft, not reviewed by anyone else)
- 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)
- 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)