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, CHANGES.txt > and release note

Re: Looking to a Hadoop 3 release

e 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 wrote: > >&g

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: Jenkins stability and patching

On Mon, Nov 23, 2015 at 1:53 PM, Colin P. McCabe 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. Right now, we > pre

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. Hav

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 betwee

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 wrote: > TL;DR: > > Heads up: I’m going to hack on these scripts to fix the race > conditions. > > > > Pre

Re: [RESULT][VOTE] Release Apache Hadoop 2.7.0 RC0

Sorry for the late reply. It seems like the consensus is that we should push these fixes to 2.7.1. That works for me. HADOOP-11802 should be in there soon, hopefully the rest will follow quickly. best, Colin On Wed, Apr 22, 2015 at 4:27 PM, Vinod Kumar Vavilapalli wrote: > It took a while for

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 wrote: > I took the liberty of adding line breaks to Joep's mail. > > Thanks for the great feedback Joep. The goal with 3.x is to maintain A

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

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

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 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 &

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 wh

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 e

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 pl

Re: 2.7 status

On Wed, Feb 18, 2015 at 1:49 AM, Steve Loughran wrote: > > > > On 17 February 2015 at 21:52:47, Colin McCabe > (cmcc...@alumni.cmu.edu) wrote: > > Re: building Windows binaries. Do we release binaries for all the > Linux and UNIX architectures? I thought we didn't.