Re: [DISCUSS] Replacing the automatic Jenkins jobs with Apache Yetus qbt

> On Jun 1, 2016, at 10:51 AM, Chris Nauroth wrote: > It looks like Failed junit tests removes the "org.apache" prefix, but > Timed out junit tests does not. If possible, it would be nice for this to > be consistent. Ha. It's been that way in Yetus for a very,

Re: [DISCUSS] Replacing the automatic Jenkins jobs with Apache Yetus qbt

> On May 31, 2016, at 8:53 PM, Andrew Wang wrote: > > I'm in favor of something that helps unify the current mess of Jenkins > jobs. We do something similar for our internal Hadoop repo: each branch has > a "build.sh" and "test.sh" script that builds and then runs the

Re: About fix versions

> On May 29, 2016, at 5:16 AM, Zheng, Kai wrote: > > Thanks Allen a lot. This is comprehensive. > >>> So if a patch has been committed to branch-2.8, branch-2, and trunk, then >>> the fix version should be 2.8.0 and only 2.8.0. > This sounds like the right rule I seem

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

> On Jun 17, 2016, at 7:04 AM, Apache Jenkins Server > wrote: > > For more details, see > https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/66/ > I suspect this change: > [Jun 16, 2016 11:17:06 AM] (vinayakumarb) HDFS-10256. Use >

Re: [DISCUSS} why is checkstyle harassing me on indentation?

> On Jan 18, 2016, at 11:34 AM, Steve Loughran wrote: > > > Yetus checkstyle is going a bit overboard on indentation policy Just the messenger. ;) FWIW: https://wiki.apache.org/hadoop/CodeReviewChecklist

node.js and more as dependencies

Hey folks. Have any of you looked at YARN-3368? Is adding node.js+a bunch of other stuff as dependencies just for the UI a good idea? Doesn’t that seem significantly heavyweight? How hard is this going to be operationally to manage?

[IMPORTANT] flag day for dev-support/ users

This is just a heads up that the contents of dev-support have changed due to HADOOP-12651. This patch effectively removes almost all of the Apache Yetus components and replaces them with wrappers now located in dev-support/bin. Note that in some cases (esp smart-apply-patch),

Re: TestPatchTips wiki not working for me

> On Jan 26, 2016, at 12:19 PM, Ray Chiang wrote: > > Not sure if this should go to Yetus or here, but starting here... > > Maybe I'm missing something, but the commands as documented at > > https://wiki.apache.org/hadoop/TestPatchTips > > are no longer working for me.

Re: 2.7.3 release plan

This is probably a good time to remind/point folks to HADOOP-12893. Apache Hadoop's binary artifacts (with or without native code) and source artifacts are not complying with the licenses of bundled components. I fairly confident this means releases are off the table until someone

Re: Branch policy question

> On Mar 22, 2016, at 10:49 AM, larry mccay wrote: > > That sounds like a reasonable approach and valid use of branches to me. > > Perhaps a set of functional tests could be provided/identified that would > help the review process by showing backward compatibility along

Branch policy question

Since it’s nearly impossible for me to get timely reviews for some build and script changes, is it possible for me to setup a branch, self review+commit to that branch, then request a branch merge? I’m basically looking at doing this for HADOOP-12857 + HADOOP-12930 and their subtasks

Re: Branch policy question

> On Mar 23, 2016, at 10:25 AM, Chris Nauroth wrote: > > 2. Apache feature branches: Sign-off may come from designated branch > committers in addition to full committers. It's OK to break the branch > for work in progress, but it must be fixed before a merge. It's

Review request: HADOOP-11393

This effectively makes the bash code the same as the Windows code with regards to using HADOOP_HOME as the base of operation. It is a large patch, but all it does is: * replace every occurrence of HADOOP_PREFIX with HADOOP_HOME with the standard bits to use and give a deprecation

Re: Branch policy question

