river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: What do we want our "main trunk" to be? (was development process)
Date Tue, 04 Sep 2007 21:10:34 GMT
Hi John,

I'll give you a small perspective based on the projects I'm very  
familiar with.

The trunk is where tested but not guaranteed stable code is checked  
in. The expectation is that self-consistent but not necessarily  
complete features can be checked in. Others can test and validate and  
comment on the code and the functionality and completeness thereof.  
After some iterations the code is stable enough for release. (see  
other discussion on release practices).

Breaking the trunk build means the project deliverable cannot be  
produced, and it's a rare but unfortunately not impossible result.  
Whoever breaks the build is expected to fix it before doing anything  
else (including the errant committer's day job). Most often the build  
is broken due to the committer and the builder being on different  
platforms where there is an incompatibility not visible in the  
committer's environment.

If features under development would unduly affect trunk, then a  
special dev branch is created. There are no expectations for stable  
dev branches. Once the dev branch is stable, it can be merged into  


On Sep 4, 2007, at 1:56 PM, John McClain - Sun Microsystems, Inc. wrote:

> What is the general role/expectation of the main trunk on Apache  
> projects?
> Classically in Jini development there was a reasonably high bar on  
> checking things into "/main/LATEST" (clearcase's equivalent of the  
> main trunk). Code reviews, tests, high conference in your code,  
> etc. "Breaking the build" was bad  and earned the ridicule of your  
> peers for weeks if not months.
> This isn't to say "/main/LATEST" was always "release ready". At the  
> beginning of the cycle less stable changes would go in and the  
> quality level would be progressively raised until you got to code  
> freeze where only changes that got in where fixes for bad bugs that  
> you had very high conference in.
> At some level I had been taking for granted that River would work  
> this way too, but this might be a flawed notion on my part....
> Another model for the main trunk would be more of a "wild west"  
> model, where the barriers for check-in would be significantly  
> lower. From a project's perspective the main advantages would be  
> that the main trunk could be used more as a space collaborative  
> development and something that gives the user community access to  
> the very newest features.
> Obviously the goal isn't to check in bad code, but letting a few  
> bits of a bad code in temporarily would be viewed as the price for  
> getting a main trunk that supports more collaboration. Put another  
> way, if there aren't a few bad check-ins then people are sharing  
> (often?) enough.
> Is this a useful lenses to look at some of these process issues  
> through? How do Apache projects treat their main trunks?
> -- 
> John McClain					john.mcclain@sun.com
> Sun Microsystems, Inc.
> Burlington, MA
> And it is that way today. We are tricked by hope into starting
> companies, beginning books, immigrating to this country and investing
> in telecom networks. The challenges turn out to be tougher than we
> imagined. Our excessive optimism is exposed. New skills are demanded.
> But nothing important was ever begun in a prudential frame of mind.
>         - David Brooks

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message