To contribute to FreePOOMA development you should get yourself a Savannah account at http://savannah.nongnu.org/. Please follow the guidelines below.
There is no enforced coding style (like the GNU coding conventions, or famous Linus Torvalds Linux kernel coding style). You rather should follow the style around the code you're changing. Apply common sense, if in doubt try to mimic the Linux kernel coding style rather than the GNU one.
All new functions and classes should get documented. Use doxygen markup so reference documentation can be automatically generated. Follow existing practice again.
Use the GNU coding conventions for these. That is, group commits logically by function, documenting them with a commit log message that looks like
2004Nov02 Richard Guenther
* src/Field/Field.h (MakeReturn): remove obsolete methods. (ForEach): likewise. src/Pooma/Pooma.h: include Field/Field.h src/Utilities/dummy.cpp: new.
again, following existing practice is recommended. You can use the 'cvsps' tool to create a ChangeLog file from the repository log data. Use
freepooma/> cvsps -Z 3 -x > ChangeLog
To give patches some peer-review, post them on the freepooma-devel mailing list. Get them reviewed and approved by a co-developer (in case there is one). If you're the only developer at the moment, just go ahead. Try to avoid incompatibilities with previous versions of the library API. If you have gread ideas for new interfaces be sure to get them discussed before changing code all over the place.
Always test your changes with a library build and a testsuite run. The testsuite coverage is low, so for new features add new testcases. For bugfixes add testcases that exploit the defect.
Copyright (C) 2004 Richard Günther
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
Last updated $Date: 2004/11/02 20:13:18 $ by $Author: richi $.