Doug Cutting wrote:
Sanjay Radia wrote:
For me the lesson is that large complex projects should be branched.
I currently estimate my merge costs of 20% -one day a week- though a lot
of that is test run time
If we change the RPC system, or switch DFS client to use RPC instead of
sockets, etc., we might want to do these in a branch since they'll touch
a lot of code and will require extensive testing before we release them.
I don't think this is fundamentally a policy issue. We still want to
demand that things are well tested before we commit them to trunk. The
append code was committed to trunk prematurely, perhaps since managing
as a patch was awkward. So this is a praxis issue. For features that
take a long-time to develop, that we do not want to be forced to
prematurely commit, a branch is perhaps a better mechanism than a patch.
So I think, if a committer feels a feature requires a branch, then they
can propose that, and if no one objects, they can create it and maintain
it. The final commit to trunk is what we should watch most closely,
since that's the event that corresponds to a commit today. Commits to a
feature branch should not require reviews, since these are equivalent to
updating a patch.
Does this sound reasonable?
this sounds good, I would propose my lifecycle changes as an example
-changes bits at the bottom
-adds lots of tests
-needs/encourages review
-lets me do my work under SCM
-let's me hook our work Hudson servers up to it
Putting the stuff in a branch makes it easier for people to work on it,
to check it out and build it etc.
-steve
