Patches will be applied directly using `git am` - so please send your
mail as text/plain without PGP encryption applied. The subject line
should act as summary of your patch and the body should have a
meaningful commit message with information about motivations for this
patch and how it changes the behavior.
Don't commit commented code and follow the coding style described at
http://s3d.berlios.de/style_guide

The patch must apply without any problems on the desired branch. So if
it is a bug fix then it must apply against the maint branch and if it is
new feature or a bug fix only available in the master branch then it
must apply against the master branch.
`git format-patch -M` should be used to create these patches. Further
changes to this file should only be done in rare situations. An example
could be to add v2 to [Patch v2] to inform other users that this makes
another unapplied patch obsolete. If you want to add other information
to the patch which should not go into the commit message then write an
extra summary mail or add these information in the part between ---
and the diffstat - please test afterward if the patch still applies
cleanly. Don't paste the patch into your mailer - this will ruin the
patch in most cases. Try to use `git send-email` or read
Documentation/email-clients.txt inside the linux kernel tree.

Read Documentation/SubmittingPatches inside the git and linux-2.6 tree.
Anything but the application specific information should be the same
for s3d. They are also describing what a good commit messages is, why
it is important to send the mail like it was generated by
`git format-patch` and what the Signed-off-by means and how it should
be used.

Your patch must be licensed under the GPL2+ (or LGPL2.1+ for libs3d and
libs3dw).

If you think that your patch is ready for inclusion then send it to
                   s3d-devel@lists.berlios.de
You must be subscribed to the mailing list or otherwise your mail will
be dropped without further notice.
