Re: [VOTE] Release Apache Hadoop 2.7.2 RC0

Forked the "tag vs commit id" point into a separate thread in order to not disturb the voting thread. Here’s your SHA1: 6f38ccc6741a51a0cb64772c35e3cbab635f11c4 +Vinod > On Nov 12, 2015, at 10:01 AM, Steve Loughran wrote: > > What's the relevant SHA1?

Jenkins build is back to normal : Hadoop-Common-trunk #1987

See

Jenkins build is back to normal : Hadoop-common-trunk-Java8 #687

See

Re: [VOTE] Release Apache Hadoop 2.7.2 RC0

+1 (Non-binding): - Deployed local cluster from binary - Configured CS with node label - Ran jobs with/without labels - Ran distributed shell / MR jobs. Thanks, Wangda On Wed, Nov 11, 2015 at 8:31 PM, Vinod Kumar Vavilapalli wrote: > Hi all, > > > I've created a release

[jira] [Created] (HADOOP-12565) Setup passphraseless SSH does not work on all systems

Alexander Veit created HADOOP-12565: --- Summary: Setup passphraseless SSH does not work on all systems Key: HADOOP-12565 URL: https://issues.apache.org/jira/browse/HADOOP-12565 Project: Hadoop Common

Release votes and git-tags [Was Re: [VOTE] Release Apache Hadoop 2.7.2 RC0]

We have always voted on release tar-balls, not svn branches / git commit-ids or tags. When we were on SVN, we used to paste in the voting thread the release branch URL. Since we moved to git, we stopped creating release branches and have always used signed tags for snapshotting and posted

Build failed in Jenkins: Hadoop-common-trunk-Java8 #688

