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

Switch to Threaded View
HDFS, mail # dev - VOTE: HDFS-347 merge


Copy link to this message
-
Re: VOTE: HDFS-347 merge
Suresh Srinivas 2013-02-20, 22:49
Todd,

Some of us have been trying to help test and review the code. However you
might have missed the following, which has resulted in the review not
completing:

02/06/13 - After intent for merge was sent, I posted comment saying
consolidate patch has extraneous changes. That was non trivial amount of
extraneous changes.
02/06/13 - Nicholas posted some comments and also indicated previous
unaddressed comments.
02/15/13 - No update was made to consolidated patch. I stopped reviewing it
waiting for the new patch. A new patch gets posted on 2/15 and soon after
merge vote email on 2/17/13 during the long weekend.

At this time, some of the comments that were made earlier have not been
addressed. Also folks who were reviewing the consolidated patch have not
posted +1.

I think we should wait for +1 for the merge patch (from the folks actively
reviewing the patch) before the merge vote. That might make this process
smoother. But  I agree, if the changes are deemed to be trivial, we can do
it post merge to trunk.

Regards,
Suresh
On Wed, Feb 20, 2013 at 12:16 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:

> Hi Nicholas,
>
> I looked at your comments on the JIRA, and they all seem like trivial
> things that could be addressed post-merge, and none of them would
> affect the functionality. If Colin addresses these issues, will you
> amend your vote to +1 within the called-for voting period?
>
> It concerns me that we've been asking for reviews on this branch for
> multiple months now, and yet you're only bringing up some of these
> things now that a merge vote is called. Colin sentp a note to this
> list a month ago (http://markmail.org/message/phcfc3watwlqiemw) saying
> that the merge was coming soon. Since then, we found a few small bugs
> around the configuration/setup code, but all of the things you're
> bringing up in the review now have been in the branch since the new
> year, so I feel like there has been quite ample time for review.
>
> -Todd
>
> On Wed, Feb 20, 2013 at 11:56 AM, Tsz Wo Sze <[EMAIL PROTECTED]> wrote:
> > -1
> > The patch seems not ready yet.  I have posted some comments/suggestions
> on the JIRA.  Colin also has agreed that there are some bugs to be fixed.
>  Sorry.
> >
> > Tsz-Wo
> >
> >
> >
> >
> > ________________________________
> >  From: Todd Lipcon <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Sent: Tuesday, February 19, 2013 4:11 PM
> > Subject: Re: VOTE: HDFS-347 merge
> >
> > +1 (binding)
> >
> > I code-reviewed almost all of the code in this branch, and also spent
> some
> > time benchmarking and testing under various workloads. We've also done
> > significant testing on clusters here at Cloudera, both secure and
> insecure,
> > and verified integration with a number of other ecosystem components (eg
> > Pig, Hive, Impala, HBase, MR, etc). The feature works as advertised and
> > should provide much better performance for a number of workloads,
> > especially in secure environments.
> >
> > Thanks for the hard work, Colin!
> >
> > -Todd
> >
> > On Sun, Feb 17, 2013 at 1:48 PM, Colin McCabe <[EMAIL PROTECTED]
> >wrote:
> >
> >> Hi all,
> >>
> >> I would like to merge the HDFS-347 branch back to trunk.  It's been
> >> under intensive review and testing for several months.  The branch
> >> adds a lot of new unit tests, and passes Jenkins as of 2/15 [1]
> >>
> >> We have tested HDFS-347 with both random and sequential workloads. The
> >> short-circuit case is substantially faster [2], and overall
> >> performance looks very good.  This is especially encouraging given
> >> that the initial goal of this work was to make security compatible
> >> with short-circuit local reads, rather than to optimize the
> >> short-circuit code path.  We've also stress-tested HDFS-347 on a
> >> number of clusters.
> >>
> >> This iniial VOTE is to merge only into trunk.  Just as we have done
> >> with our other recent merges, we will consider merging into branch-2
> >> after the code has been in trunk for few weeks.

http://hortonworks.com/download/