hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers" <...@cloudera.com>
Subject HDFS-1623 branching strategy
Date Thu, 07 Jul 2011 20:43:04 GMT
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:

- 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.

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

Comments are certainly welcome on this strategy.

Thanks a lot,

Aaron T. Myers
 Software Engineer, Cloudera

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message