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 Wed, 05 Sep 2007 11:51:33 GMT
Hi Mark,

On Sep 5, 2007, at 2:11 AM, Mark Brouwer wrote:

> Craig L Russell wrote:
>> 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).
>
> Hi Craig, are you referring to a discussion we had in the past here  
> or to a document on the ASF website that explains the common  
> procedures. In both cases could you provide a link.

Neither. I'm referring to the practices of individual projects that  
I'm involved with. As you've noticed, documentation of practices of  
projects isn't uniform. Once the project is formed, community  
discussion results in agreement of practices, and the documentation  
in the projects themselves tends to be of the "here's how to build,  
test, release" and "here's what the release process is" instead of  
"here's why we have a trunk and branch and tags". For and example,  
you can look at http://openjpa.apache.org/releasing-openjpa.html
>
>> 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 trunk.
>
> I agree there must be room for experimental branches and branches  
> people
> can use to coordinate their activities when they are working  
> together on
> some features. I expect that in most cases the trunk is not the right
> place for this. But as working on the *same* resources in multiple
> branches is painful (especially when doing multiple revisions) and  
> AFAIK
> SVN doesn't have a decent merge history (it doesn't record what was
> merged) I hope we can keep this to a minimum through some  
> coordination.

When you have a feature that is very disruptive, you would work on  
that feature in isolation in its own branch, and generally not try to  
merge the trunk on a regular basis. So when you do merge the  
completed feature back to trunk, the number of changes to be merged  
is minimal.

Craig

> -- 
> Mark

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!


Mime
View raw message