Sounds good to me. I think this strategy has worked well on the HDFS-1073
branch -- allowed development to be quite rapid, and at this point all but a
couple trivial patches have been explicitly reviewed by a committer (and the
others implicitly reviewed since later patches touched the same code area).
+1.
-Todd
On Thu, Jul 7, 2011 at 1:43 PM, Aaron T. Myers <a...@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
>
--
Todd Lipcon
Software Engineer, Cloudera
