hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: Hadoop 0.19.1
Date Mon, 09 Feb 2009 16:37:51 GMT
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.


View raw message