Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # general - HDFS-1623 branching strategy


Copy link to this message
-
Re: HDFS-1623 branching strategy
Aaron T. Myers 2011-07-13, 00:15
On Mon, Jul 11, 2011 at 1:28 PM, Suresh Srinivas <[EMAIL PROTECTED]>wrote:

> My preference is to review before commit. Reviewing incremental changes is
> much
> more effective than reviewing one mega patch during merge of a branch.
>

I certainly am not in favor of only reviewing a mega-patch either, and
that's not what I intended to propose. As Eli has already said, CTR doesn't
mean the individual patches don't get reviewed, just that they can be
committed to the branch and then any review feedback can be incorporated
later.

Note: I'm not married to the modified CTR proposal, but it is my preference.
It seems to have worked well previously on MR-279 and HDFS-1073, so seems
like a good idea here as well. I don't see why this branch is meaningfully
different from those.
> 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.
>

Fair point. How about 48 hours?

--
Aaron T. Myers
Software Engineer, Cloudera