Getting Involved
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.

The project 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.

Contributing
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 list:-
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 it.

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 big way.

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 jonathan@jwcs.net.

Thanks for reading,

Jonathan Worthington
"That hacker who started that AMaMP thing"