Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Tue, 04 Sep 2007 16:56:48 -0400
From: "John McClain - Sun Microsystems, Inc." <John.McClain@Sun.COM>
Subject: What do we want our "main trunk" to be? (was development process)
In-reply-to: <46DD765B.7010507@cheiron.org>
Sender: John.McClain@Sun.COM
To: river-dev@incubator.apache.org
Message-id: <46DDC690.8020009@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <30993F0A-4C88-41FD-A3D0-8853484931E8@sun.com>
 <46D51410.3080609@cheiron.org> <46D5D130.80002@Sun.COM>
 <46D67955.2010003@cheiron.org> <46D6A492.3000907@sun.com>
 <46D6DFA9.4040005@cheiron.org> <46DD499B.2000306@sun.com>
 <46DD765B.7010507@cheiron.org>
User-Agent: Thunderbird 1.5.0.9 (X11/20070109)

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