Re: Erratic Jenkins behavior

, Colin P. McCabe (cmcc...@apache.orgmailto:cmcc...@apache.org) wrote: I'm sorry, I don't have any insight into this. With regard to HADOOP-11084, I thought that $BUILD_URL would be unique for each concurrent build, which would prevent build artifacts from getting mixed up between jobs. Based

Re: Erratic Jenkins behavior

Hortonworks http://hortonworks.com/ On 2/12/15, 2:00 PM, Colin P. McCabe cmcc...@apache.org wrote: We could potentially use different .m2 directories for each executor. I think this has been brought up in the past as well. I'm not sure how maven handles concurrent access to the .m2

Re: Erratic Jenkins behavior

I'm sorry, I don't have any insight into this. With regard to HADOOP-11084, I thought that $BUILD_URL would be unique for each concurrent build, which would prevent build artifacts from getting mixed up between jobs. Based on the value of PATCHPROCESS that Kihwal posted, perhaps this is not the

Re: Hadoop - Major releases

Thanks, Andrew and Joep. +1 for maintaining wire and API compatibility, but moving to JDK8 in 3.0 best, Colin On Mon, Mar 16, 2015 at 3:22 PM, Andrew Wang andrew.w...@cloudera.com wrote: I took the liberty of adding line breaks to Joep's mail. Thanks for the great feedback Joep. The goal

Re: Hadoop 3.x: what about shipping trunk as a 2.x release in 2015?

Java 7 will be end-of-lifed in April 2015. I think it would be unwise to plan a new Hadoop release against a version of Java that is almost obsolete and (soon) no longer receiving security updates. I think people will be willing to roll out a new version of Java for Hadoop 3.x. Similarly, the

Re: Hadoop 3.x: what about shipping trunk as a 2.x release in 2015?

on hadoop-3.x right? So, I don't see the difference? Arun From: Colin P. McCabe cmcc...@apache.org Sent: Monday, March 09, 2015 3:05 PM To: hdfs-...@hadoop.apache.org Cc: mapreduce-...@hadoop.apache.org; common-...@hadoop.apache.org; yarn-dev

Re: Hadoop 3.x: what about shipping trunk as a 2.x release in 2015?

Er, that should read as Allen commented C. On Tue, Mar 10, 2015 at 11:55 AM, Colin P. McCabe cmcc...@apache.org wrote: Hi Arun, Not all changes which are incompatible can be fixed-- sometimes an incompatibility is a necessary part of a change. For example, taking a really old library

Re: TimSort bug and its workaround

Thanks for bringing this up. If you can find any place where an array might realistically be larger than 67 million elements, then I guess file a JIRA for it. Also this array needs to be of objects, not of primitives (quicksort is used for those in jdk7, apparently). I can't think of any such

Re: DISCUSSION: Patch commit criteria.

I agree with Andrew and Konst here. I don't think the language is unclear in the rule, either... consensus with a minimum of one +1 clearly indicates that _other people_ are involved, not just one person. I would also mention that we created the branch committer role specifically to make it

Re: Jenkins precommit-*-build

Thanks, Allen. This has long been a thorn in our side, and it's really good to see someone work on it. cheers, Colin On Tue, May 5, 2015 at 2:59 PM, Allen Wittenauer a...@altiscale.com wrote: TL;DR: Heads up: I’m going to hack on these scripts to fix the race conditions.

Re: [VOTE] Release Apache Hadoop 2.7.0 RC0

I would like to fix HDFS-8070, which just came to light. The impact is that if this isn't fixed, 2.6 clients will be unable to do short-circuit reads against 2.7 datanodes. best, Colin On Wed, Apr 15, 2015 at 8:19 PM, Brahma Reddy Battula brahmareddy.batt...@huawei.com wrote: Need Jcardar

Re: [VOTE] Release Apache Hadoop 2.7.0 RC0

, at 2:27 AM, Colin P. McCabe cmcc...@apache.org wrote: I would like to fix HDFS-8070, which just came to light. The impact is that if this isn't fixed, 2.6 clients will be unable to do short-circuit reads against 2.7 datanodes. best, Colin On Wed, Apr 15, 2015 at 8:19 PM, Brahma Reddy

Re: Java 8 + Jersey updates

Looks like a good idea. I assume you are targetting this only at trunk / 3.0 based on the "target version" and the incompatibility discussion? best, Colin On Mon, Oct 26, 2015 at 7:07 AM, Tsuyoshi Ozawa wrote: > Hi Steve, > > Thanks for your help. > > > 2. it's "significant"

Re: [DISCUSS] Looking to a 2.8.0 release

I think it makes sense to have a 2.8 release since there are a tremendous number of JIRAs in 2.8 that are not in 2.7. Doing a 3.x release seems like something we should consider separately since it would not have the same compatibility guarantees as a 2.8 release. There's a pretty big delta

Re: Jenkins stability and patching

I agree that our tests are in a bad state. It would help if we could maintain a list of "flaky tests" somewhere in git and have Yetus consider the flakiness of a test before -1ing a patch. Right now, we pretty much all have that list in our heads, and we're not applying it very consistently.

Re: Jenkins stability and patching

On Mon, Nov 23, 2015 at 1:53 PM, Colin P. McCabe <cmcc...@apache.org> wrote: > I agree that our tests are in a bad state. It would help if we could > maintain a list of "flaky tests" somewhere in git and have Yetus > consider the flakiness of a test before -1ing a patch

Re: node.js and more as dependencies

Hmm. Devil's advocate here: Do we really need to have a "JS build"? The main use-cases for "JS builds" seem to be if you want to minimize or obfuscate your JS. Given that this is open source code, obfuscation seems unnecessary. Given that it's a low-traffic management interface, minimizing the

Re: Looking to a Hadoop 3 release

ther / when it can be released in 2.9. I think we > should rather concentrate our EC dev efforts to harden key features under > the follow-on umbrella HDFS-8031 and make it solid for a 3.0 release. > > Sincerely, > Zhe > > On Mon, Feb 22, 2016 at 9:25 AM Colin P. McCabe <c

Re: Looking to a Hadoop 3 release

+1 for a release of 3.0. There are a lot of significant, compatibility-breaking, but necessary changes in this release... we've touched on some of them in this thread. +1 for a parallel release of 2.8 as well. I think we are pretty close to this, barring a dozen or so blockers. best, Colin On

Re: CHANGES.txt is gone from trunk, branch-2, branch-2.8

+1 Thanks, Andrew. This will avoid so many spurious conflicts when cherry-picking changes, and so much wasted time on commit. best, Colin On Thu, Mar 3, 2016 at 9:11 PM, Andrew Wang wrote: > Hi all, > > With the inclusion of HADOOP-12651 going back to branch-2.8,

Re: node.js and more as dependencies

Just like Java code of >> Hadoop, no user will try to get source code from a running cluster :). >> >> I will make sure integration to Maven is as less as possible, we should >> only need one single sub module, and limit all changes in that module only. >>