+1, this sounds like a very good approach. -dhruba
On Thu, Jul 7, 2011 at 4:33 PM, Eli Collins <[email protected]> wrote: > +1 > > 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 <[email protected]> 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 > > > -- Connect to me at http://www.facebook.com/dhruba
