[wplug] open source software development methodology

[me at harkyman.com]

I have to second Mr. Moran's response, but I'll add a few more specifics. On the Blender project (www.blender.org), we use SVN (used to use CVS, but SVN is sooooo much sweeter). There is a main branch called "trunk," which is the current development version. The 30 or so core developers (including me) have direct commit access to the trunk repository, although anyone can check it out anonymously to play around locally.

Even though we all have commit access, each section of Blender (it's fairly complex) has a designated maintainer who has to approve any code before it goes in. This is "honor system" so, for example, I could do a commit right now into the render code without asking anyone, even though it isn't my area. Of course, that would be immediately rolled back and they'd smack me around for it. But for small projects, we generally post them to a patch tracker on the .org website and email the relevant people to please review it.

For serious longer-term projects (a couple of months, significant new features, etc.), a new branch is made for the developer in question, so they can develop with all the tracking benefits of svn in a remote repository. It is this developer's responsibility to keep the new branch merge-able with the main trunk if they ever want their feature to see the light of day. If they don't keep up with trunk, they might as well not be coding. When the feature is completed to the satisfaction of everyone involved (module maintainer, dev lead, feature developer), the code is merged into trunk.

Decisions about suitability are conducted via the developers' mailing lists, but often devolve to the dev's irc channel. To make things more official, irc dev meetings are held once a week to discuss things like this.

As far as release engineering goes, we have pretty strict development phases (we call them BCON1 through 5), each representing different stages (5=relaxing after release, everyone just thinking; 4=active development; 3=release scheduled, clean up your code and crush your bugs; 2=feature freeze, testing builds; 1=release ahoy!; note that these are off the top of my head).

Good luck!

Roland Hess

> From: Bill Moran <wmoran at potentialtech.com>
> 
> In response to "Alexandros Papadopoulos" <apapadop at alumni.cmu.edu>:
> 
>> I assume there are a number of people on this list that have
>> first-hand involvement in free software projects, so I'd appreciate
>> your experiences, DO's and DONT's on the below scenario.
>> 
>> A loose team of software developers and web 2.0 architects
>