Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> Hadoop 0.19.1


Copy link to this message
-
Re: Hadoop 0.19.1

On Feb 6, 2009, at 10:35 AM, Doug Cutting wrote:

> Sanjay Radia wrote:
> > For me the lesson is that large complex projects should be branched.
>
> We already maintain release branches.  What's under discussion is the
> maintenance of feature branches.  We do this today through patch  
> files,
> merging each time they are applied.  The proposal is to use a source
> code management tool to manage feature branches, which would be merged
> less often, but using better merge tools.
>
> FWIW, Nutch's transition to mapreduce (in the nascent days of Hadoop)
> was managed as a feature branch.  Mike & I worked in a branch for  
> about
> six months before merging back to the trunk.  For a change of that
> magnitude, we found this to be much simpler than updating a patch.
>
> So we need concrete proposals of features that deserve a branches.  In
> retrospect, it seems like append may have been better handled in a
> branch than as a patch, but that's hindsight.  What future features do
> we feel demand this?
>
> One possibility is to manage the project split in a branch.  We could
> start new repos for the hdfs and mapred sub-projects, but branch the
> core repo.  Then changes could continue to be applied to trunk while  
> the
> details of the split are worked out.  Core changes would be merged to
> the new subprojects and the branch while this is in progress. Once we
> feel the split is solid, we can merge the core branch to trunk and  
> open
> the new subprojects for business.
>
> 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?
>

yes.

>  Commits to a
> feature branch should not require reviews, since these are  
> equivalent to
> updating a patch.

Agree,  but it would be wise for the community to get their feedback  
to the project team
earlier rather than later when the big patch to the trunk occurs.
Can Jiras be used to discuss a branch? Or would the project team  
discuss this via another mechanism
(such as email).
sanjay

>
>
> Doug
>

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB