«« Outsourcing Internationally AudioMan Dev Box »»
blog header image
Code Check-in for AudioMan

Now that AudioMan is an open source project, I've been thinking about the best way to do check-ins. Fortunately I don't have to think too much because several open source projects, like Eclipse and Bugzilla, use a process I mostly agree with.

In that system there are committers, people who have CVS logins and can modify the CVS tree (submit, modify, delete code). Committers are usually with the project for a long time.

The rest of the coders on the project submit patches which are attached to bugs in the Bugzilla defect tracking system. Committers apply the patches to the current CVS contents, make sure everything works as intended and then checkin the code and close the bug.

This system has the following advantages:
1. Allows people to contribute code very easily, without necessarily tying themselves down to AudioMan.
2. Allows committers to tightly control quality by rejecting unacceptable patches (broken, not tested well enough, not documented, etc).
3. Defect and patch tracking is easily monitored by Bugzilla.
4. Defects are likely fixed in order of importance and/or preference of users/developers.

I see this project having people coming and going, submitting code as they have time. Very few people will be able to consistently apply effort to the project, which means that specific taks and timelines for milestones will be difficult to lay out. Open source projects typically do not have firm deadlines (larger projects with paid developers working consistent hours like Mozilla and Eclipse are notable exceptions).

Oh yes, and casual patch contributors -- by submitting many successful patches and demonstrating their talent to the current batch of committers -- may be promoted to "committer" status.

Comments?

Update 9:32AM: Eclipse can make patches that you can attach to a bug. Then a committer can apply that patch in Eclipse again to the latest CVS source. If the changes introduced by the patch are good, the committer checks those changes into CVS. Sorry, I wasn't too clear on that. Yeah, as far as I know patches are just diff files.

Update Wednesday 3:56AM: Right out of the Eclipse help, here's Working with patches.

Posted at December 16, 2003 at 04:17 AM EST
Last updated December 16, 2003 at 04:17 AM EST
Comments

I wish I knew how patches work. When ever I see patched style code - it looks like a *diff* file. Is there a patch program that reads that sheeat?

I might look it up myself, but if you have some answers - let me know.

» Posted by: aforward at December 16, 2003 09:20 AM

Yo!

http://www.cryptnet.net/fdp/prog/patch.html

Enjoy.

» Posted by: roy at December 16, 2003 11:17 PM

Yup, those are the technical details. Eclipse does all of that stuff for you.

» Posted by: Ryan at December 17, 2003 03:58 AM
Google
 
Search scope: Web ryanlowe.ca