Re: [VOTE] Merge feature branch YARN-5355 (Timeline Service v2) to trunk

2017-08-30 Thread varunsax...@apache.org
Yes, I had used "git merge --no-ff" while merging ATSv2 to trunk. Maintaining history I believe can be useful as it can make reverts easier if at all required. And can be an easy reference point to look at who had contributed what without having to go back to the branch. Regards, Varun Saxena. O

Re: [VOTE] Merge feature branch YARN-5355 (Timeline Service v2) to trunk

2017-08-30 Thread Vrushali C
Thanks Sangjin for the link to the previous discussions on this! I think that helps answer Steve's questions. As decided on that thread [1], YARN-5355 as a feature branch was merged to trunk via "git merge --no-ff" . Although trunk already had TSv2 code (alpha1) prior to this merge, we chose to d

Re: [VOTE] Merge feature branch YARN-5355 (Timeline Service v2) to trunk

2017-08-30 Thread Colin McCabe
The "git" way of doing things would be to rebase the feature branch on master (trunk) and then commit the patch stack. Squashing the entire feature into a 10 MB megapatch is the "svn" way of doing things. The svn workflow evolved because merging feature branches back to trunk was really painful i

Re: [VOTE] Merge feature branch YARN-5355 (Timeline Service v2) to trunk

2017-08-30 Thread Sangjin Lee
I recall this discussion about a couple of years ago: https://lists.apache.org/thread.html/43cd65c6b6c3c0e8ac2b3c76afd9eff1f78b177fabe9c4a96d9b3d0b@1440189889@%3Ccommon-dev.hadoop.apache.org%3E On Wed, Aug 30, 2017 at 2:32 PM, Steve Loughran wrote: > I'd have assumed it would have gone in as one

Re: [VOTE] Merge feature branch YARN-5355 (Timeline Service v2) to trunk

2017-08-30 Thread Steve Loughran
I'd have assumed it would have gone in as one single patch, rather than a full history. I don't see why the trunk needs all the evolutionary history of a build. What should our policy/process be here? I do currently plan to merge the s3guard in as one single squashed patch; just getting HADOOP

[jira] [Resolved] (MAPREDUCE-6949) yarn.app.mapreduce.am.log.level is not documented in mapred-default.xml

2017-08-30 Thread Haibo Chen (JIRA)
[ https://issues.apache.org/jira/browse/MAPREDUCE-6949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Haibo Chen resolved MAPREDUCE-6949. --- Resolution: Duplicate > yarn.app.mapreduce.am.log.level is not documented in mapred-defaul

[jira] [Created] (MAPREDUCE-6949) yarn.app.mapreduce.am.log.level is not documented in mapred-default.xml

2017-08-30 Thread Haibo Chen (JIRA)
Haibo Chen created MAPREDUCE-6949: - Summary: yarn.app.mapreduce.am.log.level is not documented in mapred-default.xml Key: MAPREDUCE-6949 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6949 Proje

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

2017-08-30 Thread Apache Jenkins Server
For more details, see https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/508/ [Aug 29, 2017 11:21:14 AM] (sunilg) YARN-6386. Show decommissioning nodes in new YARN UI. Contributed by [Aug 29, 2017 11:36:22 AM] (aajisaka) HADOOP-14671. Upgrade to Apache Yetus 0.5.0. [Aug 29, 2017 2:5

[jira] [Created] (MAPREDUCE-6948) TestJobImpl.testUnusableNodeTransition failed

2017-08-30 Thread Haibo Chen (JIRA)
Haibo Chen created MAPREDUCE-6948: - Summary: TestJobImpl.testUnusableNodeTransition failed Key: MAPREDUCE-6948 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6948 Project: Hadoop Map/Reduce

Re: Apache Hadoop 2.8.2 Release Plan

2017-08-30 Thread Junping Du
Thanks Brahma for comment on this thread. To be clear, I always update branch version just before RC kicking off. For 2.8.2 release, I don't have plan to involve big top or other third-party test tools. As always, we will rely on test/verify efforts from community especially from large deployed