Want to help with AMaMP development? If so, that's cool, and thanks
in advance for your consideration. This page contains some information
about getting involved and the way things work.
uses the GNU GPL license; I suggest you take a read over it before
contributing anything to the project if you are not familiar with
it. CVS is used to store the source tree, and point releases are
made once in a while using the SourceForge release system. There
should also be nightly CVS snapshots (they weren't quite put in
at the time this was written - they may be now).
If you're interested
in joining in, I suggest you do a CVS checkout of the latest source
(see the download page). You may be
interested in helping with core development, working on a (new?)
front end or both. Either way, that's great - all contributions
are welcomed, though that doesn't mean everything is accepted -
if you send in an obfuscated, uncommented patch for the core that
causes it to segfault whenever there is a full moon, it's probably
not going to be applied. ;-).
You will also need to subscribe to the AMaMP development mailing
list - for help on how to do that, see http://lists.sourceforge.net/lists/listinfo/amamp-development.
If you wish to make contributions (yay!), please send them as a
unified diff to the mailing list (or ask for help if you don't know
about doing that). Once you've made a few of posts and sent in some
good patches, and provided people are in general agreement about
it, a project admin will then make you a project developer, which
will give you CVS commit access. The policy on this is:
1) If you know
your patch is a simple fix or it does something that is in the to-do
a) Check the thing you've changed compiles with your changes.
b) If/when we have a test suite, run it. (We really need one!)
c) Check it in (cvs commit)
d) Send a message to the list stating what you just checked in.
2) If you are not sure about whether your patch is done in a way
that people will be happy with, or if it adds something new that's
not on the to-do list, or you need someone on a different platform
to check it, or if you're just not 100% certain it should be comitted,
post the unified diff to the list with any info about the patch.
It is particularly important you do this for core patches, for a
fault in the core causes problems for all the front ends that target
Why a policy?
Much as I dislike red tape and I don't want to put people off contributing,
I do feel that to be successful a project needs management of some
kind. The above 2 simple rules for developers (and yes, that includes
project admins) should ensure that everyone is kept in the loop
about what is happening, and help prevent misunderstandings in a
I should also
point out that AMaMP is something I do for fun, and I hope everyone
who helps develop it will enjoy doing so. If you have any questions
that you want to ask someone personally rather than posting them
to the list, please feel free to mail me at email@example.com.
Thanks for reading,
"That hacker who started that AMaMP thing"