> On Mar 22, 2016, at 6:46 PM, Gangumalla, Uma wrote: > >> is it possible for me to setup a branch, self review+commit to that >> branch, then request a branch merge? > Basically this is something like Commit-Then-Review(here review later) > process right. I have not

hadoop-integration-tests jenkins job

Given that we’re down to half our capacity in build-land, it’s interesting to see what everyone’s running since everything runs slower. You can find some interesting bits. Like ‘hadoop-integration-tests’. Is this job actually providing any value, especially with an aggressive

Precommit changed to Yetus 0.2.0 release, src version to follow soon

FYI, Apache Yetus 0.2.0 passed vote this morning. In accordance with ASF rules, I’m setting the precommit scripts to use that version rather than Yetus master. As soon as it is officially announced and available on ASF dist servers worldwide, I’ll be filing the necessary jira to update the

Re: Looking to a Hadoop 3 release

> On Apr 22, 2016, at 5:38 PM, Vinod Kumar Vavilapalli > wrote: > > On an unrelated note, offline I was pitching to a bunch of contributors > another idea to deal with rotting trunk post 3.x: *Make 3.x releases off of > trunk directly*. > > What this gains us is that > -

Re: Looking to a Hadoop 3 release

> On Apr 22, 2016, at 6:10 PM, Vinod Kumar Vavilapalli > wrote: > > Nope. > > I’m proposing making a new 3.x release (as has been discussed in this thread) > off today’s trunk (instead of creating a fresh branch-3) and create a new > trunk-incompt where incompatible

Re: Recent PreCommit Jenkins failures

> On Apr 27, 2016, at 3:53 PM, Arun Suresh wrote: > > which I guess is due to the haskell site throwing a 502 and prior to that I > saw a couple of failures with > hackage.haskell.org has been down all day for some reason. I’ve got a patch sitting in HADOOP-13067 which

Re: [DISCUSS] upgrade tomcat from 6.0.44 to 6.0.45 and use non apache.org mirror

> On May 17, 2016, at 8:32 PM, Wangda Tan wrote: > > I'm not sure if archive.apache.org enforces some new bandwidth limit > policies recently, I haven't seen such bandwidth limits before. We should > consider to fix it If more people complaint about such failures.

Re: [DISCUSS] upgrade tomcat from 6.0.44 to 6.0.45 and use non apache.org mirror

Some potential ways to fix this: a) Move away from tomcat to one of the other two? three? maybe even four? application servers that are already in the Apache Hadoop build b) Move to embedded tomcat so that the jars, etc, get downloaded as part of the maven build Either

Re: Compatibility guidelines for toString overrides

-1 without an audit of every toString usage. We have recent examples (e.g., HDFS-9732) where toString was used for output from CLI utilities. (which, IMO, should never have been done, but it’s too late now...) Output of CLI utilities is most definitely covered by the compatibility

Re: Tons of "javac: invalid target release: 1.8" failures happen on YARN precommit runs

> On May 17, 2016, at 10:54 AM, Wangda Tan wrote: > > Hi YARN-dev/Common-dev, > > I noticed lots of "javac: invalid target release: 1.8" failures happen on > YARN precommit runs since yesterday, not sure if other projects like HDFS > face the same issue. > > Filed

Re: [DISCUSS] upgrade tomcat from 6.0.44 to 6.0.45 and use non apache.org mirror

> On May 17, 2016, at 2:08 PM, Wangda Tan wrote: > > Then I investigated a little more, there're two issues from what I can see > 1) If you look at http://archive.apache.org/dist/, it clearly says: > *> Please do not download from apache.org !* > > 2)

Re: Different JIRA permissions for HADOOP and HDFS

gt; >>>>> On Mon, May 16, 2016 at 1:21 AM, Zhihai Xu >><zhi...@uber.com <mailto:zhi...@uber.com>> >>> wrote: >>> > >>>>> >>> > >>>>> Currently I also have permission issue to access the JIRA. >

Re: [DISCUSS] Set minimum version of Hadoop 3 to JDK8 (HADOOP-11858)

