Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

+1 (binding) - downloaded both source and binary tarballs and verified the signatures - set up a pseudo-distributed cluster - ran some simple mapreduce jobs - checked the basic web UI Sangjin On Wed, Jul 27, 2016 at 12:57 PM, John Zhuge wrote: > +1 (non-binding) > > -

[jira] [Created] (HADOOP-13434) Add quoting to Shell class

Owen O'Malley created HADOOP-13434: -- Summary: Add quoting to Shell class Key: HADOOP-13434 URL: https://issues.apache.org/jira/browse/HADOOP-13434 Project: Hadoop Common Issue Type: Bug

Re: Feedback on IRC channel

Regarding approaches to cleaning up the Wiki content--how about an approach similar to the Spark cwiki: https://cwiki.apache.org/confluence/display/SPARK/Wiki+Homepage My take is that the Hadoop product docs on hadoop.apache.org generally target (or should target) the audiences described in 1-4

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Hi Junping, thanks for sharing your thoughts, inline, On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 wrote: > Thanks Vinod for bringing up this topic for discussion. I share the same > concern here from my previous experience and I doubt some simple rules > proposed below could

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

+1 (non-binding) - Build source with Java 1.8.0_101 on Centos 7.2 with native - Build source with Java 1.7.0_79 on Mac - Verify license and notice using the shell script in HADOOP-13374 - Deploy a pseudo cluster - Run basic dfs, distcp, ACL, webhdfs commands - Run MapReduce workcount and pi

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> > The -alphaX versions we're using leading up to 3.0.0 GA can be treated as >> a.b.c versions, with alpha1 being the a.b.0 release. >> > > Once 3.0.0 GA goes out, a user would want to see the diff from the latest > 2.x.0 release (say 2.9.0). > > Are you suggesting 3.0.0 GA would have c = 5 (say)

Wiki migration and clean-up

Hi Ray, The migration is much needed, and thanks for initiating it. Regarding approaches to cleaning up the Wiki content--my 2 cents is in favor an approach similar to the Spark cwiki: https://cwiki.apache.org/confluence/display/SPARK/Wiki+Homepage My take is that the Hadoop product docs on

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

+1 (binding) - Downloaded binary tarball - verified signatures - setup pseudo cluster - ran some of the example jobs, clicked around the UI a bit - Robert On Mon, Jul 25, 2016 at 3:28 PM, Jason Lowe wrote: > +1 (binding) > - Verified signatures and digests-

Re: Feedback on IRC channel

Good to know. It's certainly easier to set up an alternate location in any case and then do a wholesale migration. It saves from having that "under construction" look before it's complete. I'll get on the appropriate infra@ list and ask about recommendations. -Ray On 7/26/16 10:49 PM,

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Thanks Vinod for bringing up this topic for discussion. I share the same concern here from my previous experience and I doubt some simple rules proposed below could make life easier. > The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix versions. > Allen's historical perspective is

Apache Hadoop qbt Report: trunk+JDK8 on Linux/x86

For more details, see https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/115/ [Jul 26, 2016 1:30:02 PM] (stevel) Revert "HDFS-10668. Fix intermittently failing UT [Jul 26, 2016 1:53:37 PM] (kai.zheng) HADOOP-13041. Adding tests for coder utilities. Contributed by Kai [Jul 26, 2016

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Inline. > 1) Set the fix version for all a.b.c versions, where c > 0. > 2) For each major release line, set the lowest a.b.0 version. > Sounds reasonable. > > The -alphaX versions we're using leading up to 3.0.0 GA can be treated as > a.b.c versions, with alpha1 being the a.b.0 release. >

[jira] [Created] (HADOOP-13433) Race in UGI.reloginFromKeytab

Duo Zhang created HADOOP-13433: -- Summary: Race in UGI.reloginFromKeytab Key: HADOOP-13433 URL: https://issues.apache.org/jira/browse/HADOOP-13433 Project: Hadoop Common Issue Type: Bug

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

Hi All +1 (non-binding) - Compiled and created tar ball from source - Tested few MR jobs with node labels - Verified UI Thanks Sunil On Sat, Jul 23, 2016 at 7:45 AM Vinod Kumar Vavilapalli wrote: > Hi all, > > I've created a release candidate RC0 for Apache Hadoop 2.7.3. >

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

+1 for the source tarball. - Compiled and built from the source code - Deployed a cluster - Successfully ran some sample jobs. Thanks, Jian > On Jul 27, 2016, at 10:11 AM, Akira Ajisaka > wrote: > > +1 for the source tarball. > > - Downloaded source tarball and

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Thanks Andrew for sharing your thoughts, It looks better if we can put multiple versions on the fix version, with that we can at least do some queries on JIRA to check the issues like "in branch-2.6.5 but not in branch-2.7.4". I still have a couple of questions: *1) How CHANGES.txt (or release

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> I think I understand a bit better, though now I ask how this date is > different from the release date. OIC. I also assume that the freezing branch cannot include the changes between freezing date and the release date. This is for strict ordering to ensure which is the newer. If we have lots

[jira] [Created] (HADOOP-13432) S3A: Consider using TransferManager.download for copyToLocalFile

Rajesh Balamohan created HADOOP-13432: - Summary: S3A: Consider using TransferManager.download for copyToLocalFile Key: HADOOP-13432 URL: https://issues.apache.org/jira/browse/HADOOP-13432

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I think I understand a bit better, though now I ask how this date is different from the release date. Based on the HowToRelease instructions, we set the release date to when the release vote passes. So, start of release vote vs. end of release vote doesn't seem that different, and these dates are

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> Andrew: I bet many would assume it's the release date, like how Ubuntu releases are numbered. Good point. Maybe I confuse you because of lack of explanation. I assume that "branch-cut off timing" mean the timing of freezing branch like when starting the release vote. It's because that the