Re: Looking to a Hadoop 3 release

A heads up that I think we're getting close on the blockers for the first alpha. Looking at my list, I see two I'd like to get in still: YARN-5270 and HADOOP-13316. Will cut a branch and roll the release once those go in; my test builds have looked good thus far. My original plan was to do alphas

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

I think it's okay to merge. We've already bumped other deps in trunk. On Wed, Jun 29, 2016 at 12:27 PM, Tsuyoshi Ozawa wrote: > I forgot to mention about importance point: it's a blocker issue to > compile Hadoop with JDK8. Hence, we need to merge it on both client > side and server slide anyway

Heads up: branched branch-3.0.0-alpha1

Hi all, You might have already noticed from the bulk JIRA updates, but I've branched branch-3.0.0-alpha1 off trunk, and updated trunk to be 3.0.0-alpha2. For most changes, you can just commit to trunk and the branch-2s. Just remember to use the new 3.0.0-alpha2 version where appropriate. I still

Setting JIRA fix versions for 3.0.0 releases

Hi all, Since we're planning to spin releases off of both branch-2 and trunk, the changelog for 3.0.0-alpha1 based on JIRA information isn't accurate. This is because historically, we've only set 2.x fix versions, and 2.8.0 and 2.9.0 and etc have not been released. So there's a whole bunch of chan

Re: Setting JIRA fix versions for 3.0.0 releases

t; 3.0.0-alpha1 right behind 2.8.0? > > That simplifies most of this confusion, we can avoid splitting the > bandwidth from the community on fixing blockers / vetting these concurrent > releases. Waiting a little more for 3.0.0 alpha to avoid most of this is > worth it, IMO. &

Re: Setting JIRA fix versions for 3.0.0 releases

Thanks for the input Vinod, inline: > Similarly the list of features we are enabling in this alpha would be good > - may be update the Roadmap wiki. Things like classpath-isolation which > were part of the original 3.x roadmap are still not done. > > I already updated the website release notes at

Re: Setting JIRA fix versions for 3.0.0 releases

> > >> I am also not quite sure I understand the rationale of what's in the > HowToCommit wiki. Assuming the semantic versioning (http://semver.org) as > our baseline thinking, having concurrent release streams alone breaks the > principle. And that is *regardless of* how we line up individual rele

Re: Setting JIRA fix versions for 3.0.0 releases

Thanks for the input Allen, good perspective as always, inline: > 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 reada

Re: Setting JIRA fix versions for 3.0.0 releases

. I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should be a very similar process. Best, Andrew On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer wrote: > > > On Jul 22, 2016, at 7:16 PM, Andrew Wang > wrote: > > > > Does this mean you find our curre

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

I got asked this off-list, so as a reminder, only PMC votes are binding on releases. Everyone is encouraged to vote on releases though! +1 (binding) * Downloaded source, built * Started up HDFS and YARN * Ran Pi job which as usual returned 4, and a little teragen On Mon, Jul 25, 2016 at 11:08 AM

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

n. I feel there must be a more developer-friendly solution here. * If you start the NodeManager and not the RM, the NM has a handler for SIGTERM and SIGINT that blocked my Ctrl-C and kill attempts during startup. I had to kill -9 it. On Mon, Jul 25, 2016 at 11:44 AM, Andrew Wang wrote: > I got a

Re: Setting JIRA fix versions for 3.0.0 releases

oing two releases (2.7.3 / 2.8.0). > > Thanks, > Wangda > > On Mon, Jul 25, 2016 at 11:02 AM, Andrew Wang > wrote: > >> If I don't hear otherwise, I'd like to go ahead and do the bulk fix >> version >> update on JIRA for 3.0.0-alpha1, diffing from 2.7

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Thanks Vinod for forking the thread. Let me try and summarize what Allen and I talked about in the previous thread. Currently, we've been marking JIRAs with fix versions of both 2.6.x and 2.7.x. IIUC, the chronological ordering between these two lines is actually not important. If you're on 2.6.1,

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