There’s a bunch of stuff that needs to happen at the Jenkins level: * Kill off the JDK7 trunk builds for HADOOP, HDFS, MAPRED, YARN * Remove JDK7 from pre-commit for HADOOP, HDFS, MAPRED, YARN One thing that needs to happen in the Apache Yetus project: * Wait until YETUS-369 has been written

[RESULT] Re: [VOTE] Merge feature branch HADOOP-12930

Vote passes. 1 = +1 non-binding 4 = +1 binding I’ll squash and commit here in a sec. Thanks everyone! - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail:

Re: [DISCUSS] Set minimum version of Hadoop 3 to JDK8 (HADOOP-11858)

OK, it looks like if someone commits HADOOP-13161, then trunk only uses JDK8 and branch-2 will use JDK7 and JDK8 during precommit with no changes required to Apache Yetus. :D > On May 16, 2016, at 5:38 PM, Allen Wittenauer > <allenwittena...@yahoo.com.INVALID> wrote: >

Re: [VOTE] Merge feature branch HADOOP-12930

tried running through new shell tests (both >> with and without bats installed), tried making an example custom >> command (valid and malformed). everything looks great. >> >> On Mon, May 9, 2016 at 1:26 PM, Allen Wittenauer <a...@apache.org> wrote: >>> >

Re: Compatibility guidelines for toString overrides

> On May 12, 2016, at 12:20 PM, Chris Nauroth wrote: > > Hello Allen, > > The intent is not for this rule to override other compatibility rules, > such as the important CLI output rule. It's also not intended to give us > free reign to change existing toString()

Re: Different JIRA permissions for HADOOP and HDFS

