hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers" <...@cloudera.com>
Subject Re: HDFS-1623 branching strategy
Date Wed, 13 Jul 2011 00:15:49 GMT
On Mon, Jul 11, 2011 at 1:28 PM, Suresh Srinivas <suresh@hortonworks.com>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

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