Sorry for the late reply... My concern is not about creating a branch. Using a branch is some thing we have been doing for a long time for feature development and it is effective. Infact I am eager for branch for HA to be created, to start submitting the patches I am currently working on.
Here are some of my concerns: Commit-then-review: I have same concerns expressed by Jakob, about commit and review. My preference is to review before commit. Reviewing incremental changes is much more effective than reviewing one mega patch during merge of a branch. Diverging solutions: Second unrelated problem to branching is - in HDFS-1623, the design defines common elements to build HA solution. The idea was, it could enable different solutions depending on how folks want to go about it. I would like to make sure that we are all converging, instead of diverging. This means some of the jiras still need to be discussed, especially the ones that make major structural changes, adds interfaces etc. I am not sure 24 hr is a long enough notice. >From what I also know, HDFS-2064 HA is being planned for release 0.22. At an early glance, this seems to be closely tied to Backup node and not generic enough (will post comments to jira). Given that this is added to 0.22, how does that impact the current HA plans and backward compatibility requirements? Release 0.23: Initial plan was to make HA part of post 0.23 (as discussed in contributors meetup). It would be good to work in that direction and commit changes to HDFS-1623 branch instead of making changes in the trunk, to ensure stability of the trunk. HADOOP-7380 went into trunk. It would be better for such changes to go into HDFS-1623 branch. We should merge this branch post 0.23 into trunk. Regards, Suresh
