Last Update Thursday, July 26, 2001 06:10 PM
Revision Status
Revision | Date | Author(s) | Reason |
0.1 | 5 July 2001 | M. brasher, K. Schopmeyer | first Draft |
0.2 | 24 July 2001 | M. Brasher, K. Schopmeyer | |
0.3 | 26 July 2001 | K. Schopmeyer | Add documentation on licensing. |
This document defines the basic set of guides and rules for programmers contributing to the Pegasus Project
NOTE: This is a draft copy for comment.
RULES and GUIDELINES - A number of the guidelines below are absolute rules that we must follow in the Pegasus project. These are the things that will help insure portability and effective interoperability of the components.
Other area are "guidelines" that we strongly suggest be followed so that 1) the code will be readable and usable, 2) we develop a single look to our source code, etc. In some cases, there may be reasons to bypass some of these guidelines but we strongly encourage everybody to follow them. In fact, if there is a real reason we will change to what the group wants and suggestions.
void MyClass::myMethod( const char* someReallyLongName, const char* someOtherReallyLongName);
for(...) { .... }Not this:
for (...) { .... }or this:
for (...){ .... }
class X { public: void f(); void g(); };
Avoid this: int x; float y;
int f() { .... }
Effective testing is essential to allowing a group to work together in a common code environment. We have created a structure where unit and even system level tests can be created and committed to the source tree as part of all development. Each major directory section includes a tests subdirectory with individual directories for tests. Please create and commit tests as part of the normal environment wherever it is possible. All core code should include tests created in this manner as well
If you change code to extend it or make corrections, please review the corresponding tests code to 1) add tests to cover the problem corrected 2) extend tests to cover the new code added.
Be mindful that the tests must run on all supported platforms and that a commit may break another platform.
Tests must clean up the effect they have on the repository.
Changes must work on all platforms. Commits must not break any platform. Always write a regression test for everything.No files with warnings should be committed to CVS. Test big changes on at least Windows and Unix (or Linux)
Don't commit anything that breaks the build (try a clean slate checkout and build). Remember that if the build is broken for you, it is also broken for everybody that gets the new code.
Always build and run all regression tests before committing.
No binaries may be committed to repository.
There are a few exceptions to this rule but binary files cause problems
This is an open source project. All code that is contributed to this project must be open source and must be made available under the standard license used by the Pegasus project. Do not use any outside libraries that do not meet this criteria. Further, every reference to outside code make it more complex for others to build and work with the project and introduces potential portability problems. At the same time, there may be real reasons to use outside code and libraries at times. Thus, for example, the initial project used the ACE_wrappers libraries extensively but with the objective of eventually providing a replacement. That replacement has been produced, partly because ACE was not available on all of the platforms.
All code submitted to the Pegasus core source libraries is to be made available under the standard license used by Pegasus. If any code is to be taken from other open source projects, we expect that the code recognize both the requirements of the Pegasus standard license and the other license (ex. if we were to share code with the Caldera OpenWBEM) project, we would have to show both their license and our licenses.
All code input to the Pegasus project must include the license statement.
If there is a case of code that we want to use on the Pegasus project but that is licensed outside of the above rules, it can be included only with the specific permission of the Pegasus project management. We will be very hesitant to do this since it could mean weakening the whole open source nature of the project and would greatly complicate our license arrangements.
The Pegasus project has developed a consistent and portable make system that allows bot localized and global builds on a wide variety of systems from Windows to Unix to the tandem platforms today. This is based on 1) using the GNU Make tool as the core of the make system, 2) minimining the use of other tools.
<<EXPLAIN THE MAKE SYSTEM OR REFERENCE DOC>>>
All code must be reachable (built) from master makefile. Otherwise it will not be reached when doing mass substitutions, testings of builds, and license changes.
<<<THIS SECTION NEED TO BE COMPLETED>>>
We work from a single source tree in CVS. We have a fixed structure for this structure.
<<<THIS SECTION IS TBD>>>
---END OF DOCUMENT--