DeveloperGuidelines

h1. Guide to making life easy for everyone

An important aspect of distributed development is having everyone know what everyone else is doing (or not doing). When people only communicate via email, and often only when something goes wrong (a bug report for example), it's hard to keep track of who is doing what, who is planning to do something, who needs help, and so on. The tools PortAudio developers use offer a number of mechanisms to help with this. The main ones are:

• url:http://www.assembla.com/code/portaudio/subversion/changesets, which lists all recent SVN commits.
• url:http://www.assembla.com/spaces/portaudio/tickets for tracking development tasks.
• url:http://www.portaudio.com/docs/v19-doxydocs/
• url:http://www.portaudio.com/contacts.html for discussions between developers and users.
• url:http://www.assembla.com/spaces/portaudio/wiki
• url:http://www.portaudio.com/docs/proposals/index.html - more formalised documents for API changes.

h2. Add all future tasks to the ticket system

If you think of a task that needs to be done, but you haven't done it yet, or you want someone else to do it, create a new ticket: url:http://www.assembla.com/spaces/portaudio/tickets/new If you don't have Ticket admin priveledges email rossb@audiomulch.com and you'll be given some, it's that simple.

h2. Write meaningful SVN commit messages

If you write meaningful SVN commit messages other people can see what you're working on.

h2. Crossreferencing SVN commits and issue tickets

You can crossreference a ticket in an SVN commit message simply by including the ticket number with a # before it. You can crossreference an svn changeset in a ticket comment by putting the changeset number between square brackets [ [r:{id}] ]. Keep things crossreferenced whenever you can.

h2. Post patches to the ticket system

If someone sends you a patch, but you can't/won't action it, at least create a new ticket with the patch attached. url:http://www.assembla.com/spaces/portaudio/tickets/new

There are a couple of other things that can be done to help us keep track of where each other is up to (what has been done, what hasn't been done, what we're thinking about doing):

h2. Don't use doxygen @todo comments

We used to have a guideline to use doxygen @todo tags in the code. Don't do that. If you find things in the code that need doing, please create a ticket.

h2. Don't forget the style guide

There are PortAudio coding style guidelines, they live here: ImplementationStyleGuidelines