[jira] [Resolved] (HDFS-4507) Update quota verification for snapshot

[ https://issues.apache.org/jira/browse/HDFS-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE resolved HDFS-4507. -- Resolution: Fixed Fix Version/s: Snapshot (HDFS-2802) Hadoop Flags: R

[jira] [Created] (HDFS-4538) allow use of legacy blockreader

Colin Patrick McCabe created HDFS-4538: -- Summary: allow use of legacy blockreader Key: HDFS-4538 URL: https://issues.apache.org/jira/browse/HDFS-4538 Project: Hadoop HDFS Issue Type: Sub

RE: [Vote] Merge branch-trunk-win to trunk

+1 (non-binding) I am really glad to see this happening! As people already mentioned, this has been a great engineering effort involving many people! Folks raised some valid concerns below and I thought it would be good to share my 2 cents. In my opinion, we don't have to solve all these probl

Re: [Vote] Merge branch-trunk-win to trunk

> > I'm concerned about the above. Personally, I don't have access to any > Windows boxes with development tools, and I know nothing about developing > on Windows. The only Windows I run is an 8GB VM with 1 GB RAM allocated, > for powerpoint :) > If I submit a patch and it gets -1 "tests failed"

Re: [Vote] Merge branch-trunk-win to trunk

On Wed, Feb 27, 2013 at 2:54 PM, Suresh Srinivas wrote: > With that we need to decide how our precommit process looks. > My inclination is to wait for +1 from precommit builds on > both the platforms to ensure no issues are introduced. > Thoughts? > > 2. Feature development impact > Some questions

Re: VOTE: HDFS-347 merge

+1 It sounds like restoring 2246 to the 347 patch is the only path forward (ie there will be zero compromise on a proposal that removes 2246 in any form) in which case this seems like a good way to implement that (similar to what Sanjay suggested earlier). We can have a separate jira for removing

Re: VOTE: HDFS-347 merge

Suresh offered to write a patch restoring HDFS-2246, so unless his timeline is unacceptable, I think we're done. On Wed, Feb 27, 2013 at 11:45 AM, sanjay Radia wrote: > It is not being held back of for the windows port. It is being held back > because 2246 should not be removed as part of 347; a

Re: VOTE: HDFS-347 merge

Here is a compromise proposal, which hopefully will satisfy both sides: We keep the old block reader and have a configuration option that enables it. So in addition to dfs.client.use.legacy.blockreader, which we already have, we would have dfs.client.use.legacy.blockreader.local. Does that make s

Re: [Vote] Merge branch-trunk-win to trunk

Thanks for raising good questions. Currently the merge patch passes all the tests on Linux, hence the proposal for merging the patch to trunk. But as Bobby, Harsh and Eli pointed out, before declaring support for Windows, we need the discussion on the following: 1. Precommit and development proce

Re: [Vote] Merge branch-trunk-win to trunk

+1 non-binding. I have extensively tested this on both Windows and Linux over the last few months. Thanks, -Arpit On Wed, Feb 27, 2013 at 11:56 AM, Eli Collins wrote: > Bobby raises some good questions. A related one, since most current > developers won't add Windows support for new features

Re: VOTE: HDFS-347 merge

On Wed, Feb 27, 2013 at 11:45 AM, sanjay Radia wrote: > > On Feb 26, 2013, at 1:51 PM, Eli Collins wrote: > >> it doesn't seem right to hold up 347 up for Windows support given that >> Windows support has not been merged to trunk yet, is not in any Apache >> release, etc. Personally I don't like e

Re: [Vote] Merge branch-trunk-win to trunk

Bobby raises some good questions. A related one, since most current developers won't add Windows support for new features that are platform specific is it assumed that Windows development will either lag or will people actively work on keeping Windows up with the latest? And vice versa in case Wi

Re: VOTE: HDFS-347 merge

On Feb 26, 2013, at 1:51 PM, Eli Collins wrote: > it doesn't seem right to hold up 347 up for Windows support given that > Windows support has not been merged to trunk yet, is not in any Apache > release, etc. Personally I don't like establishing the precedent here > that we can hold up a merge d

Re: [Vote] Merge branch-trunk-win to trunk

Similar personal concern as Robert: Does this bring about a development process change? Do new features all need to work on Windows as well to go into trunk (i.e. immediately or eventually, either way requires a new policy for all of us devs)? Not that anyone would be avoiding doing that, I just as

Re: [Vote] Merge branch-trunk-win to trunk

After this is merged in is Windows still going to be a second class citizen but happens to work for more than just development or is it a fully supported platform where if something breaks it can block a release? How do we as a community intend to keep Windows support from breaking? We don't have

[jira] [Created] (HDFS-4537) Add Last-Access Time Format to FsShell Stat Command

Nick White created HDFS-4537: Summary: Add Last-Access Time Format to FsShell Stat Command Key: HDFS-4537 URL: https://issues.apache.org/jira/browse/HDFS-4537 Project: Hadoop HDFS Issue Type: Bug

[jira] [Created] (HDFS-4536) Add test methods in org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.TestFairScheduler

Vadim Bondarev created HDFS-4536: Summary: Add test methods in org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.TestFairScheduler Key: HDFS-4536 URL: https://issues.apache.org/jira/browse/HDFS-4536

Jenkins build is back to normal : Hadoop-Hdfs-trunk #1329

See