> On May 14, 2016, at 7:07 AM, Zheng, Kai wrote: > > Hi, > > Noticed this difference but not sure if it’s intended. YARN is similar with > HDFS. It’s not convenient. Any clarifying? Under JIRA, different projects (e.g., HADOOP, YARN, MAPREDUCE, HDFS, YETUS,

Re: Hadoop CI with alternate architectures.

That’s really a question for infrastructure-...@apache.org . They manage the ASF build infrastructure which Apache Hadoop and lots of other projects utilize. (Bigtop uses something custom, which I think is funded by Cloudera.) Once it is registered with builds.apache.org,

Re: Build failed in Jenkins: Hadoop-common-trunk-Java8 #1502

looks like H3 is about to collapse. > On May 18, 2016, at 10:55 AM, Apache Jenkins Server > wrote: > > See > > -- > [...truncated 4 lines...] > Cloning

Re: [VOTE] Merge feature branch HADOOP-12930

> On May 14, 2016, at 9:04 PM, Masatake Iwasaki > wrote: > > + hadoop_debug "Calling dynamically: hadoop_subcommand_${HADOOP_SUBCMD} > ${HADOOP_SUBCMD_ARGS[$*]}” Easy fix. The $* should just be *. I’ll open an issue and fix it here in a sec.

Re: [VOTE] Merge feature branch HADOOP-12930

was to prevent Jenkins from getting overwhelmed since it would trigger full unit tests on pretty much the entire code base…. > While testing this, I discovered a bug in the distro build for Windows. > Could someone please code review my patch on HADOOP-13149? Done! > > --Chris Nau

Re: [VOTE] Merge feature branch HADOOP-12930

> On May 15, 2016, at 7:27 AM, Allen Wittenauer <a...@apache.org> wrote: > > >> On May 14, 2016, at 9:04 PM, Masatake Iwasaki <iwasak...@oss.nttdata.co.jp> >> wrote: >> >> + hadoop_debug "Calling dynamically: hadoop_subcommand_${HADOOP_SUBC

git commit errors

Just a heads up that I accidentally forced push over branch-2 and branch-2.8 (in the process of pushing a feature branch) around 10am PT this morning that dropped several commits. I have since reset us back to those git refs. If anything has been committed since then, please

Re: Guidance needed on HADOOP-13096 and HADOOP-13097

:22 PM, Larry McCay <lmc...@hortonworks.com> wrote: > > I would vote for C or D with a filed JIRA to clean up the maven structure as > a separate effort. > Before moving to D, could you describe any reason to not go with C? > > On May 4, 2016, at 9:51 PM, Allen Wittena

7 build nodes are down

Anyone know why? - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org

Guidance needed on HADOOP-13096 and HADOOP-13097

When the sub-projects re-merged, maven work was done, whatever, the shell scripts for MR and YARN were placed (effectively) outside of the normal maven hierarchy. In order to add unit tests to the shell scripts for these sub-projects, it means effectively turning

Re: every JIRA is now getting a no-longer-employed message

> On May 5, 2016, at 3:01 AM, Steve Loughran wrote: > > > whenever someone opens a new JIRA, it gains an auto attachment, > "ran...@yahoo-inc.com is no longer with Yahoo! > Inc." ... > > e.g > >

Re: [DISCUSS] Merge Jersey upgrade(HADOOP-9613) to trunk

+1 agreed. > On May 9, 2016, at 2:13 PM, Akira AJISAKA wrote: > > +1 for marking HADOOP-9613 as incompatible change and upgrading the version > in trunk. > > Thanks, > Akira > > On 5/9/16 12:12, Tsuyoshi Ozawa wrote: >> Hi developers, >> >> We’ve worked on

Re: [DISCUSS] Treating LimitedPrivate({"MapReduce"}) as Public APIs for YARN applications

> On May 10, 2016, at 8:37 AM, Hitesh Shah wrote: > > There have been various discussions on various JIRAs where upstream projects > such as YARN apps ( Tez, Slider, etc ) are called out for using the above > so-called Private APIs. A lot of YARN applications that have been

Re: [DISCUSS] Set minimum version of Hadoop 3 to JDK8 (HADOOP-11858)

> On May 10, 2016, at 8:32 AM, Akira AJISAKA wrote: > > Hi developers, > > Before cutting 3.0.0-alpha RC, I'd like to drop JDK7 support in trunk. +1 yes please. > One concern I think is, when the minimum version is set to JDK8, we need to > configure

[VOTE] Merge feature branch HADOOP-12930

Hey gang! I’d like to call a vote to run for 7 days (ending May 16 at 13:30 PT) to merge the HADOOP-12930 feature branch into trunk. This branch was developed exclusively by me as per the discussion two months ago as a way to make what would be a rather large patch hopefully

Re: [DISCUSS] The order of classpath isolation work and updating/shading dependencies on trunk

Does any of this work actually help processes that sit outside of YARN? > On Jul 21, 2016, at 12:29 PM, Sean Busbey wrote: > > thanks for bringing this up! big +1 on upgrading dependencies for 3.0. > > I have an updated patch for HADOOP-11804 ready to post this week. I've

Re: [DISCUSS] 2.6.x line releases

> On Jul 21, 2016, at 5:06 PM, Zhe Zhang wrote: > > We are using 2.6 releases and would like to see 2.6.5. > > One related issue, pre-commit is not working for 2.6 (see comment from > Allen >

Re: Wiki migration and clean-up

I hope you folks are aware that this is much more intensive than just moving a bunch of documents. Lots of wiki pages are referenced in the source code, including in user-facing error messages. > On Jul 28, 2016, at 10:47 AM, Ray Chiang wrote: > > Thanks Martin.

Re: [DISCUSS] The order of classpath isolation work and updating/shading dependencies on trunk

> My work on HADOOP-11804 *only* helps processes that sit outside of YARN. :) > > On Fri, Jul 22, 2016 at 10:48 AM, Allen Wittenauer > <a...@effectivemachines.com> wrote: > > > > Does any of this work actually help processes that sit outside of YARN? > >

Re: [DISCUSS] 2.6.x line releases

> On Jul 22, 2016, at 9:07 AM, Zhe Zhang wrote: > > Thanks Allen for the note. I thought the 2.6 Dockerfile issue was addressed > in https://issues.apache.org/jira/browse/HADOOP-12800? 2.6 builds on JDK6 and JDK7. 2.x, where x>6, builds on JDK7 and JDK8. [1]

Re: Setting JIRA fix versions for 3.0.0 releases

From the perspective of an end user who is reading multiple versions' listings at once, listing the same JIRA being fixed in multiple releases is totally confusing, especially now that release notes are actually readable. "So which version was it ACTUALLY fixed in?" is going to be the

Re: Setting JIRA fix versions for 3.0.0 releases

> On Jul 22, 2016, at 7:16 PM, Andrew Wang wrote: > > Does this mean you find our current system of listing a JIRA as being fixed > in both a 2.6.x and 2.7.x to be confusing? Nope. I'm only confused when there isn't a .0 release in the fix line. When I see

Re: [DISCUSS] The order of classpath isolation work and updating/shading dependencies on trunk

> On Jul 22, 2016, at 5:47 PM, Zheng, Kai wrote: > > For the leveldb thing, wouldn't we have an alternative option in Java for the > platforms where leveldb isn't supported yet due to whatever reasons. IMO, > native library would be best to be used for optimization and

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

I've already asked on builds and infra if it was related to some other changes they made. As usual, radio silence. On the flip side, the PPC machines are making builds and in many ways might be more valuable. e.g., pointing out that the leveldb changes in YARN have pretty much completely

Re: [DISCUSS] The order of classpath isolation work and updating/shading dependencies on trunk

> On Jul 25, 2016, at 1:16 PM, Sangjin Lee wrote: > > Also: right now, the non-Linux and/or non-x86 platforms have to supply their > own leveldbjni jar (or at least the C level library?) in order to make YARN > even functional. How is that going to work with the class path

Re: [Release thread] 2.6.5 release activities

> On Aug 11, 2016, at 5:59 AM, Junping Du wrote: > > These comments are more like wishes but not giving more clarifications > on the needs. I would like to hear more specific reasons to not move to 2.7.x > releases but prefer to upgrade to 2.6.5. If the only reason

Re: [Release thread] 2.6.5 release activities

> On Aug 11, 2016, at 8:10 AM, Junping Du wrote: > > Allen, to be clear, I am not against any branch release effort here. However, "I'm not an X but " > as RM for previous releases 2.6.3 and 2.6.4, I feel to have responsibility to > take care

Re: Assign my Jira to myself?

> On Jul 11, 2016, at 9:41 AM, Poepping, Thomas wrote: > > Hi common-dev@, > > I’m finding I can’t assign my own Jira, > https://issues.apache.org/jira/browse/HADOOP-13344 to myself. > > Is there a list I need to be on to do that? Or can someone do it for me? Done.

Re: [DICUSS] Upgrading Guice to 4.0(HADOOP-12064)

> On Jun 29, 2016, at 10:16 AM, Tsuyoshi Ozawa wrote: > > No objections here? I talked to a handful of non-committer ISV-type folks yesterday and the general consensus was that there is an expectation that 3.x will have all the dependencies updated to something relatively

Re: [Release thread] 2.6.5 release activities

> On Aug 12, 2016, at 8:19 AM, Junping Du wrote: > > In this community, we are so aggressive to drop Java 7 support in 3.0.x > release. Here, why we are so conservative to keep releasing new bits to > support Java 6? I don't view a group of people putting bug

Re: [VOTE] Release Apache Hadoop 2.7.3 RC1

ome > exception cases. I think it still belongs to 2.7.3 scope. > Kuhu and Kihwal, any comments here? > > > Thanks, > > Junping > ____ > From: Allen Wittenauer <a...@effectivemachines.com> > Sent: Wednesday, Au

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha2 RC0

> On Jan 20, 2017, at 2:36 PM, Andrew Wang wrote: > > http://home.apache.org/~wang/3.0.0-alpha2-RC0/ There are quite a few JIRA issues that need release notes. - To unsubscribe, e-mail:

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha2 RC0

> On Jan 22, 2017, at 9:05 PM, Allen Wittenauer <a...@effectivemachines.com> > wrote: > > > > > >> On Jan 20, 2017, at 2:36 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: >> >> http://home.apache.org/~wang/3.0.0-alpha2-RC0/ > >

Re: [VOTE] Release cadence and EOL

> On Jan 21, 2017, at 7:08 PM, Karthik Kambatla wrote: > > 3. RM: some method to madness. Junping, for instance, is trying to roll > a release with 2300 patches. It is a huge time investment. (Thanks again, > Junping.) Smaller releases are easier to manage. A target

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha2 RC0

> On Jan 23, 2017, at 8:50 PM, Chris Douglas wrote: > > Thanks for all your work on this, Andrew. It's great to see the 3.x > series moving forward. > > If you were willing to modify the release notes and add the LICENSE to > the jar, we don't need to reset the clock

Re: [Continued] [Release thread] 2.8.0 release activities

If you ran mvn clean at any point in your repo between create-release and mvn deploy, you'll need to start at running create-release again. create-release leaves things in a state that mvn deploy should be ready to go, with no clean necessary. > On Jan 20, 2017, at 11:12 AM, Junping Du

Re: [VOTE] Release cadence and EOL

> On Jan 18, 2017, at 11:21 AM, Chris Trezzo wrote: > > Thanks Sangjin for pushing this forward! I have a few questions: These are great questions, because I know I'm not seeing a whole lot of substance in this vote. The way to EOL software in the open source

Re: [VOTE] Release Apache Hadoop 2.7.3 RC1

-1 HDFS-9395 is an incompatible change: a) Why is not marked as such in the changes file? b) Why is an incompatible change in a micro release, much less a minor? c) Where is the release note for this change? > On Aug 12, 2016, at 9:45 AM, Vinod Kumar Vavilapalli >

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha1 RC0