On Tue, Jul 26, 2016 at 1:23 PM, Karthik Kambatla wrote: > IIRR, the vote is on source artifacts and binaries are for convenience. > > Let me refine this statement a bit. Both the binary tarball and the JARs we publish to Maven are still official release artifacts. This is why we need L&Ns for th

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Thanks for replies Akira and Tsuyoshi, inline: Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we > need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we > don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira. > Is it right? Yes, cor

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

s. It helps users, not devs > basically, to decide which version users will use: e.g. if > 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses > 2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes > against 2.7.3. Please let me know if I have some missing

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> > The -alphaX versions we're using leading up to 3.0.0 GA can be treated as >> a.b.c versions, with alpha1 being the a.b.0 release. >> > > Once 3.0.0 GA goes out, a user would want to see the diff from the latest > 2.x.0 release (say 2.9.0). > > Are you suggesting 3.0.0 GA would have c = 5 (say)

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Hi Junping, thanks for sharing your thoughts, inline, On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 wrote: > Thanks Vinod for bringing up this topic for discussion. I share the same > concern here from my previous experience and I doubt some simple rules > proposed below could make life easier. > > > The

Re: Heads up: branched branch-3.0.0-alpha1

I'll send another email when this happens. On Fri, Jul 15, 2016 at 7:26 PM, Andrew Wang wrote: > Hi all, > > You might have already noticed from the bulk JIRA updates, but I've > branched branch-3.0.0-alpha1 off trunk, and updated trunk to be > 3.0.0-alpha2. For most c

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I've written up the proposal from my initial reply in a GDoc. I found one bug in the rules when working through my example again, and also incorporated Akira's correction. Thanks all for the discussion so far! https://docs.google.com/document/d/1vlDtpsnSjBPIZiWQjSwgnV0_Z6ZQJ1r91J8G0FduyTg/edit Pi

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

x27;m going to be on vacation until the 15th, but will tackle this when I get back. The bulk updates will also be floowed with a wide-distribution email reminder about how to appropriately set fix versions. Best, Andrew On Thu, Jul 28, 2016 at 4:46 PM, Andrew Wang wrote: > I've written up

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Hi Konst, thanks for commenting, On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko wrote: > 1. I probably missed something but I didn't get it how "alpha"s made their > way into release numbers again. This was discussed on several occasions and > I thought the common perception was to use jus

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

On Thu, Aug 4, 2016 at 12:41 PM, Chris Douglas wrote: > I agree with Konst. The virtues of branching (instead of releasing > from trunk) and using the version suffix for the 3.x releases are lost > on me. Both introduce opportunities for error, in commits, in > consistent JIRA tagging, in packagi

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

Could a YARN person please comment on these two issues, one of which Vinay also hit? If someone already triaged or filed JIRAs, I missed it. On Mon, Jul 25, 2016 at 11:52 AM, Andrew Wang wrote: > I'll also add that, as a YARN newbie, I did hit two usability issues. > These are very

Re: Setting JIRA fix versions for 3.0.0 releases

Sean gave me some pointers on using Java ACC, I've made a report using the script I've been working on at YETUS-445: http://home.apache.org/~wang/h3/report.html Invocation was something like this: -> % ~/dev/yetus/check-java-compatibility/checkjavacompatibility.py --annotation org.apache.hadoop.

Re: Setting JIRA fix versions for 3.0.0 releases

r 3.0.0-alpha1 and the corresponding fix version updates. On Thu, Aug 25, 2016 at 11:44 AM, Andrew Wang wrote: > Sean gave me some pointers on using Java ACC, I've made a report using the > script I've been working on at YETUS-445: > > http://home.apache.org/~wang/h3/report.htm

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

