[ https://issues.apache.org/jira/browse/HDFS-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125876#comment-14125876 ]
Konstantin Shvachko commented on HDFS-6940: ------------------------------------------- > why doing this refactor, which is really mostly just opening up visibility of > a host of methods, will make merging from/to trunk easier? I unswered this already. Will elaborate. Working on a branch means a lot of merging from trunk to the branch intended to keep the bunch in sync with trunk. So it used to be a general practice in this community to make initial refactoring on the trunk, if such changes keep the trunk in working condition, in order to easy those frequent merges. [Found this conversation, for example|https://issues.apache.org/jira/browse/HDFS-4942?focusedCommentId=13706469&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13706469]. Aaron, you never commented or objected on the patch itself. My understanding that you are questioning the implementation of ConsensusNode via sub-classing the NameNode. You actually posted your reservations even before the patch was submitted. I did create a jira to discuss ConsensusNode interfaces including your topic HDFS-7007. And this jira has nothing to do with NameNode subclassing. At all. I did ask explicitly if you have technical objections to the patch, and since you did not reply I assumed you don't have any. > Initial refactoring to allow ConsensusNode implementation > --------------------------------------------------------- > > Key: HDFS-6940 > URL: https://issues.apache.org/jira/browse/HDFS-6940 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: namenode > Affects Versions: 2.0.6-alpha, 2.5.0 > Reporter: Konstantin Shvachko > Assignee: Konstantin Shvachko > Fix For: 2.6.0 > > Attachments: HDFS-6940.patch > > > Minor refactoring of FSNamesystem to open private methods that are needed for > CNode implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)