hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: HDFS-1623 branching strategy
Date Thu, 07 Jul 2011 21:33:08 GMT

Sounds like this has worked well for the MR2 branch as well.

Thanks for volunteering to maintain the branch.

On Thu, Jul 7, 2011 at 1:43 PM, Aaron T. Myers <atm@cloudera.com> wrote:
> Hello everyone,
> This has been informally mentioned before, but I think it's best to be
> completely transparent/explicit about this.
> We (Sanjay, Suresh, Todd, Eli, myself, and anyone else who wants to help)
> intend to do the work for HDFS-1623 (High Availability Framework for HDFS
> NN) on a development branch off of trunk. The work in the HDFS-1073
> development branch is necessary to complete HDFS-1623. As such, we're
> waiting for the work in HDFS-1073 to be merged into trunk before creating a
> branch for HDFS-1623.
> Once this branch is created, I'd like to use a similar modified
> commit-then-review policy for this branch as was done in the HDFS-1073
> branch, which I think worked very well. To review, this was:
> {quote}
> - A patch will be uploaded to the JIRA for review like usual
> - If another committer provides a +1, it may be committed at that
> point, just like usual.
> - If no committer provides +1 (or a review asking for changes) within
> 24 business hours, it will be committed to the branch under "commit then
> review" policy.Of course if any committer feels that code needs to be
> amended, he or she should feel free to open a new JIRA against the branch
> including the review comments, and they will be addressed before the merge
> into trunk. And just like with any branch merge, ample time will be given
> for the community to review both the large merge commit as well as the
> individual historical commits of the branch, before it goes into trunk.
> {quote}
> I'm also volunteering to keep the HDFS-1623 development branch up to date
> with respect to merging the concurrent changes which go into trunk into this
> development branch to make sure the merge back into trunk is as painless as
> possible.
> Comments are certainly welcome on this strategy.
> Thanks a lot,
> Aaron
> --
> Aaron T. Myers
>  Software Engineer, Cloudera

View raw message