. > > Jason > > > ------ > *From:* Andrew Wang > *To:* Karthik Kambatla > *Cc:* larry mccay ; Vinod Kumar Vavilapalli < > vino...@apache.org>; "common-...@hadoop.apache.org" < > common-...@hadoop.apache.org>; &quo

Turning off JIRA notifications temporarily at ~6PM PDT for bulk JIRA fix version update

Hi folks, I'm planning to pull the trigger on a bulk JIRA update to add the 3.0.0-alpha1 fix version to a bunch of JIRAs, based on the versioning scheme put forth in a previous set of common-dev emails [1]. Vinod asked me to hold off on the 2.8.0 update, I think he'll run it separately. I've talk

Re: Turning off JIRA notifications temporarily at ~6PM PDT for bulk JIRA fix version update

Starting this now, wish me luck... On Mon, Aug 29, 2016 at 2:18 PM, Andrew Wang wrote: > Hi folks, > > I'm planning to pull the trigger on a bulk JIRA update to add the > 3.0.0-alpha1 fix version to a bunch of JIRAs, based on the versioning > scheme put forth in a previo

Re: Turning off JIRA notifications temporarily at ~6PM PDT for bulk JIRA fix version update

Script has finished, JIRA notifications should be back on. If you notice any strangeness, let me know. I'll send a separate email blast reminding people about branches and fix versions. On Mon, Aug 29, 2016 at 5:56 PM, Andrew Wang wrote: > Starting this now, wish me luck... > >

[REMINDER] How to set fix versions when committing

Hi all, I finished the bulk fix version update and just rebranched branch-3.0.0-alpha1 off of trunk. So, a reminder that the procedure for setting fix versions has changed slightly from before. Everything is fully detailed here, the example in particular should help clarify things: https://hadoo

[VOTE] Release Apache Hadoop 3.0.0-alpha1 RC0

Hi all, Thanks to the combined work of many, many contributors, here's an RC0 for 3.0.0-alpha1: http://home.apache.org/~wang/3.0.0-alpha1-RC0/ alpha1 is the first in a series of planned alpha releases leading up to GA. The objective is to get an artifact out to downstreams for testing and to ite

Re: [REMINDER] How to set fix versions when committing

Hi Junping, On Tue, Aug 30, 2016 at 4:30 AM, Junping Du wrote: > Hi Andrew and all, > Thanks for the notice on the change. I still concern this rule change > may cause some confusion from conflicting against our previous rule - no > need to set trunk version if it is landing on 2.x branch.

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

ll cluster and test simple programs, focusing on EC > functionalities > > -- Zhe > > On Tue, Aug 30, 2016 at 8:51 AM Andrew Wang > wrote: > >> Hi all, >> >> Thanks to the combined work of many, many contributors, here's an RC0 for >> 3.0.0-alpha1:

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

Hi Eric, thanks for trying this out, I tried this gpg command to get my key, seemed to work: # gpg --keyserver pgp.mit.edu --recv-keys 7501105C gpg: requesting key 7501105C from hkp server pgp.mit.edu gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key 7501105C: public key "Andrew Wang

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

ase-3.0.0-alpha1-RC0 tagger Andrew Wang 1472541776 -0700 Release candidate - 3.0.0-alpha1-RC0 gpg: Signature made Tue 30 Aug 2016 12:22:56 AM PDT using RSA key ID 7501105C gpg: Good signature from "Andrew Wang (CODE SIGNING KEY) < andrew.w...@cloudera.com>" gpg: aka &q

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

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

-node, non-secure cluster >> - Ran sleep jobs >> - Ensured preemption works as expected >> >> -Eric Payne >> >> >> - Original Message - >> From: Andrew Wang >> To: "common-...@hadoop.apache.org" ; " >> hdfs-...@hado

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

I don't think it's a blocker, though I wonder what the point of that date and attribution are on the WebUI. Maybe file a follow-on JIRA to remove it for the future? On Thu, Oct 6, 2016 at 3:09 PM, Sangjin Lee wrote: > I looked into building it on jenkins earlier, but it appears that this > jenk

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

