Return-Path: X-Original-To: apmail-hadoop-common-dev-archive@www.apache.org Delivered-To: apmail-hadoop-common-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id ACE1018CA7 for ; Thu, 18 Feb 2016 23:04:49 +0000 (UTC) Received: (qmail 23326 invoked by uid 500); 18 Feb 2016 23:04:42 -0000 Delivered-To: apmail-hadoop-common-dev-archive@hadoop.apache.org Received: (qmail 23243 invoked by uid 500); 18 Feb 2016 23:04:42 -0000 Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-dev@hadoop.apache.org Delivered-To: mailing list common-dev@hadoop.apache.org Received: (qmail 23214 invoked by uid 99); 18 Feb 2016 23:04:41 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Feb 2016 23:04:41 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 21407C111B for ; Thu, 18 Feb 2016 23:04:41 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.979 X-Spam-Level: * X-Spam-Status: No, score=1.979 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=cloudera-com.20150623.gappssmtp.com Received: from mx2-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id GuPmy4VVYmMH for ; Thu, 18 Feb 2016 23:04:39 +0000 (UTC) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) by mx2-lw-us.apache.org (ASF Mail Server at mx2-lw-us.apache.org) with ESMTPS id 6DDF45F1E9 for ; Thu, 18 Feb 2016 23:04:39 +0000 (UTC) Received: by mail-yw0-f179.google.com with SMTP id g127so53996864ywf.2 for ; Thu, 18 Feb 2016 15:04:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudera-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Jm+k7Jgx1HP99LpC0dOjrPyklgTsevvZexlSPzByigk=; b=OPEwfFisfNVYgmc1Homy8v/a4rU65KPxWKpe/tFTzpuz2SiTZea7zTWwaT8tO2iHR7 /Dwdx7p/7S4YjhQDFajIzJLNY9ds9bT4YiYf4aqLk4/4SEQ9BC6P3JxcqaIWNA/JDTa1 ElZKgp15cKHJevja2+a08cc+jFFiZkky2/DUcBrouogJJuknNWiHf5m8t1SrpZ8IQ+VB ZTaxfOopAHc6wFPhUGw72cNdc8k6dy/N4MUVzEqfJjlSSScsP17180fR8g/KwdiVnQhJ Gz8Msyed2zrYf1tuzRBkz7ZhGriD5hHRR1KCR9E7eA1H95rugqDgY9dPg/usb4WIwljd r4tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Jm+k7Jgx1HP99LpC0dOjrPyklgTsevvZexlSPzByigk=; b=DkffridFSNr6BGjSiM6fjrUPhjj+C6GgDFtv8PkbsTWAK7Uwl8Zfsvmi6hXASfAF4R q/KF+95RK0FWzOHku2gVKEdaLugNYjTLvtb2qRqVRBolVBPHZ2GGaMRdgNFgA93kccZx SPquWnvWV/2KHAIRS7o6Kbn3cxjddZo3bqSGx+pOEBkuntjvfULXvvCY4jfAdWtMk/qO 24LNsqEeXa3mxsLx5QIFiuStA4XIVYKqX+z3xb3wywKJbgwU8hJKhIiFYZYrvzh4FDQg lbpmKk7NnAstGnauwX58sFx/APOCLiUQxTFQ9vJJzApnEp+T2HFemPzt4+bwevRennpu OtnQ== X-Gm-Message-State: AG10YOQwruy47FbKuhTs+mJ9VocRMBNfFHdOGM/d+2IC6rFdRdnEpxlM4F/w4BbYFTK4aYXG4+jFvXs8lT59uW4W X-Received: by 10.13.204.77 with SMTP id o74mr5907909ywd.338.1455836673013; Thu, 18 Feb 2016 15:04:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.234.82 with HTTP; Thu, 18 Feb 2016 15:04:13 -0800 (PST) In-Reply-To: <1730597427.5140749.1455835803311.JavaMail.yahoo@mail.yahoo.com> References: <1425349807827.88706@hortonworks.com> <1425421960667.60647@hortonworks.com> <3D693482-E140-488A-8F3C-D28650294486@gmail.com> <1730597427.5140749.1455835803311.JavaMail.yahoo@mail.yahoo.com> From: Andrew Wang Date: Thu, 18 Feb 2016 15:04:13 -0800 Message-ID: Subject: Re: Looking to a Hadoop 3 release To: "hdfs-dev@hadoop.apache.org" , Kihwal Lee Cc: "mapreduce-dev@hadoop.apache.org" , "common-dev@hadoop.apache.org" , "yarn-dev@hadoop.apache.org" Content-Type: multipart/alternative; boundary=001a114f27eabf43ca052c136307 --001a114f27eabf43ca052c136307 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Kihwal, I think there's still value in continuing the 2.x releases. 3.x comes with the incompatible bump to a JDK8 runtime, and also the fact that 3.x won't be beta or GA for some number of months. In the meanwhile, it'd be good to keep putting out regular, stable 2.x releases. Best, Andrew On Thu, Feb 18, 2016 at 2:50 PM, Kihwal Lee wrote: > Moving Hadoop 3 forward sounds fine. If EC is one of the main motivations= , > are we getting rid of branch-2.8? > > Kihwal > > From: Andrew Wang > To: "common-dev@hadoop.apache.org" > Cc: "yarn-dev@hadoop.apache.org" ; " > mapreduce-dev@hadoop.apache.org" ; > hdfs-dev > Sent: Thursday, February 18, 2016 4:35 PM > Subject: Re: Looking to a Hadoop 3 release > > Hi all, > > Reviving this thread. I've seen renewed interest in a trunk release since > HDFS erasure coding has not yet made it to branch-2. Along with JDK8, the > shell script rewrite, and many other improvements, I think it's time to > revisit Hadoop 3.0 release plans. > > My overall plan is still the same as in my original email: a series of > regular alpha releases leading up to beta and GA. Alpha releases make it > easier for downstreams to integrate with our code, and making them regula= r > means features can be included when they are ready. > > I know there are some incompatible changes waiting in the wings > (i.e. HDFS-6984 making FileStatus a PB rather than Writable, some of > HADOOP-9991 bumping dependency versions) that would be good to get in. If > you have changes like this, please set the target version to 3.0.0 and ma= rk > them "Incompatible". We can use this JIRA query to track: > > > https://issues.apache.org/jira/issues/?jql=3Dproject%20in%20(HADOOP%2C%20= HDFS%2C%20YARN%2C%20MAPREDUCE)%20and%20%22Target%20Version%2Fs%22%20%3D%20%= 223.0.0%22%20and%20resolution%3D%22unresolved%22%20and%20%22Hadoop%20Flags%= 22%3D%22Incompatible%20change%22%20order%20by%20priority > > There's some release-related stuff that needs to be sorted out (namely, t= he > new CHANGES.txt and release note generation from Yetus), but I'd > tentatively like to roll the first alpha a month out, so third week of > March. > > Best, > Andrew > > On Mon, Mar 9, 2015 at 7:23 PM, Raymie Stata wrote= : > > > Avoiding the use of JDK8 language features (and, presumably, APIs) > > means you've abandoned #1, i.e., you haven't (really) bumped the JDK > > source version to JDK8. > > > > Also, note that releasing from trunk is a way of achieving #3, it's > > not a way of abandoning it. > > > > > > > > On Mon, Mar 9, 2015 at 7:10 PM, Andrew Wang > > wrote: > > > Hi Raymie, > > > > > > Konst proposed just releasing off of trunk rather than cutting a > > branch-2, > > > and there was general agreement there. So, consider #3 abandoned. 1&2 > can > > > be achieved at the same time, we just need to avoid using JDK8 langua= ge > > > features in trunk so things can be backported. > > > > > > Best, > > > Andrew > > > > > > On Mon, Mar 9, 2015 at 7:01 PM, Raymie Stata > > wrote: > > > > > >> In this (and the related threads), I see the following three > > requirements: > > >> > > >> 1. "Bump the source JDK version to JDK8" (ie, drop JDK7 support). > > >> > > >> 2. "We'll still be releasing 2.x releases for a while, with similar > > >> feature sets as 3.x." > > >> > > >> 3. Avoid the "risk of split-brain behavior" by "minimize backporting > > >> headaches. Pulling trunk > branch-2 > branch-2.x is already tedious. > > >> Adding a branch-3, branch-3.x would be obnoxious." > > >> > > >> These three cannot be achieved at the same time. Which do we abando= n? > > >> > > >> > > >> On Mon, Mar 9, 2015 at 12:45 PM, sanjay Radia > > >> wrote: > > >> > > > >> >> On Mar 5, 2015, at 3:21 PM, Siddharth Seth > wrote: > > >> >> > > >> >> 2) Simplification of configs - potentially separating client side > > >> configs > > >> >> and those used by daemons. This is another source of perpetual > > confusion > > >> >> for users. > > >> > + 1 on this. > > >> > > > >> > sanjay > > >> > > > > > --001a114f27eabf43ca052c136307--