To contribute to FreePOOMA development you should get yourself a Savannah account at http://savannah.nongnu.org/. Please follow the guidelines below.

Coding Style

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.

CVS commit log messages

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

CVS write policy

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 $.