Thanks to Chris and Sangjin for working on this release. +1 binding * Verified signatures * Built from source tarball * Started HDFS and did some basic ops Thanks, Andrew On Fri, Oct 7, 2016 at 2:50 PM, Wangda Tan wrote: > Thanks Sangjin for cutting this release! > > +1 (Binding) > > - Downlo

Planning for 3.0.0-alpha2

Hi folks, It's been a month since 3.0.0-alpha1, and we've been incorporating fixes based on downstream feedback. Thus, it's getting to be time for 3.0.0-alpha2. I'm using this JIRA query to track open issues: https://issues.apache.org/jira/issues/?jql=project%20in%20(HADOOP%2C%20HDFS%2C%20MAPREDU

Re: [DISCUSS] HADOOP-13603 - Remove package line length checkstyle rule

I don't think anything has really changed since we had this discussion in 2015 [1]. Github and gerrit and IDEs existed then too, and we decided to leave it at 80 characters due to split screens and readability. I personally still like 80 chars for these same reasons. [1] https://lists.apache.org/

Re: [DISCUSS] HADOOP-13603 - Remove package line length checkstyle rule

gt; change the rule, we need to discuss again. > > Regards, > Akira > > > On 10/21/16 07:12, Andrew Wang wrote: > >> I don't think anything has really changed since we had this discussion in >> 2015 [1]. Github and gerrit and IDEs existed then too, and we de

Re: [DISCUSS] Release cadence and EOL

Thanks for pushing on this Sangjin. The proposal sounds reasonable. However, for it to have teeth, we need to be *very* disciplined about the release cadence. Looking at our release history, we've done 4 maintenance releases in 2016 and no minor releases. 2015 had 4 maintenance and 1 minor release

Re: [DISCUSS] Release cadence and EOL

e cadence which is still within the realm of the > possible. > > The EOL policy can also be a bit of a forcing function. By having a > defined EOL, hopefully it would prod the community to move faster with > releases. Of course, automating releases and testing should help. > >

Hadoop 3 status wiki page

Hi folks, I've put together a cwiki page as a go-to place for Hadoop 3 release tracking: https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+3.0.0+release It links to a JIRA dashboard for open issues and a nightly JACC run I setup. I've also been writing periodic status updates, so we can

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

I recommend giving the JACC report another look. I set up a parameterized jenkins job which you can trigger manually for branch-2.8: https://builds.apache.org/view/H-L/view/Hadoop/job/Hadoop-trunk-JACC/ On Wed, Nov 30, 2016 at 4:06 PM, Junping Du wrote: > Hi Sangjin and all, > > That sound

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

create a similar > job: https://builds.apache.org/view/H-L/view/Hadoop/job/Hadoop-2.8-JACC/ > for 2.8 and kick off several runs manually. Will monitor > incompatible status from there. > > > Thanks, > > > Junping > > > ------ > *From:* Andrew

Re: Planning for 3.0.0-alpha2

be an alpha3 before we freeze for beta1. I've updated the Hadoop 3 wiki page [1] to reflect this. Thanks, Andrew [1]: https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+3.0.0+release On Mon, Oct 17, 2016 at 1:57 PM, Andrew Wang wrote: > Hi folks, > > It's been

Re: [VOTE] Release cadence and EOL

I don't think the motivation here is vendor play or taking away power from committers. Having a regular release cadence helps our users understand when a feature will ship so they can plan their upgrades. Having an EOL policy and a minimum support period helps users choose a release line, and under

Re: Planning for 3.0.0-alpha2

Heads up that I'm branching for 3.0.0-alpha2 and moving out targets versions. We're waiting on one last blocker which is in final stages of review. Best, Andrew On Wed, Jan 4, 2017 at 11:15 AM, Andrew Wang wrote: > Hi folks, > > Thanks to the hard work of many contributors,

