Re: [DISCUSS] Release cadence and EOL

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

[jira] [Created] (HADOOP-13790) Make qbt script executable

Andrew Wang created HADOOP-13790: Summary: Make qbt script executable Key: HADOOP-13790 URL: https://issues.apache.org/jira/browse/HADOOP-13790 Project: Hadoop Common Issue Type: Improvement

[jira] [Resolved] (HADOOP-13717) Normalize daemonization behavior of the diskbalancer with balancer and mover

[ https://issues.apache.org/jira/browse/HADOOP-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-13717. -- Resolution: Invalid Fix Version/s: (was: 3.0.0-alpha2) Reverted and reclosing

[jira] [Reopened] (HADOOP-13717) Normalize daemonization behavior of the diskbalancer with balancer and mover

[ https://issues.apache.org/jira/browse/HADOOP-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang reopened HADOOP-13717: -- > Normalize daemonization behavior of the diskbalancer with balancer and mo

[jira] [Created] (HADOOP-13784) Output javadoc inside the target directory

Andrew Wang created HADOOP-13784: Summary: Output javadoc inside the target directory Key: HADOOP-13784 URL: https://issues.apache.org/jira/browse/HADOOP-13784 Project: Hadoop Common Issue

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

[jira] [Resolved] (HADOOP-13696) change hadoop-common dependency scope of jsch to provided.

[ https://issues.apache.org/jira/browse/HADOOP-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-13696. -- Resolution: Won't Fix Fix Version/s: (was: 3.0.0-alpha2) I filed and linked HADOOP

[jira] [Reopened] (HADOOP-13696) change hadoop-common dependency scope of jsch to provided.

[ https://issues.apache.org/jira/browse/HADOOP-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang reopened HADOOP-13696: -- > change hadoop-common dependency scope of jsch to provi

[jira] [Created] (HADOOP-13759) Split SFTP FileSystem into its own artifact

Andrew Wang created HADOOP-13759: Summary: Split SFTP FileSystem into its own artifact Key: HADOOP-13759 URL: https://issues.apache.org/jira/browse/HADOOP-13759 Project: Hadoop Common Issue

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

ant to > 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

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]

[jira] [Resolved] (HADOOP-9280) HADOOP-7101 was never merged from 0.23.x to the 1.x branch

[ https://issues.apache.org/jira/browse/HADOOP-9280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-9280. - Resolution: Won't Fix Old JIRA for branch-1, resolving. > HADOOP-7101 was never merged f

[jira] [Resolved] (HADOOP-8190) Eclipse plugin fails to access remote cluster

[ https://issues.apache.org/jira/browse/HADOOP-8190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-8190. - Resolution: Not A Problem This JIRA is 4 years old, I'm going to resolve. Please reopen if you

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:

[jira] [Created] (HADOOP-13724) Fix a few typos in site markdown documents

Andrew Wang created HADOOP-13724: Summary: Fix a few typos in site markdown documents Key: HADOOP-13724 URL: https://issues.apache.org/jira/browse/HADOOP-13724 Project: Hadoop Common Issue

[jira] [Created] (HADOOP-13717) Shell scripts call hadoop_verify_logdir even when command is not started as daemon

Andrew Wang created HADOOP-13717: Summary: Shell scripts call hadoop_verify_logdir even when command is not started as daemon Key: HADOOP-13717 URL: https://issues.apache.org/jira/browse/HADOOP-13717

[jira] [Created] (HADOOP-13705) Revert HADOOP-13534 Remove unused TrashPolicy#getInstance and initialize code

Andrew Wang created HADOOP-13705: Summary: Revert HADOOP-13534 Remove unused TrashPolicy#getInstance and initialize code Key: HADOOP-13705 URL: https://issues.apache.org/jira/browse/HADOOP-13705

[jira] [Resolved] (HADOOP-13699) Configuration does not substitute multiple references to the same var

[ https://issues.apache.org/jira/browse/HADOOP-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-13699. -- Resolution: Fixed Fix Version/s: 3.0.0-alpha2 Committed to trunk, thanks for reviewing

[jira] [Created] (HADOOP-13699) Configuration does not substitute multiple references to the same var

Andrew Wang created HADOOP-13699: Summary: Configuration does not substitute multiple references to the same var Key: HADOOP-13699 URL: https://issues.apache.org/jira/browse/HADOOP-13699 Project

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

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

[jira] [Resolved] (HADOOP-11090) [Umbrella] Support Java 8 in Hadoop

[ https://issues.apache.org/jira/browse/HADOOP-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-11090. -- Resolution: Fixed I think we're safe to resolve this JIRA. CDH blacklists a few versions

Re: new look site

Can we revert that change until we can get the site fixed? On Tue, 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/ >

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

Have you git blamed to dig up the original JIRA conversation? I think that deprecation predates many of us, so you might not get much historical perspective from the mailing list. I'm happy to lend a +1 though, since like you said, it doesn't seem like that config key is going anywhere. On Fri,

[jira] [Created] (HADOOP-13632) Daemonization does not check process liveness before renicing

Andrew Wang created HADOOP-13632: Summary: Daemonization does not check process liveness before renicing Key: HADOOP-13632 URL: https://issues.apache.org/jira/browse/HADOOP-13632 Project: Hadoop

[jira] [Created] (HADOOP-13615) Convert uses of AtomicLong for counter metrics to LongAdder

Andrew Wang created HADOOP-13615: Summary: Convert uses of AtomicLong for counter metrics to LongAdder Key: HADOOP-13615 URL: https://issues.apache.org/jira/browse/HADOOP-13615 Project: Hadoop Common

[jira] [Resolved] (HADOOP-7198) Hadoop defaults for web UI ports often fall smack in the middle of Linux ephemeral port range

[ https://issues.apache.org/jira/browse/HADOOP-7198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-7198. - Resolution: Duplicate Believe this is handled by HDFS-9427 and related JIRAs. Resolving; any

Re: how about syncing namenode metadata to glusterfs?

This is a similar idea to NFS HA, which you can read about here: https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html This is definitely less preferred compared to using QJM, since you need an external mechanism for fencing writes. FWIW, I don't

[jira] [Resolved] (HADOOP-13575) Website shows incorrect 25 January, 2016 as the release date for 2.7.3

[ https://issues.apache.org/jira/browse/HADOOP-13575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-13575. -- Resolution: Done I noticed this independently and fixed already, should be good. > Webs

[jira] [Created] (HADOOP-13583) Incorporate checkcompatibility script which runs Java API Compliance Checker

Andrew Wang created HADOOP-13583: Summary: Incorporate checkcompatibility script which runs Java API Compliance Checker Key: HADOOP-13583 URL: https://issues.apache.org/jira/browse/HADOOP-13583

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

ative >> - Installed on 3-node, non-secure cluster >> - Ran sleep jobs >> - Ensured preemption works as expected >> >> -Eric Payne >> >> >> - Original Message - >> From: Andrew Wang <andrew.w...@cloudera.com> >> To: "common-d

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

llen Wittenauer <a...@effectivemachines.com> > wrote: > > > > > >> On Sep 1, 2016, at 2:57 PM, Andrew Wang <andrew.w...@cloudera.com> > wrote: > >> > >> Steve requested a git hash for this release. This led us into a brief > >> discussion of our use of g

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

alpha1-RC0 tagger Andrew Wang <w...@apache.org> 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:

Re: Yes/No newbie question on contributing

Hello Martin, Sorry for the slow followup here. If you'd like, someone can give you edit permissions to the wiki so you can make changes yourself. In this case, please provide your wiki username. I also took a look at your document, and am having a hard time determining the diff between it and

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

art small cluster and test simple programs, focusing on EC > functionalities > > -- Zhe > > On Tue, Aug 30, 2016 at 8:51 AM Andrew Wang <andrew.w...@cloudera.com> > wrote: > >> Hi all, >> >> Thanks to the combined work of many, many contributors,

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

[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

[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:

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 <andrew.w...@cloudera.com> wrote: > Starting this now

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 <andrew.w...@cloudera.com> 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

[jira] [Reopened] (HADOOP-13286) add a S3A scale test to do gunzip and linecount

[ https://issues.apache.org/jira/browse/HADOOP-13286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang reopened HADOOP-13286: -- > add a S3A scale test to do gunzip and lineco

[jira] [Resolved] (HADOOP-13286) add a S3A scale test to do gunzip and linecount

[ https://issues.apache.org/jira/browse/HADOOP-13286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-13286. -- Resolution: Duplicate Fix Version/s: (was: 2.8.0) > add a S3A scale test to

[jira] [Resolved] (HADOOP-12976) s3a toString to be meaningful in logs

[ https://issues.apache.org/jira/browse/HADOOP-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-12976. -- Resolution: Duplicate > s3a toString to be meaningful in l

[jira] [Resolved] (HADOOP-12997) s3a to pass PositionedReadable contract tests, improve readFully perf.

[ https://issues.apache.org/jira/browse/HADOOP-12997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-12997. -- Resolution: Duplicate Fix Version/s: (was: 2.8.0) > s3a to pass PositionedReada

[jira] [Reopened] (HADOOP-12997) s3a to pass PositionedReadable contract tests, improve readFully perf.

[ https://issues.apache.org/jira/browse/HADOOP-12997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang reopened HADOOP-12997: -- > s3a to pass PositionedReadable contract tests, improve readFully p

[jira] [Reopened] (HADOOP-12976) s3a toString to be meaningful in logs

[ https://issues.apache.org/jira/browse/HADOOP-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang reopened HADOOP-12976: -- > s3a toString to be meaningful in l

[jira] [Resolved] (HADOOP-12762) task: null java.lang.unsupportedoperationexception: this is supposed to be overridden by subclasses.

[ https://issues.apache.org/jira/browse/HADOOP-12762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-12762. -- Resolution: Cannot Reproduce > task: null java.lang.unsupportedoperationexcept

[jira] [Reopened] (HADOOP-12420) While trying to access Amazon S3 through hadoop-aws(Spark basically) I was getting Exception in thread "main" java.lang.NoSuchMethodError: com.amazonaws.services.s3.tr

[ https://issues.apache.org/jira/browse/HADOOP-12420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang reopened HADOOP-12420: -- > While trying to access Amazon S3 through hadoop-aws(Spark basically) I was > getting Exc

[jira] [Resolved] (HADOOP-12420) While trying to access Amazon S3 through hadoop-aws(Spark basically) I was getting Exception in thread "main" java.lang.NoSuchMethodError: com.amazonaws.services.s3.tr

[ https://issues.apache.org/jira/browse/HADOOP-12420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-12420. -- Resolution: Duplicate Fix Version/s: (was: 2.8.0) > While trying to access Ama

[jira] [Reopened] (HADOOP-12319) S3AFastOutputStream has no ability to apply backpressure

[ https://issues.apache.org/jira/browse/HADOOP-12319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang reopened HADOOP-12319: -- > S3AFastOutputStream has no ability to apply backpress

[jira] [Resolved] (HADOOP-12319) S3AFastOutputStream has no ability to apply backpressure

[ https://issues.apache.org/jira/browse/HADOOP-12319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-12319. -- Resolution: Duplicate Fix Version/s: (was: 2.8.0) > S3AFastOutputStream

[jira] [Resolved] (HADOOP-11874) s3a can throw spurious IOEs on close()

[ https://issues.apache.org/jira/browse/HADOOP-11874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-11874. -- Resolution: Duplicate > s3a can throw spurious IOEs on cl

[jira] [Reopened] (HADOOP-11874) s3a can throw spurious IOEs on close()

[ https://issues.apache.org/jira/browse/HADOOP-11874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang reopened HADOOP-11874: -- > s3a can throw spurious IOEs on cl

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

e > JIRAs to track them. > > Jason > > > ------ > *From:* Andrew Wang <andrew.w...@cloudera.com> > *To:* Karthik Kambatla <ka...@cloudera.com> > *Cc:* larry mccay <lmc...@apache.org>; Vinod Kumar Vavilapalli < > vino..

Re: Setting JIRA fix versions for 3.0.0 releases

version updates. On Thu, Aug 25, 2016 at 11:44 AM, Andrew Wang <andrew.w...@cloudera.com> 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.html > > Invoc

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

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 <andrew.w...@cloudera.com> wrote: > I'll also add that, as a YARN newbie, I did hit two usabili

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

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

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

I'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 <andrew.w...@cloudera.com> wrote: &

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

Re: Heads up: branched branch-3.0.0-alpha1

send another email when this happens. On Fri, Jul 15, 2016 at 7:26 PM, Andrew Wang <andrew.w...@cloudera.com> 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-alp

Re: Wiki migration and clean-up

s for those sites definitely load much, >> much >> faster than ASF wiki pages using MoinMoin. Clearly no surprise. >> >> Best, >> Martin >> >> >> On Wed, Jul 27, 2016 at 10:29 AM, Ray Chiang <rchi...@apache.org> wrote: >> >> Good to know. It's

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

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]

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: Feedback on IRC channel

evelopment, "just check out code and go", etc). > 3. Organize the Users section a bit more. The "Setting up a Hadoop >Cluster" is grouped well, but I'd perhaps rearrange the ordering a bit. > > -Ray > > > On 7/14/16 3:49 PM, Andrew Wang wrote: > >> I t

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,

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

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

Re: Setting JIRA fix versions for 3.0.0 releases

two releases (2.7.3 / 2.8.0). > > Thanks, > Wangda > > On Mon, Jul 25, 2016 at 11:02 AM, Andrew Wang <andrew.w...@cloudera.com> > 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,

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

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 <andrew.w...@cloudera.com>

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

Re: Setting JIRA fix versions for 3.0.0 releases

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 <a...@effectivemachines.com> wrote: > > > On Jul 22, 2016, at 7:16 PM, Andrew Wang <andrew.w...@cloudera.com> > wrote: > &g

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

[jira] [Created] (HADOOP-13409) Andrew's test JIRA

Andrew Wang created HADOOP-13409: Summary: Andrew's test JIRA Key: HADOOP-13409 URL: https://issues.apache.org/jira/browse/HADOOP-13409 Project: Hadoop Common Issue Type: Bug

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

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

Re: Setting JIRA fix versions for 3.0.0 releases

> > 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. > > Thanks > +Vinod > >

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

[jira] [Resolved] (HADOOP-13383) Update release notes for 3.0.0-alpha1

[ https://issues.apache.org/jira/browse/HADOOP-13383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-13383. -- Resolution: Fixed Fix Version/s: 3.0.0-alpha1 Thanks for the reviews Akira and Sangjin

Re: Not being able to add HDFS contributors

What works for me is pasting in the JIRA userID, checking "ignore popups from this page" to quash the browser alerts, and then hitting the "update" button. What's broken is the username auto-complete, actually saving works fine. On Tue, Jul 19, 2016 at 5:08 PM, Chris Douglas

[jira] [Created] (HADOOP-13383) Update release notes for 3.0.0-alpha1

Andrew Wang created HADOOP-13383: Summary: Update release notes for 3.0.0-alpha1 Key: HADOOP-13383 URL: https://issues.apache.org/jira/browse/HADOOP-13383 Project: Hadoop Common Issue Type

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

Re: Feedback on IRC channel

ld we use it more >>>> often? >>>> If that starts to gain traction, we could set up a more open room for >>>> >>> users >>> >>>> as well. >>>> >>>> Sangjin >>>> >>>> On Wed, Jul 1

[jira] [Resolved] (HADOOP-13348) delete spurious 'master' branch

[ https://issues.apache.org/jira/browse/HADOOP-13348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-13348. -- Resolution: Fixed Assignee: Andrew Wang With the help of INFRA-12223, the master branch

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

[jira] [Resolved] (HADOOP-13303) Detail Informations of KMS High Avalibale

[ https://issues.apache.org/jira/browse/HADOOP-13303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-13303. -- Resolution: Invalid Please use the user list for questions like this, JIRA is for tracking

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: feature branch merge policy

This vote from last year covers some of it, says to use "git merge --no-ff" and tags. With merge, I believe the history is propagated correctly. https://lists.apache.org/thread.html/43cd65c6b6c3c0e8ac2b3c76afd9eff1f78b177fabe9c4a96d9b3d0b@1440189889@%3Ccommon-dev.hadoop.apache.org%3E I never got

Re: [DISCUSS] Increased use of feature branches

> > I agree with the concerns you raise around feature rot. For a feature like >> EC, it'd be untenable to leave it in trunk-incompat since the rebases would >> be impossible. I imagine we'd also need a very motivated maintainer (or >> maintainers) to handle the periodic integration of new trunk

Re: [DISCUSS] Increased use of feature branches

incompatible changes to trunk >> is a >> >> much more tricky question (related to trunk-incompat etc.). But per my >> >> comment above, IMHO, *not committing uncompleted work to trunk* should >> be a >> >> much easier principle to agree upon. >> >> >> >>

[jira] [Resolved] (HADOOP-13175) Remove hadoop-ant from hadoop-tools

[ https://issues.apache.org/jira/browse/HADOOP-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang resolved HADOOP-13175. -- Resolution: Fixed Hadoop Flags: Incompatible change Fix Version/s: 3.0.0-alpha1

Re: Cannot create release artifacts for branch-2.8

I'm not super happy about the alternative of reverting the auto-generated CHANGES/RL JIRAs, since it means we have to do CHANGES.txt maintenance again in branch-2. That's an overhead that we pay for every commit, and it's particularly bad when doing backports. As I commented on HADOOP-12892, I

[jira] [Reopened] (HADOOP-13175) Remove hadoop-ant from hadoop-tools

[ https://issues.apache.org/jira/browse/HADOOP-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang reopened HADOOP-13175: -- Assignee: Chris Douglas Reopening based on Jason's latest comment. FWIW patch LGTM +1

Re: Why there are so many revert operations on trunk?

To clarify what happened here, I moved the commits to a feature branch, not just reverting the commits. The intent was to make it easy to merge back in later, and also to unblock the 2.8 and 3.0 releases we've been trying very hard to wrap up for weeks. This doesn't slow down development since you

Re: Release numbering for 3.x leading up to GA

t are the goals we want to achieve for alpha1? From EC's > perspective, maybe we should target on having all compatibility-related > changes in alpha1, like new config keys and fsimage format? > > Thanks, > > On Thu, May 12, 2016 at 11:35 AM Andrew Wang <andrew.w...@cloudera.com

Re: [DISCUSS] Release blocker HADOOP-12893 (LICENSE and NOTICE files)

"the src tarball is the only official release artifact, the bin tarball and jars are only provided as a convenience", but I don't think we're actually allowed to do that. On Tue, May 17, 2016 at 1:56 AM, Steve Loughran <ste...@hortonworks.com> wrote: > > > On 16 May 20

Re: Different JIRA permissions for HADOOP and HDFS

; > > > >> > > > > >> Thanks Junping! It seems to work now. > > > > >> > > > > >> On Mon, May 16, 2016 at 5:22 PM, Junping Du <j...@hortonworks.com> > > > > wrote: > > > > >> > > > > >> Someone fix the permis

<    1   2   3   4   5   6   >