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 [EMAIL PROTECTED]
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
