|«« Outsourcing Internationally||AudioMan Dev Box »»|
I'm Ryan Lowe, a Software Engineering graduate living in Ottawa, Canada. I like agile software development and Ruby on Rails.
I write this blog in Canadian English and don't use a spell checker. Typos happen.
» Full-time Ruby on Rails freelancer
» Full-time with Rails since May 2005
» Former committer for RadRails (now Aptana)
» I also have a few Rails side-projects in development:
1. wheretogoinTO.com Toronto nightlife
2. Hey Heads Up! TODO list and sharing
3. Layered Genealogy family history research
4. foos for foosball scoring
5. fanconcert for music fans (on hold)
Hiring Rails developers? I can telecommute by the hour from Ottawa, Canada
»» Email: rails AT ryanlowe DOT ca
Now hosted on Hey! Heads Up -- check it out!
Derek Lowe's (Ryan's older brother) words at Ryan's funeral
firstname.lastname@example.org no more
Forging Email Headers: Good, Bad or Ugly?
Sarcastic Dictionary (Part 1 of Many)
Twisting Rails is Risky Business
Risky Business? My Take on Early Alphas
Whoa, it's August 2007
A Postscript to "Growth at the grassroots"
»» All Blog Posts
David Heinemeier Hansson
James Duncan Davidson
Signal vs. Noise
Amy Hoy: (24)slash7
Luis de la Rosa
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:
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.
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