> On Sep 1, 2016, at 2:57 PM, Andrew Wang wrote: > > Steve requested a git hash for this release. This led us into a brief > discussion of our use of git tags, wherein we realized that although > release tags are immutable (start with "rel/"), RC tags are not. This is

[VOTE] Merge HADOOP-13341

I’d like to call for a vote to run for 5 days (ending Mon 12, 2016 at 7AM PT) to merge the HADOOP-13341 feature branch into trunk. This branch was developed exclusively by me. As usual with large shell script changes, it's been broken up into several smaller commits to make it easier

Re: [VOTE] Merge HADOOP-13341

> On Sep 8, 2016, at 2:50 AM, Steve Loughran wrote: > > I'm trying to do the review effort here even though I don't know detailed > bash, as I expect I don't know any less than others, and what better way to > learn than reviewing code written by people that do know

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha1 RC0

> On Aug 30, 2016, at 10:17 AM, Zhe Zhang wrote: > > Thanks Andrew for the great work! It's really exciting to finally see a > Hadoop 3 RC. > > I noticed CHANGES and RELEASENOTES markdown files which were not in > previous RCs like 2.7.3. What are good tools to verify them? I

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha1 RC0

> On Aug 30, 2016, at 2:20 PM, Eric Badger wrote: > > Well that's embarrassing. I had accidentally slightly renamed my > log4j.properties file in my conf directory, so it was there, just not being > read. Nah. You were just testing out the shell rewrite's

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha1 RC0

