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
The point isn't when the consolidated patches were posted to the JIRA.
The branch is on the public SVN and has been for months. The work was
done incrementally on the branch, and you were welcome (and
encouraged) to review it all along. The consolidated patches are
mostly there in order to get a "Hadoop QA" run against the branch,
since we can't currently run the QA bot on anything but trunk.


On Wed, Feb 20, 2013 at 1:48 PM, Tsz Wo Sze <[EMAIL PROTECTED]> wrote:
> The previous patch of HDFS-347 was posted on Jan 31
> (2013.01.31.consolidated2.patch)  I have tried to review it but the code is
> quite unreadable at that time.  Then, the next patch is the latest patch
> 2013.02.15.consolidated4.patch posted in the evening of Feb 15, right before
> the weekends.  As mentioned previously, I did not get a chance to check it
> until yesterday (Feb 19).
> The currently patch is still not yet ready.  It seems to have unnecessarily
> changed the API and protocol.  I believe those are important but not trivial
> things.
> Tsz-Wo
> ________________________________
> From: Todd Lipcon <[EMAIL PROTECTED]>
> Sent: Wednesday, February 20, 2013 12:16 PM
> Subject: Re: VOTE: HDFS-347 merge
> 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]>
>> 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
Todd Lipcon
Software Engineer, Cloudera