Re: Planning for 3.0.0-alpha2

ndrew Wang wrote: > Heads up that I'm branching for 3.0.0-alpha2 and moving out targets > versions. We're waiting on one last blocker which is in final stages of > review. > > Best, > Andrew > > On Wed, Jan 4, 2017 at 11:15 AM, Andrew Wang > wrote: > >&

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

ect: Re: [Continued] [Release thread] 2.8.0 release activities > > Thanks Junping and Andrew! > > HADOOP-2.8-JACC is not working well, so I manually kicked a job to > compare 2.8 with 2.7.3. > > https://builds.apache.org/view/H-L/view/Hadoop/job/ > Hadoop-trunk-JACC/24/artifa

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

eploy in root directory before close the staging > repository. If this is the only suspect, I can drop the repository and do > mvn deploy again. > > > Thanks, > > > Junping > ------ > *From:* Andrew Wang > *Sent:* Friday, January 20, 2017 1

[VOTE] Release Apache Hadoop 3.0.0-alpha2 RC0

Hi all, With heartfelt thanks to many contributors, the RC0 for 3.0.0-alpha2 is ready. 3.0.0-alpha2 is the second alpha in the planned 3.0.0 release line leading up to a 3.0.0 GA. It comprises 857 fixes, improvements, and new features since alpha1 was released on September 3rd, 2016. More inform

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

After some googling, I discovered we need the sign profile to make deploy work: mvn deploy -Psign -DskipTests -DskipShading Updated HowToRelease accordingly. On Fri, Jan 20, 2017 at 11:15 AM, Andrew Wang wrote: > What I meant is that you can mvn deploy the specific missing files to fix &

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

L commands > > - KMS and HttpFS tests > > - MapReduce wordcount example > - balancer start/stop > > > John Zhuge > Software Engineer, Cloudera > > On Fri, Jan 20, 2017 at 2:36 PM, Andrew Wang > wrote: > >> Hi all, >> >> With heartfelt thank

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

wrote: > > > On Jan 22, 2017, at 9:05 PM, Allen Wittenauer > wrote: > > > > > > > > > > > >> On Jan 20, 2017, at 2:36 PM, Andrew Wang > wrote: > >> > >> http://home.apache.org/~wang/3.0.0-alpha2-RC0/ > > > >

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

rce, stood up a pseudo-distributed cluster > with FairScheduler, ran example jobs, and played around with the UI. > > Thanks > Karthik > > > On Fri, Jan 20, 2017 at 2:36 PM, Andrew Wang > wrote: > >> Hi all, >> >> With heartfelt thanks to many contributo

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

open to changes to RN and License. >> >> On Wed, Jan 25, 2017 at 11:59 AM, Chris Douglas >> wrote: >> >> > On Wed, Jan 25, 2017 at 11:42 AM, Andrew Wang > > >> > wrote: >> > > Chris and Karthik, could you clarify the contingency of your vote

Hadoop 3.0.0-alpha3 release planning

Hi folks, I wanted to drop a note on the current plan for 3.0.0-alpha3. The main development tasks targeted for alpha3 is finishing all incompatible changes related to HDFS erasure coding and the Tomcat->Jetty conversion for HTTPFS. This is reflected in the 2017-02-03 status update I wrote on the

Re: About 2.7.4 Release

Our release steps are documented on the wiki: 2.6/2.7: https://wiki.apache.org/hadoop/HowToReleasePreDSBCR 2.8+: https://wiki.apache.org/hadoop/HowToRelease I think given the push toward 2.8 and 3.0, there's less interest in streamlining the 2.6 and 2.7 release processes. CHANGES.txt is the big

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

Hi Junping, Noticed this possible blocker float by my inbox today. It had an affects but no target version set: https://issues.apache.org/jira/browse/HDFS-11431 Thoughts? Seems like the hadoop-hdfs-client artifact doesn't work right now. Best, Andrew On Tue, Mar 14, 2017 at 1:41 AM, Junping D

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