> On Aug 30, 2016, at 2:06 PM, Eric Badger > wrote: > > > WARNING: log4j.properties is not found. HADOOP_CONF_DIR may be incomplete. ^^ > > After running the above command, the RM UI showed a successful job, but as > you can

[DISCUSS] HADOOP-13341 Merge Request

Before requesting a merge vote, I'd like for folks to take a look at HADOOP-13341. This branch changes how the vast majority of the _OPTS variables work in various ways, making things easier for devs and users by helping to make the rules consistent. It also clarifies/cleans up how the _USER

Re: [VOTE] Merge HADOOP-13341

> On Sep 9, 2016, at 2:15 PM, Anu Engineer wrote: > > +1, Thanks for the effort. It brings in a world of consistency to the hadoop > vars; and as usual reading your bash code was very educative. Thanks! There's still a handful of HDFS and MAPRED

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

> On Sep 13, 2016, at 7:31 AM, Apache Jenkins Server > wrote: > > For more details, see > https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/163/ > > unit: > > > >

[RESULTS] Re: [VOTE] Merge HADOOP-13341

The vote passes with 3 +1 binding votes. I'll be merging this later today. Thanks everyone! > On Sep 7, 2016, at 6:44 AM, Allen Wittenauer <a...@effectivemachines.com> > wrote: > > > I’d like to call for a vote to run for 5 days (ending Mon 12, 2016 a

