river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: What do we want our "main trunk" to be? (was development process)
Date Wed, 05 Sep 2007 09:11:23 GMT
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.

> 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.
-- 
Mark

Mime
View raw message