See Changes: [wangda] YARN-4287. Capacity Scheduler: Rack Locality improvement (Nathan Roberts [wangda] YARN-4347. Resource manager fails with Null pointer exception. (Jian He [zhz] HDFS-8968. Erasure coding: a

Build failed in Jenkins: Hadoop-Common-trunk #1986

See Changes: [wheat9] HADOOP-12562. Make hadoop dockerfile usable by Yetus. Contributed by [wangda] YARN-4287. Capacity Scheduler: Rack Locality improvement (Nathan Roberts [wangda] YARN-4347. Resource manager fails with Null

Re: Need for force-push on feature branches

> On 11 Nov 2015, at 22:47, Sangjin Lee wrote: > > If we do use "feature/..." as the branch naming convention, it does pose an > issue with the patch naming due to the separator character ('/'). How about > "feature-..."? In most spark UIs, they get treated as subdirectories

[jira] [Created] (HADOOP-12567) NPE in SaslRpcServer

Sergey Shelukhin created HADOOP-12567: - Summary: NPE in SaslRpcServer Key: HADOOP-12567 URL: https://issues.apache.org/jira/browse/HADOOP-12567 Project: Hadoop Common Issue Type: Task

[jira] [Created] (HADOOP-12566) Add NullGroupMapping

Daniel Templeton created HADOOP-12566: - Summary: Add NullGroupMapping Key: HADOOP-12566 URL: https://issues.apache.org/jira/browse/HADOOP-12566 Project: Hadoop Common Issue Type:

[jira] [Created] (HADOOP-12568) Update core-default.xml to describe posixGroups support

Wei-Chiu Chuang created HADOOP-12568: Summary: Update core-default.xml to describe posixGroups support Key: HADOOP-12568 URL: https://issues.apache.org/jira/browse/HADOOP-12568 Project: Hadoop

[GitHub] hadoop pull request: Branch 2.7.1

GitHub user hellodengfei opened a pull request: https://github.com/apache/hadoop/pull/45 Branch 2.7.1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/hellodengfei/hadoop branch-2.7.1 Alternatively you can review and apply these

Re: [DISCUSS] Looking to a 2.8.0 release

Thank you Vinod for starting this discussion. +1 for getting a beta/alpha version for Application Priority (YARN-1963). Major patches are already in and MAPREDUCE-5870 (making MR also to use app-priority) is in final review stages. This feature is also tested in-house. With 2.8.0 alpha, I feel we

Re: [DISCUSS] Looking to a 2.8.0 release

There's a lot of stuff in 2.8; I note that I'd like to see the s3a perf improvements & openstack fixes in there: for which I need reviewers. I don't have the spare time to do this myself. I've already been building & testing both Apache Slider (incubating) and Apache Spark against both

Build failed in Jenkins: Hadoop-common-trunk-Java8 #686

See Changes: [jlowe] YARN-4345. yarn rmadmin -updateNodeResource doesn't work. Contributed by -- [...truncated 5783 lines...] Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time

Build failed in Jenkins: Hadoop-Common-trunk #1985

See Changes: [jlowe] YARN-4345. yarn rmadmin -updateNodeResource doesn't work. Contributed by -- [...truncated 8531 lines...] [javadoc] Loading source files for package

Re: Need for force-push on feature branches

Yes, I completely understand about the git branch naming practice (in fact that's what I normally do). I was commenting on our hadoop patch naming convention. We are supposed to use patch names as "-..patch". If we used "feature/HADOOP-12345" as the git branch name and the subtask JIRA was

Re: Need for force-push on feature branches

I suppose that would be fine too. Yetus just needs to add "feature/" to the git branch name when it fails to find it as is. So it would require a little work on yetus, but I guess should be pretty trivial? On Thu, Nov 12, 2015 at 9:59 AM, Steve Loughran wrote: > > > On

Re: Need for force-push on feature branches

Implementing project-specific patch identification rules are definitely ‘not trivial’. FWIW, the documented ruleset Yetus supports is here: https://yetus.apache.org/documentation/latest/precommit-patchnames/ (Altho, in reality, the code does support more than this but they are sort

Re: Need for force-push on feature branches

> On Nov 12, 2015, at 10:14 AM, Sangjin Lee wrote: > > I don't think we're proposing project-specific rules. It would be a > recognition of the git branch name prefix "feature/". > > If the file name had "HADOOP-67890-HADOOP-12345.001.patch" where > HADOOP-12345 was the

Re: Need for force-push on feature branches

> On 12 Nov 2015, at 17:49, Sangjin Lee wrote: > > Yes, I completely understand about the git branch naming practice (in fact > that's what I normally do). I was commenting on our hadoop patch naming > convention. We are supposed to use patch names as > "-..patch". > > If we

Re: [VOTE] Release Apache Hadoop 2.7.2 RC0

> On 12 Nov 2015, at 04:31, Vinod Kumar Vavilapalli wrote: > > Hi all, > > > I've created a release candidate RC0 for Apache Hadoop 2.7.2. > > > As discussed before, this is the next maintenance release to follow up > 2.7.1. > > > The RC is available for validation at:

Re: Need for force-push on feature branches

I don't think we're proposing project-specific rules. It would be a recognition of the git branch name prefix "feature/". If the file name had "HADOOP-67890-HADOOP-12345.001.patch" where HADOOP-12345 was the feature JIRA but the git branch was "feature/HADOOP-12345", if yetus didn't find a branch

Re: [DISCUSS] Looking to a 2.8.0 release

I am really against the notion of calling x.y.0 releases alpha/beta; it is very confusing. If we think a release is alpha/beta quality, why not release it as x.y.0-alpha or x.y.0-beta, and follow it up eventually with x.y.0 GA. I am in favor of labeling any of the newer features to be of

Re: [DISCUSS] Looking to a 2.8.0 release

Did we consider cutting a branch-3 that borrows relatively compatible patches from trunk to run the 3.x line? That said, I would like for us to really tighten our compatibility policies and actually stick to them starting the next major release. On Wed, Nov 11, 2015 at 1:11 PM, Vinod Vavilapalli

Re: Github integration for Hadoop

gerrit has a button on the UI to cherry-pick to different branches. The button creates separate "gerrit changes" which you can then commit. Eventually we could hook those up to Jenkins-- something which we've never been able to do for different branches with the patch-file-based workflow. best,