Hi Junping, inline, >From my understanding, this issue is related to our previous > improvements with separating client and server jars in HDFS-6200. If we use > the new "client" jar in NN HA deployment, then we will hit the issue > reported. > >From my read of the poms, hadoop-client depends on h

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

I poked around a bit. The 3.0.0-alpha2 binary tarball is only 246M and has more changes than 2.8.0. It looks like the 2.8.0 bin tarball has an extra 1.5GB of docs when extracted compared to 3.0.0-alpha2. I think it's from the extra src-html content: -> % find share/doc -name src-html | xargs du -

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

I've been investigating this a bit. I'm hoping Chris can ring in, since he's identified wire compatibility issues. Replying inline to Chris' comment

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

> > > If unknown fields are dropped, then applications proxying tokens and > other > >> data between servers will effectively corrupt those messages, unless we > >> make everything opaque bytes, which- absent the convenient, prenominate > >> semantics managing the conversion- obviate the compatibil

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

gt;> > 'optional' >> >> > qualifier -- not allowed in proto3): >> >> > $ more pb_drops_two.proto >> >> > syntax = "proto3"; >> >> > message Test { >> >> > string one = 1; >> >> > } >> >

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

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 this new behavior opt-in. Best, Andrew On Mon, Apr 3, 2017 at 9:

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

for years on `hadoop > classpath` for their script to launch jobs or other tools, perhaps no the > best idea to change the behavior without providing a proper deprecation > path. > > > > thanks! > > esteban. > > > > -- > > Cloudera, Inc. > > >

Re: Automated documentation build for Apache Hadoop

Nice work Akira! Appreciate the help with trunk development. On Mon, Apr 3, 2017 at 1:56 AM, Akira Ajisaka wrote: > Hi folks, > > I've created a repository to build and push Apache Hadoop document (trunk) > via Travis CI. > https://github.com/aajisaka/hadoop-document > > The document is updated

3.0.0-alpha3 release status update

Hi folks, We're planning on releasing 3.0.0-alpha3 next month (May 15th). The biggest piece of work targeted for this release is completing user-facing erasure coding changes. This is on track, but there are some other blockers that we also need to push on. I've also written a new status update o

Re: About 2.7.4 Release

I didn't close JIRAs after the 3.0.0-alpha1 or alpha2 releases since closing makes the JIRAs read-only. This makes it more annoying to backport to older releases and for concurrent releases in general. I believe I asked about this on dev-yetus a while back. I'd prefer that the presence of the fix

Re: About 2.7.4 Release

On Mon, May 1, 2017 at 3:44 PM, Allen Wittenauer wrote: > > > On May 1, 2017, at 2:27 PM, Andrew Wang > wrote: > > I believe I asked about this on dev-yetus a while back. I'd prefer that > the presence of the fix version be sufficient to indicate whether a JIRA is >

Re: About 2.7.4 Release

Can we wait for 2.7.4 first? There are still backports happening to branch-2.7. After that, there shouldn't be many backports since both 2.8.x and 2.7.x will be up-to-date with what's in 3.0.0-alpha1 and 3.0.0-alpha2. On Tue, May 2, 2017 at 4:07 PM, Allen Wittenauer wrote: > > Is there any reas

Reminder to always set x.0.0 and x.y.0 fix versions when backporting

Hi folks, I've noticed with the backporting efforts for 2.8.1, we're losing some x.y.0 fix versions (e.g. 2.9.0). Our fix version scheme is described here (also quoted) https://hadoop.apache.org/versioning.html 1. For each *minor* release line, set the *lowest unreleased a.b.c version, whe

3.0.0-alpha3 JIRA version has been renamed to 3.0.0-alpha4

