We hope that this project will attract a diverse group of developers. If this happens we think that a clear set of written down rules would help to avoid misunderstandings.
The rules on the pages are brief. We also maintain a page with more practical instructions and a guide to common practices.
- Build system
- Revision control system
- Unit test system
- Hosting service
- Bug Tracking
Any reusable software related to robotics. Emphasis is placed on algorithm and driver implementations. Integration frameworks are generally discouraged. Relevance of a particular library is determined through mailing list discussion.
Must specify an
open source license.
Must specify ownership.
Sufficient to be useful, depends on the complexity of software, determined by peer review (at least 1 reviewer) and a public discussion on the mailing list.
- Tests and sample code
Sufficient to be useful, depends on software, determined by peer review.
- Programming style
Must name a known style, or describe a style (see Appendix A
), and adhere to it.
Must compile without warnings (with -Wall) on all supported platforms with all supported compilers.
Libraries must operate (within reason) as described by the documentation. Reviewers of hardware drivers are encouraged to have access to hardware where feasible.
Failure of any in 2.1.2 Criteria for acceptance
Fails to compile on any one of the supported platforms/complilers (as specified by the library developer) or does not gracefully handle one of the platforms/compilers specified as supported by Gearbox but not supported by that library - will be disabled immediatly in SVN and in any following releases until fixed
Fails for 2 months since disabling to compile on any one of the supported platforms/complilers (as specified by the library developer) or does not gracefully handle one of the platforms/compilers specified as supported by Gearbox but not supported by that library - will be moved to graveyard at the end of the 2nd month.
Failure of any 2.1.2 Criteria for acceptance
for 3 months after warning.
Regular frequent releases every 1.5-3 months.
Copyright belongs to authors and major contributors. The copyright is recorded in a comment block at the top of every source file. It is up to the current copyright holders to distinguish between "major" and "minor" contributions.
Aside from complying with Sec.2, the designer of every module within the project is not constrained in any way. We specifically mention several important freedoms:
- OS, compiler, programming language. New contributor's responsibility is to make sure that the new addition does not break the existing code.
- code design, e.g. whether or not to use C++ exceptions.
- data types used by libraries.
In the case of not using a well-known, named style, contributors must describe the programming style in sufficient detail for others to be able to adhere to it (assuming, of course, that others are also capable of looking at the code for details). An example of what is necessary for C++ is given below.
- Naming conventions
- variables, member variables, classes, structs, namespaces
- functions, member functions
- #defines, enums
- API usage style
- Units and coordinate systems
If applicable (needless to say that the units and CS's of the API must be documented separately, this applies to the code itself.)