Re: HADOOP-13636 and io.bytes.per.checksum

> On Sep 24, 2016, at 4:24 AM, Steve Loughran wrote: > > > On 23 Sep 2016, at 18:55, Andrew Wang > > wrote: > > Have you git blamed to dig up the original JIRA conversation? I think that > deprecation predates

Re: [VOTE] Release Apache Hadoop 2.6.5 (RC1)

> On Oct 5, 2016, at 10:35 PM, Akira Ajisaka wrote: > Can we rename it? > > AFAIK, hadoop releases were built by hortonmu in 2014 and was renamed to > jenkins. That's not how that works. It's literally storing the id of the person who built the

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

> On Aug 26, 2016, at 7:55 AM, Apache Jenkins Server > wrote: > > >Failed CTEST tests : > > test_test_libhdfs_threaded_hdfs_static > test_test_libhdfs_zerocopy_hdfs_static Something here likely broke these tests: [Aug 24, 2016 7:47:52 AM]

Re: jdk 9 early access

> On Aug 28, 2016, at 4:27 AM, Steve Loughran wrote: > > who is bold enough to set up a no-emails-please jenkins build of Hadoop & > Java 9? We already know it won't work. (log4j) - To

Re: Upgrading Hadoop dependencies and catching potential incompatibilities for HBase

> On Sep 28, 2016, at 9:56 AM, Sean Mackrory wrote: > and > Bigtop's integration tests too. Anything else you would add to this? Be aware that bigtop does things to the jar layout that will break parts of hadoop 3.

Re: new look site

> On Sep 27, 2016, at 10:06 AM, Steve Loughran wrote: > > Things aren't laying out very well in the site now the new logo is in. > > https://hadoop.apache.org/docs/stable2/hadoop-project-dist/hadoop-common/FileSystemShell.html > > Is there anyone who understands CSS

Re: [DISCUSS] Pre-commit build in Windows platform

> On Oct 27, 2016, at 8:20 PM, Brahma Reddy Battula > wrote: > > As we supporting the Hadoop in windows, I feel, we should have pre-commit > build in windows( atleast in qbt). I actually tried to get Apache Yetus testing Apache Hadoop on the

Re: [DISCUSS] Commit log Pattern Unification

> On Nov 7, 2016, at 11:29 AM, Ravi Prakash wrote: > > I have a preference for d) Contributed by XXX. > > Wouldn't signed-off require the commit to come from the contributor? What > about people who submit patch files? If the patches are built with 'git

Re: [DISCUSS] Pre-commit build in Windows platform

> On Nov 1, 2016, at 4:00 AM, Brahma Reddy Battula > wrote: > Thanks for information. Seems to be challenge to get it done. Can we try to > get dedicated machine for this..? We have one. What we don't have is someone dedicated enough to keep it

Re: [RESULT] [VOTE] Release Apache Hadoop 2.8.0 (RC3)

Just a heads up. Looks like some removed the Finish Date off of 2.8.0 in JIRA. It needs to be put back to match what is in the artifacts that we voted on. - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For

Re: Can we update protobuf's version on trunk?