Hi all, The Hadoop PMC is reserving the 3.0.0-alpha3 version for an upcoming release. I've renamed the versions already in JIRA. More information on this to come next week. Please use the renamed "3.0.0-alpha4" version for commits to trunk from here on out. Thanks, Andrew

Heads up: branching 3.0.0-alpha4, use -beta1 for new commits to trunk

Hi folks, I'm in the process of moving out all the JIRA versions from 3.0.0-alpha4 to 3.0.0-beta1 in preparation for a 3.0.0-alpha4 release. I'm hoping to get an RC up tomorrow for a vote, with possibly extending it given the holiday week in the US for July 4th. Please use the beta1 target/fix ve

[VOTE] Release Apache Hadoop 3.0.0-alpha4-RC0

Hi all, As always, thanks to the many, many contributors who helped with this release! I've prepared an RC0 for 3.0.0-alpha4: http://home.apache.org/~wang/3.0.0-alpha4-RC0/ The standard 5-day vote would run until midnight on Tuesday, July 4th. Given that July 4th is a holiday in the US, I expect

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

Thanks for taking a look Steve, On Fri, Jun 30, 2017 at 4:59 AM, Steve Loughran wrote: > > On 30 Jun 2017, at 03:40, Andrew Wang wrote: > > Hi all, > > As always, thanks to the many, many contributors who helped with this > release! I've prepared an RC0

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

, as > docker containers can still be run, but with degraded functionality. I'm +1 > if others feel this isn't a blocker. > > Thanks, > -Shane > > On Fri, Jun 30, 2017 at 10:29 AM, Andrew Wang > wrote: > >> Thanks for taking a look Steve, >> >>

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

it tests >> > >- Deployed both binary and built source to a pseudo cluster, passed >> > the >> > >following sanity tests in insecure, SSL, and SSL+Kerberos mode: >> > > - HDFS basic and ACL >> > > - DistCp basic >> >

3.0.0-beta1 release plan and branch cuts

Hi all, Here's a long overdue update on Hadoop 3. We've made great progress through the alpha releases, thanks to the hard work of numerous contributors. With alpha4 out the door, it's time to look toward beta1! I updated the wiki page with a proposed release date for beta1: September 15th. http

Re: [VOTE] Release Apache Hadoop 2.7.4 (RC0)

I agree with Brahma on the two issues flagged (having src in the binary tarball, missing native libs). These are regressions from prior releases. As an aside, "we release binaries as a convenience" doesn't relax the quality bar. The binaries are linked on our website and distributed through offici

Are binary artifacts are part of a release?

equested. > > Will keep it as RC0 as there is no source code change and it comes from > the > > same build. > > Hope this is satisfactory. > > > > Thanks, > > --Konstantin > > > > On Mon, Jul 31, 2017 at 1:53 PM, Andrew Wang > > wrote: > &g

Re: Are binary artifacts are part of a release?

e ASF >> primarily produces and publishes source-code >> > so voting artifacts should be optimized for evaluation of that." >> > >> > Thanks, >> > --Konst >> > >> > On Mon, Jul 31, 2017 at 4:51 PM, Allen Wittenauer < >> a...@effec

Re: [DISCUSS] Merge yarn-native-services branch into trunk

Hi Jian, Hadoop 3.0.0-beta1 is planned for mid-September. If the plan is to merge in hopefully the next two weeks, that's very, very close to the goal release date. We've already got a pile of blockers and criticals to resolve before then. Could you comment on testing and API stability for this b

Re: [DISCUSS] Merging YARN-5355 (Timeline Service v.2) to trunk

Hi Vrushali, Glad to hear this major dev milestone is nearing completion! Repeating my request on other merge [DISCUSS] threads, could you comment on testing and API stability of this merge? Our timeline for beta1 is about a month out, so there's not much time to fix things beforehand. Looking a

Re: [DISCUSS] Merging YARN-5355 (Timeline Service v.2) to trunk

