hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Srinivas <sur...@hortonworks.com>
Subject Re: HDFS-1623 branching strategy
Date Mon, 11 Jul 2011 20:28:34 GMT
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

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