> On Mar 28, 2017, at 5:09 PM, Chris Douglas wrote: > > I haven't seen data identifying PB as a bottleneck, but the > non-x86/non-Linux and dev setup arguments may make this worthwhile. -C FWIW, we have the same problem with leveldbjni-all. (See the ASF

Review request for HADOOP-14202

Hey gang. Could I get a quick review of HADOOP-14202? This changes a few things: * Makes the rest of the _USER vars consistent with the other changes in trunk (e.g., HADOOP_SECURE_DN_USER becomes HDFS_DATANODE_SECURE_USER) * deprecation warnings as necessary *

Re: [VOTE] Release Apache Hadoop 2.8.0 (RC3)

> On Mar 21, 2017, at 10:12 AM, Andrew Wang wrote: > > I poked around a bit. The 3.0.0-alpha2 binary tarball is only 246M and has > more changes than 2.8.0. Not to disclaim any other potential issues, but it's worth noting 3.x de-dupes jar files as part of the

[DISCUSS] Changing the default class path for clients

This morning I had a bit of a shower thought: With the new shaded hadoop client in 3.0, is there any reason the default classpath should remain the full blown jar list? e.g., shouldn’t ‘hadoop classpath’ just return configuration, user supplied bits (e.g.,

Re: [DISCUSS] Changing the default class path for clients

ng <andrew.w...@cloudera.com> wrote: > What's the current contract for `hadoop classpath`? Would it be safer to > introduce `hadoop userclasspath` or similar for this behavior? > > I'm betting that changing `hadoop classpath` will lead to some breakages, > so I'd prefer to make t

Re: Hadoop QA fails with "Docker failed to build yetus/hadoop:a9ad5d6"

> On Apr 13, 2017, at 11:13 PM, Arun Suresh wrote: > > Yup, > > YARN Pre-Commit tests are having the same problem as well. > Is there anything that can be done to fix this ? Ping Yetus folks (Allen / > Sean) https://issues.apache.org/jira/browse/HADOOP-14311

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

Looks like someone reset HEAD back to Mar 31. Sent from my iPad > On Apr 16, 2017, at 12:08 AM, Apache Jenkins Server > wrote: > > For more details, see > https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/378/ > > > > > > -1 overall > > > The

Re: HADOOP-14316: Switching from Findbugs to Spotbugs

> On Apr 19, 2017, at 10:52 AM, Wei-Chiu Chuang wrote: > That sounds scary. Would you mind to share the list of bugs that spotbugs > found? Sounds like some of them may warrant new blockers jiras for Hadoop 3. I've added the list to the JIRA.

HADOOP-14316: Switching from Findbugs to Spotbugs

Hey gang. HADOOP-14316 enables the spotbugs back-end for the findbugs front-end. Spotbugs (https://spotbugs.github.io/) is the fork of findbugs that the community and some of the major contributors have made to move findbugs forward. It is geared towards JDK8 and JDK9.

Re: H9 build slave is bad

> On Mar 9, 2017, at 2:15 PM, Andrew Wang wrote: > > H9 is again eating our builds. > H0: https://builds.apache.org/job/PreCommit-HDFS-Build/18652/console H6: https://builds.apache.org/job/PreCommit-HDFS-Build/18646/console

Re: H9 build slave is bad

> On Mar 8, 2017, at 9:34 AM, Sean Busbey wrote: > > Is this HADOOP-13951? Almost certainly. Here's the run that broke it again: https://builds.apache.org/job/PreCommit-HDFS-Build/18591 Likely something in the HDFS-7240 branch or with this patch that's

Re: H9 build slave is bad

> On Mar 8, 2017, at 12:04 PM, Allen Wittenauer <a...@effectivemachines.com> > wrote: > > >> On Mar 8, 2017, at 9:34 AM, Sean Busbey <bus...@cloudera.com> wrote: >> >> Is this HADOOP-13951? > > Almost certainly. Here's the run that br

<    1   2   3   4   5   6   7   8   9   10   >