t; thanks > Vrushali > [link1] https://issues.apache.org/jira/projects/YARN/versions/12337991 > > > On Wed, Aug 16, 2017 at 10:47 AM, Andrew Wang > wrote: > >> Hi Vrushali, >> >> Glad to hear this major dev milestone is nearing completion! >> >> Repeati

Re: [DISCUSS] Merge YARN resource profile (YARN-3926) branch into trunk

Hi Wangda, Can this feature be disabled? Is it on or off by default? We're 1 month from the target release for beta1, so I don't want to introduce risk to existing code paths. TSv2 and S3Guard and YARN Federation are all okay in that regard. I'm also not clear on what work is remaining, there are

Re: [DISCUSS] Merge yarn-native-services branch into trunk

Hi Jian, thanks for the reply, On Thu, Aug 17, 2017 at 1:03 PM, Jian He wrote: > Thanks Andrew for the comments. Answers below: > > - There are no new APIs added in YARN/Hadoop core. In fact, all the new > code are running outside of existing system and they are optional and > require users to e

Branch merges and 3.0.0-beta1 scope

Hi folks, As you might have seen, we've had a number of branch merges floated this past week targeted for 3.0.0-beta1, which is planned for about a month from now. In total, I'm currently tracking these branches: YARN-2915: YARN federation (recently merged) HADOOP-13345: S3Guard (currently being

Re: Branch merges and 3.0.0-beta1 scope

Glad to see the discussion continued in my absence :) >From a release management perspective, it's *extremely* reasonable to block the inclusion of new features a month from the planned release date. A typical software development lifecycle includes weeks of feature freeze and weeks of code freeze

Re: Branch merges and 3.0.0-beta1 scope

ce we release beta, compatibility would be a > matter. > During this gap i.e between beta-GA release, should we maintain > compatibility ? > If my understanding is right then TSv2 have to be merged with beta1 > release. In TSv2 phase-2, we have compatibility changes from phase-1. > >

Re: Branch merges and 3.0.0-beta1 scope

Hi Jason, I agree with this proposal. I'll start another email thread spelling this out, and gather additional feedback. Best, Andrew On Fri, Aug 25, 2017 at 6:27 AM, Jason Lowe wrote: > Andrew Wang wrote: > > >> This means I'll cut branch-3 and >> branch-3.0,

[DISCUSS] Branches and versions for Hadoop 3

Hi folks, With 3.0.0-beta1 fast approaching, I wanted to go over the proposed branching strategy. In the early 2.x days, moving trunk immediately to 3.0.0 was a mistake. branch-2 and trunk were virtually identical, and increased backport complexity. Until we need to make incompatible changes, the

Re: Branch merges and 3.0.0-beta1 scope

t; On Fri, Aug 25, 2017 at 10:54 AM, Rohith Sharma K S < > rohithsharm...@apache.org> wrote: > >> On 25 August 2017 at 22:39, Andrew Wang wrote: >> >> > Hi Rohith, >> > >> > Given that we're advertising TSv2 as an alpha feature, I think we

Re: Branch merges and 3.0.0-beta1 scope

t; changes are safe. >> >> Discussed with Andrew offline, we decided to not put this to beta1 since >> beta1 is not far away. But we want to put it before GA if sufficient tests >> are done. >> >> Thanks, >> Wangda >> >> >> >> On Fri,

2017-08-25 Hadoop 3 release status update

Hi all, I've written up a status report for the current state of Hadoop 3 on the wiki. I've also pasted it below for your convenience. Cheers, Andrew https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+3+release+status+updates 2017-08-25 Another month flew by without an update. This is a

Re: [DISCUSS] Branches and versions for Hadoop 3

So far I've seen no -1's to the branching proposal, so I plan to execute this tomorrow unless there's further feedback. Regarding the above discussion, I think Jason and I have essentially the same opinion. I hope that keeping trunk a release branch means a higher bar for merges and code review i

  1   2   3   >