Re: Assignment to JIRA tickets

I believe he’s svaughan. I went ahead and added Steve to the contributors group for the HADOOP, HDFS, YARN, and MAPREDUCE projects in jira. > On Aug 4, 2022, at 3:49 PM, Wei-Chiu Chuang wrote: > > What is your JIRA user id? I can help you by adding you to the contributor > list where you'll

Re: Publishing hadoop-lzo maven package in com.hadoop namespace

As an ASF project we can not distribute GPL code. As an ASF project it’s also our job to defend our trademarks. We should actively prevent this GPL code from going to maven central with our name attached to it. > On May 5, 2022, at 1:49 PM, Wei-Chiu Chuang wrote: > > Please be careful. >

Re: [DISCUSS] Merging PRs vs. commit from CLI and keep committer field

If you add a line in the commit message that the commit closes a given PR # then GitHub will annotate the PR as related to the specific commit and close it for you. i.e. you can add “closes #3454” to the commit message body and then PR 3454 will close and link to that commit when it hits the

[jira] [Created] (HADOOP-17946) Update commons-lang to latest 3.x

Sean Busbey created HADOOP-17946: Summary: Update commons-lang to latest 3.x Key: HADOOP-17946 URL: https://issues.apache.org/jira/browse/HADOOP-17946 Project: Hadoop Common Issue Type: Task

Re: [DISCUSS] Migrate to Yetus Interface classification annotations

I think consolidating on a common library and tooling for defining API expectations for Hadoop would be great. Unfortunately, the Apache Yetus community recently started a discussion around dropping their maintenance of the audience annotations codebase[1] due to lack of community interest. In

Re: [Conference] Uber's story on running Apache Hadoop deployment in Docker

Hi Brahma! Thanks for organizing this. What’s the timezone for the 10p - midnight? Pacific Time? > On Sep 8, 2021, at 1:17 AM, Brahma Reddy Battula wrote: > > Hi All, > > Updated the meeting to record the session.. Please use the following link > to attend the conference tomorrow. > > >

Re: Building 3.2.2 -- hadoop-client-check-test-invariants failing on edu.umd.cs.findbugs

If you want to update to that zookeeper version then you should update the build files to exclude those classes from getting included transitively from it. Would you mind filing a bug against zookeeper as well? spotbugs-annotations 3.1.9 is LGPL, so they should not be exposing it as a

Re: Are you developing Hadoop on Windows 10 Pro x64?

Hi! I can empathize with your frustration; building Hadoop in general is an involved process and being on different day-to-day development platform than most of the existing committers only makes things harder. Please try to keep in mind that the Hadoop community is made up of folks

Re: [VOTE] Release Apache Hadoop 3.3.1 RC3

Sounds good to me. That would be until Thursday June 10th, right? As a side note it’s concerning that a double-dot maintenance release is a big release, but I get that it’s the current state of the project. > On Jun 3, 2021, at 11:30 AM, Wei-Chiu Chuang wrote: > > Hello, > do we want to

Re: [VOTE] Hadoop 3.1.x EOL

+1 > On Jun 3, 2021, at 1:14 AM, Akira Ajisaka wrote: > > Dear Hadoop developers, > > Given the feedback from the discussion thread [1], I'd like to start > an official vote > thread for the community to vote and start the 3.1 EOL process. > > What this entails: > > (1) an official

Re: [DISCUSS] Change project style guidelines to allow line length 100

Hi folks! The consensus seems pretty strongly in favor of increasing the line length limit. Do folks still want to see a formal VOTE thread? > On May 19, 2021, at 4:22 PM, Sean Busbey wrote: > > Hello! > > What do folks think about changing our line length guidelines to a

[DISCUSS] which release lines should we still consider actively maintained?

Hi folks! Which release lines do we as a community still consider actively maintained? I found an earlier discussion[1] where we had consensus to consider branches that don’t get maintenance releases on a regular basis end-of-life for practical purposes. The result of that discussion was

[jira] [Resolved] (HADOOP-17115) Replace Guava Sets usage by Hadoop's own Sets in hadoop-common and hadoop-tools

[ https://issues.apache.org/jira/browse/HADOOP-17115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey resolved HADOOP-17115. -- Fix Version/s: 3.4.0 Hadoop Flags: Reviewed Resolution: Fixed merged to trunk

Re: [DISCUSS] Change project style guidelines to allow line length 100

hadoop.apache.org%3E>>; >> - >> >> https://lists.apache.org/thread.html/3e1785cbbe14dcab9bb970fa0f534811cfe00795a8cd1100580f27dc%401430849118%40%3Ccommon-dev.hadoop.apache.org%3E >> >> <https://lists.apache.org/thread.html/3e1785cbbe14dcab9bb970fa0f534811cfe00795a8cd1100580f

[DISCUSS] Change project style guidelines to allow line length 100

Hello! What do folks think about changing our line length guidelines to allow for 100 character width? Currently, we tell folks to follow the sun style guide with some exception unrelated to line length. That guide says width of 80 is the standard and our current check style rules act as

[DISCUSS] check style changes

Hi folks! I’d like to start cleaning up our nightly tests. As a bit of low hanging fruit I’d like to alter some of our check style rules to match what I think we’ve been doing in the community. How would folks prefer I make sure we have consensus on such changes? As an example, our last

Re: Needs support to add more entropy to improve cryptographic randomness on Linux VMs

You should file an INFRA jira asking about this. They can get in touch with the folks who maintain the Hadoop labeled nodes. On Tue, Jan 14, 2020 at 12:42 PM Ahmed Hussein wrote: > > Hi, > > I was investigating a JUnit test > (MAPREDUCE-7079:TestMRIntermediateDataEncryption > is failing in

Re: How should we do about dependency update?

speaking with my HBase hat on instead of my Hadoop hat, when the Hadoop project publishes that there's a CVE but does not include a maintenance release that mitigates it for a given minor release line, we assume that means the Hadoop project is saying that release line is EOM and should be

Re: [DISCUSS] GitHub PRs without JIRA number

We should add a Pull Request Template that specifically calls out the expectation that folks need to have a JIRA associated with their PR for it to get reviewed. Expectations around time to response and how to go about getting attention when things lag would also be good to include. (e.g. are

Re: [VOTE] Mark 2.6, 2.7, 3.0 release lines EOL

On Mon, Aug 26, 2019 at 9:20 AM Eric Badger wrote: > > - Stuff has been going into branch-2 sporadically but I don't who is > actively > using that code other than as part of a cherrypick backwards strategy. > > - Should we do a 2.10.x release? Or just say "time to upgrade?" > > We have talked at

Re: [VOTE] Move Submarine source code, documentation, etc. to a separate Apache Git repo

+1 (non-binding) On Fri, Aug 23, 2019 at 9:06 PM Wangda Tan wrote: > > Hi devs, > > This is a voting thread to move Submarine source code, documentation from > Hadoop repo to a separate Apache Git repo. Which is based on discussions of >

Re: [VOTE] Mark 2.6, 2.7, 3.0 release lines EOL

+1 On Tue, Aug 20, 2019 at 10:03 PM Wangda Tan wrote: > > Hi all, > > This is a vote thread to mark any versions smaller than 2.7 (inclusive), > and 3.0 EOL. This is based on discussions of [1] > > This discussion runs for 7 days and will conclude on Aug 28 Wed. > > Please feel free to share

Re: Make EOL branches to public?

For what it's worth, in HBase we've been approximating which Hadoop lines are EOL by looking at release rates and specifically CVE announcements that include an affected release line but do not include a fix for that release line. Our current approximation[1] lists 2.6, 2.7, and 3.0 as dead. So

Re: [DISCUSS] Prefer Github PR Integration over patch in JIRA

a word of caution. according to INFRA-18748, asf infra is going to be cutting out blind PR building. So we'll need to be sure that precommit integration works e.g. testing PRs because there's a JIRA that a whitelisted contributor has associated and put in patch available status. On Mon, Jul 22,

Re: getting Yetus and github to be friends

Unfortunately I think we're a little late to the game to have this be much more than "what does AW have to do". The upcoming Yetus 0.9.0 release includes a pretty huge reworking of Yetus to make it work better in non-ASF settings; including getting the GitHub PR handling updated to work with

Re: Can someone add me to the JIRA admin list

rks fine for me, > because I primarily only work on HDFS and Hadoop Common space. > And that's probably a good idea to respect my peer YARN/MAPREDUCE/HDDS > committers, but I am just curious. > > On Thu, Dec 13, 2018 at 5:37 AM Sean Busbey wrote: >> >> It looks like I'm only

Can someone add me to the JIRA admin list

It looks like I'm only listed as a JIRA admin on the YARN tracker. Could someone add me on the rest of the project trackers? I'm trying to get a new contributor on-boarded so I can assign them an issue they're working. - To

[jira] [Created] (HADOOP-15971) website repo is missing a LICENSE / NOTICE

Sean Busbey created HADOOP-15971: Summary: website repo is missing a LICENSE / NOTICE Key: HADOOP-15971 URL: https://issues.apache.org/jira/browse/HADOOP-15971 Project: Hadoop Common Issue

[jira] [Created] (HADOOP-15878) website should have a list of CVEs w/impacted versions and guidance

Sean Busbey created HADOOP-15878: Summary: website should have a list of CVEs w/impacted versions and guidance Key: HADOOP-15878 URL: https://issues.apache.org/jira/browse/HADOOP-15878 Project

Re: [VOTE] reset/force push to clean up inadvertent merge commit pushed to trunk

-1 (non-binding) force pushes are extremely disruptive. there's no way to know who's updated their local git repo to include these changes since the commit went in. if a merge commit is so disruptive that we need to subject folks to the inconvenience of a force push then we should have more

Re: [DISCUSS]: securing ASF Hadoop releases out of the box

I really, really like the approach of defaulting to only non-routeable IPs allowed. it seems like a good tradeoff for complexity of implementation, pain to reconfigure, and level of protection. On Thu, Jul 5, 2018 at 2:25 PM, Todd Lipcon wrote: > The approach we took in Apache Kudu is that, if

Re: site doc cleanup

IMHO dump the docs from the beta release as well. anyone on an alpha/beta release should move on to a GA release and beta1 should have been API frozen compared to GA. 3.1.0 was labeled "not ready for production" in its release notes[1]. Seems that means 3.0.3 is the stable3 release? Speaking

Re: yetus build rejecting shaded artifacts ....

yep! I'll walk through how to find it, skip to "tl;dr:" if you just want the answer. Start with the "Console output" line in the footer of the QABot post Console output https://builds.apache.org/job/PreCommit-HADOOP-Build/14777/console Search the output for "Checking client artifacts".

Re: [DISCUSS] Branch Proposal: HADOOP 15407: ABFS

apologies, copying back in common-dev@ with my question about the code. On Tue, May 15, 2018 at 2:36 PM, Sean Busbey <bus...@cloudera.com> wrote: > > Internal constraints prevented this feature from being developed in > Apache, so we want to ensure that all the code is discusse

Re: PreCommit-Admin fails to fetch issue list from jira

FYI Duo, I believe https://issues.apache.org/jira/browse/YETUS-594 is also slated to fix this. it just needs a review. On Tue, Jan 16, 2018 at 4:38 AM, Duo Zhang wrote: > Started from this build > > https://builds.apache.org/job/PreCommit-Admin/329113/ > > Have dug a bit,

Re: Apache Hadoop qbt Report: branch2+JDK7 on Linux/x86

Just curious, Junping what would "solid evidence" look like? Is the supposition here that the memory leak is within HDFS test code rather than library runtime code? How would such a distinction be shown? On Tue, Oct 24, 2017 at 4:06 PM, Junping Du wrote: > Allen, > Do

Re: Do we still have nightly (or even weekly) unit test run for Hadoop projects?

Here's the email from last night to common-dev@hadoop: https://s.apache.org/ARe1 On Wed, Oct 18, 2017 at 10:42 PM, Akira Ajisaka wrote: > Yes, qbt runs nightly and it sends e-mail to dev lists. > https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/ > > Regards,

Re: [DISCUSS] moving to Apache Yetus Audience Annotations

wrote: > Is this itself an incompatible change? I imagine the bytecode will be > different. > > I think we're too late to do this for beta1 given that I want to cut an > RC0 today. > > On Fri, Sep 22, 2017 at 7:03 AM, Sean Busbey <bus...@cloudera.com> wrote: > >

[DISCUSS] moving to Apache Yetus Audience Annotations

When Apache Yetus formed, it started with several key pieces of Hadoop that looked reusable. In addition to our contribution testing infra, the project also stood up a version of our audience annotations for delineating the public facing API[1]. I recently got the Apache HBase community onto the

Re: Trunk fails

On Wed, Sep 20, 2017 at 5:12 AM, Steve Loughran wrote: > > > > > What we could do is have a patch submission process which says "if you are > playing with packaging, you must declare at the time of patch submission > that you have run a full mvn clean install". And a

Re: [DISCUSS] Can we make our precommit test robust to dependency changes while staying usable?

On Thu, Sep 14, 2017 at 4:23 PM, Andrew Wang wrote: > > > > > I discussed this on yetus-dev a while back and Allen thought it'd be > non-trivial: > > https://lists.apache.org/thread.html/552ad614d1b3d5226a656b60c01084 >

Re: [DISCUSS] Can we make our precommit test robust to dependency changes while staying usable?

On 2017-09-14 15:36, Chris Douglas wrote: > This has gotten bad enough that people are dismissing legitimate test > failures among the noise. > > On Thu, Sep 14, 2017 at 1:20 PM, Allen Wittenauer > wrote: > > Someone should probably

Re: [DISCUSS] Can we make our precommit test robust to dependency changes while staying usable?

t; On Sep 14, 2017, at 8:03 AM, Sean Busbey <bus...@cloudera.com> wrote: > > > > * HADOOP-14654 updated commons-httplient to a new patch release in > > hadoop-project > > * Precommit checked the modules that changed (i.e. not many) > > * nightly had Azure support

[DISCUSS] Can we make our precommit test robust to dependency changes while staying usable?

Moving discussion here from HADOOP-14654. Short synopsis: * HADOOP-14654 updated commons-httplient to a new patch release in hadoop-project * Precommit checked the modules that changed (i.e. not many) * nightly had Azure support break due to a change in behavior. Is this just the cost of our

[jira] [Created] (HADOOP-14857) downstream client artifact IT fails

Sean Busbey created HADOOP-14857: Summary: downstream client artifact IT fails Key: HADOOP-14857 URL: https://issues.apache.org/jira/browse/HADOOP-14857 Project: Hadoop Common Issue Type

Re: Moving Java Forward Faster

ugh. this will be rough for cross-jdk compatibility, unless they update the target jre options of javac to support more than the last 2 major versions. > Question: Does GPL licensing of the JDK/JVM affect us negatively? Nope. all the openjdk bits we rely on were already going to be under the

Re: Pre-Commit build is failing

-dev@yetus to bcc, since I think this is a Hadoop issue and not a yetus issue. Please review/commit HADOOP-14686 (which I am providing as a volunteer/contributor on the Hadoop project). On Tue, Jul 25, 2017 at 7:54 PM, Allen Wittenauer wrote: > > Again: just

[jira] [Created] (HADOOP-14686) Branch-2.7 .gitignore is out of date

Sean Busbey created HADOOP-14686: Summary: Branch-2.7 .gitignore is out of date Key: HADOOP-14686 URL: https://issues.apache.org/jira/browse/HADOOP-14686 Project: Hadoop Common Issue Type

Re: zstd compression

>> > below to make the user opt in, and if we are not shipping zstd with our >> products (source code releases), >> > then this is an acceptable usage. >> > >> > Cheers, >> > Chris >> >> >> So I think we are in the clear with respec

Re: zstd compression

I know that the HBase community is also looking at what to do about our inclusion of zstd. We've had it in releases since late 2016. My plan was to request that they relicense it. Perhaps the Hadoop PMC could join HBase in the request? On Sun, Jul 16, 2017 at 8:11 PM, Allen Wittenauer

Re: Apache Hadoop qbt Report: trunk+JDK8 on Linux/x86

disallowing force pushes to trunk was done back in: * August 2014: INFRA-8195 * February 2016: INFRA-11136 On Mon, Apr 17, 2017 at 11:18 AM, Jason Lowe wrote: > I found at least one commit that was dropped, MAPREDUCE-6673. I was able to > cherry-pick the original

Re: H9 build slave is bad

All the precommit builds should be doing the correct thing now for making sure we don't render nodes useless. They don't flag the problem yet and someone will still need to run the "cleanup" job on nodes broken before jenkins runs pick up the new configuration changes. Probably best if we move to

Re: H9 build slave is bad

On Wed, Mar 8, 2017 at 2:04 PM, Allen Wittenauer <a...@effectivemachines.com> wrote: > >> On Mar 8, 2017, at 9:34 AM, Sean Busbey <bus...@cloudera.com> wrote: >> >> Is this HADOOP-13951? > > Almost certainly. Here's the run that broke it again: >

Re: H9 build slave is bad

Is this HADOOP-13951? On Tue, Mar 7, 2017 at 8:32 PM, Andrew Wang wrote: > A little ping that H9 hit the same error again, and I'm again going to > clean it out. One more time and I'll ask infra about either removing or > reimaging this node. > > On Mon, Mar 6, 2017 at

[jira] [Created] (HADOOP-13951) Precommit builds do not adequately protect against test malformed fs permissions.

Sean Busbey created HADOOP-13951: Summary: Precommit builds do not adequately protect against test malformed fs permissions. Key: HADOOP-13951 URL: https://issues.apache.org/jira/browse/HADOOP-13951

[jira] [Created] (HADOOP-13921) Remove Log4j classes from JobConf

Sean Busbey created HADOOP-13921: Summary: Remove Log4j classes from JobConf Key: HADOOP-13921 URL: https://issues.apache.org/jira/browse/HADOOP-13921 Project: Hadoop Common Issue Type

[jira] [Created] (HADOOP-13919) add integration tests for shaded client based on use by Spark

Sean Busbey created HADOOP-13919: Summary: add integration tests for shaded client based on use by Spark Key: HADOOP-13919 URL: https://issues.apache.org/jira/browse/HADOOP-13919 Project: Hadoop

[jira] [Created] (HADOOP-13920) add integration tests for shaded client based on use by Spark

Sean Busbey created HADOOP-13920: Summary: add integration tests for shaded client based on use by Spark Key: HADOOP-13920 URL: https://issues.apache.org/jira/browse/HADOOP-13920 Project: Hadoop

[jira] [Created] (HADOOP-13918) Add integration tests for shaded client based on use by HBase

Sean Busbey created HADOOP-13918: Summary: Add integration tests for shaded client based on use by HBase Key: HADOOP-13918 URL: https://issues.apache.org/jira/browse/HADOOP-13918 Project: Hadoop

[jira] [Created] (HADOOP-13917) Ensure nightly builds run the integration tests for the shaded client

Sean Busbey created HADOOP-13917: Summary: Ensure nightly builds run the integration tests for the shaded client Key: HADOOP-13917 URL: https://issues.apache.org/jira/browse/HADOOP-13917 Project

[jira] [Created] (HADOOP-13916) Document how downstream clients should make use of the new shaded client artifacts

Sean Busbey created HADOOP-13916: Summary: Document how downstream clients should make use of the new shaded client artifacts Key: HADOOP-13916 URL: https://issues.apache.org/jira/browse/HADOOP-13916

[jira] [Created] (HADOOP-13889) master build broken

Sean Busbey created HADOOP-13889: Summary: master build broken Key: HADOOP-13889 URL: https://issues.apache.org/jira/browse/HADOOP-13889 Project: Hadoop Common Issue Type: Bug

[NOTICE] breaking precommit checks

Hi folks! a host of precommit checks are currently timing out due to an update to our job configs (the timeout is currently set to 50 minutes). I'm in the process of giving things more time based on our historic usage, but if your check fails in the mean time and 1) the total run time is close

[jira] [Created] (HADOOP-13794) JSON.org license is now CatX

Sean Busbey created HADOOP-13794: Summary: JSON.org license is now CatX Key: HADOOP-13794 URL: https://issues.apache.org/jira/browse/HADOOP-13794 Project: Hadoop Common Issue Type: Bug

[jira] [Created] (HADOOP-13789) Hadoop Common includes generated test protos in both jar and test-jar

Sean Busbey created HADOOP-13789: Summary: Hadoop Common includes generated test protos in both jar and test-jar Key: HADOOP-13789 URL: https://issues.apache.org/jira/browse/HADOOP-13789 Project

[jira] [Created] (HADOOP-13780) LICENSE/NOTICE are out of date for source artifacts

Sean Busbey created HADOOP-13780: Summary: LICENSE/NOTICE are out of date for source artifacts Key: HADOOP-13780 URL: https://issues.apache.org/jira/browse/HADOOP-13780 Project: Hadoop Common

Re: Upgrading Hadoop dependencies and catching potential incompatibilities for HBase

On Wed, Sep 28, 2016 at 1:55 PM, Enis Söztutar wrote: > Can Hadoop please shade ALL of the dependencies (including PB) in Hadoop-3 > so that we do not have this mess going forward. > > Enis I'm working on this under HADOOP-11804, using HBase as my test application. --

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

It's also the key Andrew has in the project's KEYS file: http://www.apache.org/dist/hadoop/common/KEYS On Tue, Aug 30, 2016 at 4:12 PM, Andrew Wang wrote: > Hi Eric, thanks for trying this out, > > I tried this gpg command to get my key, seemed to work: > > # gpg

Re: HADOOP-13410

ServiceLoader API stuff won't load out of the unpacked version, right? On Tue, Aug 9, 2016 at 11:00 AM, Sangjin Lee wrote: > I'd like to get feedback from the community (especially those who might > remember this) on HADOOP-13410: >

Re: Jenkins Node Labelling Documentation

puppetized? On Thu, Aug 4, 2016 at 5:05 PM, Gav <gmcdon...@apache.org> wrote: > > > On Fri, Aug 5, 2016 at 7:52 AM, Sean Busbey <bus...@cloudera.com> wrote: >> >> On Thu, Aug 4, 2016 at 4:16 PM, Gav <gmcdon...@apache.org> wrote: >> > >> &

Re: Where do we track our Jenkins stuff

Okay, I'll get something together today. Thanks for the response Chris! -- Sean Busbey On Aug 6, 2016 10:48, "Chris Nauroth" <cnaur...@hortonworks.com> wrote: > Hello Sean, > > Thank you for bringing this up. The lack of response could indicate that > we’

Re: Where do we track our Jenkins stuff

Hi folks! Any response here? The notice from infra about projects needing to update for Maven and Java had a three day migration period. I'm happy to just make something up, but I want to make sure it's useful for the other person or people who currently update build stuff. -- Sean Busbey

Where do we track our Jenkins stuff

? Or is there some particular mailing list thread or a wiki page or something? -- Sean Busbey

Re: Jenkins Node Labelling Documentation

On Thu, Aug 4, 2016 at 4:16 PM, Gav <gmcdon...@apache.org> wrote: > > > On Fri, Aug 5, 2016 at 3:14 AM, Sean Busbey <bus...@cloudera.com> wrote: >> >> > Why? yahoo-not-h2 is really not required since H2 is the same as all the >> > other H* nodes. >&

Re: Jenkins Node Labelling Documentation

> Why? yahoo-not-h2 is really not required since H2 is the same as all the > other H* nodes. The yahoo-not-h2 label exists because the H2 node was misconfigured for a long time and would fail builds as a result. What label will jobs taht are currently configured to avoid H2 be migrated to? Will

[jira] [Created] (HADOOP-13463) update to Guice 4.1

Sean Busbey created HADOOP-13463: Summary: update to Guice 4.1 Key: HADOOP-13463 URL: https://issues.apache.org/jira/browse/HADOOP-13463 Project: Hadoop Common Issue Type: Improvement

[jira] [Resolved] (HADOOP-13456) Just for watching

[ https://issues.apache.org/jira/browse/HADOOP-13456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey resolved HADOOP-13456. -- Resolution: Invalid please send general questions to the user@hadoop mailing list. > J

Re: Yes/No newbie question on contributing

The current HowToContribute guide expressly tells folks that they should ensure all the tests run and pass before and after their change. Sounds like we're due for an update if the expectation is now that folks should be using -DskipTests and runs on particular modules. Maybe we could instruct

Re: Setting JIRA fix versions for 3.0.0 releases

, a >> guide about migration from 2.x to 3.x will be very helpful, and it can also >> help for people to better understand what have changed (Just like >> http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hado

Re: Setting JIRA fix versions for 3.0.0 releases

Yes, the Java API Compliance Checker allows specifying Annotations to pare down where incompatible changes happen. It was added some time ago based on feedback from the Apache HBase project. The limitations I've found are: 1) at least earlier versions only supported annotations at the class level

Re: [DISCUSS] The order of classpath isolation work and updating/shading dependencies on trunk

My work on HADOOP-11804 *only* helps processes that sit outside of YARN. :) On Fri, Jul 22, 2016 at 10:48 AM, Allen Wittenauer <a...@effectivemachines.com> wrote: > > Does any of this work actually help processes that sit outside of YARN? > >> On Jul 21, 2016, at 12:29

Re: Apache Hadoop qbt Report: trunk+JDK8 on Linux/x86

u, Jul 21, 2016 at 6:49 PM, Sean Busbey <bus...@cloudera.com> wrote: > Okay, I have something hacked together as of this build: > > https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/109 > > It's terrible, but it will get us through when infra uses puppet > a

Re: Apache Hadoop qbt Report: trunk+JDK8 on Linux/x86

, just a heads up). On Thu, Jul 21, 2016 at 4:54 PM, Akira Ajisaka <ajisa...@oss.nttdata.co.jp> wrote: > Failing jenkins job > https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/ > > -Akira > > > On 7/21/16 14:43, Sean Busbey wrote: >> >> they've

Re: Apache Hadoop qbt Report: trunk+JDK8 on Linux/x86

they've been puppetizing the Y! hosted machines, so it's probably related. Can someone point me to the exact jenkins job? I htink I fixed this for HBase once already. On Thu, Jul 21, 2016 at 3:31 PM, Allen Wittenauer wrote: > > I've already asked on builds and infra

Re: Setting JIRA fix versions for 3.0.0 releases

On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli wrote: >> I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible >> for downstreams to test incompat changes and new features without a release >> artifact. I've been doing test builds, and

Re: Setting JIRA fix versions for 3.0.0 releases

> Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still > have the issue of things committed for 2.9.0 that will be appearing for the > first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs, > it's only incrementally more work to also fix up 2.8 and other

Re: [DISCUSS] Official Docker Image at release time

Folks might want to take a look at https://issues.apache.org/jira/browse/HBASE-12721 and its associated review board posting of aggregate work. One of hte HBase community members has been creating infra (geared towards test ATM) for spinning up clusters of docker images. from what I understand,

Re: [DISCUSS] The order of classpath isolation work and updating/shading dependencies on trunk

thanks for bringing this up! big +1 on upgrading dependencies for 3.0. I have an updated patch for HADOOP-11804 ready to post this week. I've been updating HBase's master branch to try to make use of it, but could use some other reviews. On Thu, Jul 21, 2016 at 4:30 AM, Tsuyoshi Ozawa

Re: [DISCUSS] 2.6.x line releases

The HBase community would like more 2.6.z releases. On Wed, Jul 20, 2016 at 2:00 PM, Ravi Prakash wrote: > We for one are not using 2.6.* > > On Tue, Jul 19, 2016 at 1:21 PM, Sangjin Lee wrote: > >> It's been a while since we had a release on the 2.6.x

Re: [DISCUSS] Official Docker Image at release time

FWIW, there is a "blessed" apache area on docker hub now, and it's just an INFRA request to point out the needed Dockerfile in the repo. PMCs can also request write access to bintray hosting of docker images for PMC members. Info on INFRA-8441, example on INFRA-12019. A Docker image that starts

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

At the very least, I'm running through an updated shaded hadoop client this week[1] (HBase is my test application and it wandered onto some private things that broke in branch-2). And Sangjin has a good lead on an lower-short-term-cost incremental improvement for runtime isolation of apps built on

Re: hadoop-build-tools/src/main/resources/META-INF/

o include it. I'm > happy to try out more elegant solutions if you have any suggestions. > > Thanks! > > > -Xiao > > On Fri, Jun 17, 2016 at 7:34 AM, Sean Busbey <bus...@cloudera.com> wrote: >> >> If it's generated and we're following The Maven Way, it sh

Re: hadoop-build-tools/src/main/resources/META-INF/

If it's generated and we're following The Maven Way, it should be in target. probably in target/generated-sources On Fri, Jun 17, 2016 at 9:33 AM, Steve Loughran wrote: > > I see (presumably from the licensing work), that I'm now getting >

Re: ASF OS X Build Infrastructure

Some talk about the MSDN-for-committers program recently passed by on a private list. It's still active, it just changed homes within Microsoft. The info should still be in the committer repo. If something is amiss please let me know and I'll pipe up to the folks already plugged in to confirming

Re: Compatibility guidelines for toString overrides

As a downstream user of Hadoop, it would be much clearer if the toString functions included the appropriate annotations to say they're non-public, evolving, or whatever. Most downstream users of Hadoop aren't going to remember in-detail exceptions to the java API compatibility rules, once they

Re: [VOTE] Merge feature branch HADOOP-12930

+1 (non-binding) reviewed everything, filed an additional subtask for a very trivial typo in the docs. should be fine to make a full issue after close and then fix. tried merging locally, tried running through new shell tests (both with and without bats installed), tried making an example custom

[jira] [Created] (HADOOP-13129) fix typo in dynamic subcommand docs

Sean Busbey created HADOOP-13129: Summary: fix typo in dynamic subcommand docs Key: HADOOP-13129 URL: https://issues.apache.org/jira/browse/HADOOP-13129 Project: Hadoop Common Issue Type

Re: 2.7.3 release plan

On Wed, Apr 6, 2016 at 6:26 PM, Colin McCabe wrote: > In general, the only bundled native component I can see is lz4. I guess > debatably we should add tree.h to the NOTICE file as well, since it came > from BSD and is licensed under that license. > > Please keep in mind

Re: 2.7.3 release plan

. In addition, I didn't see any blocker issue to bring it into > 2.6.5 now. > Just my 2 cents. > > Thanks, > > Junping > > > From: Sean Busbey <bus...@cloudera.com> > Sent: Thursday, March 31, 2016 2:57 PM > To: h

Re: 2.7.3 release plan

A layout change in a maintenance release sounds very risky. I saw some discussion on the JIRA about those risks, but the consensus seemed to be "we'll leave it up to the 2.6 and 2.7 release managers." I thought we did RMs per release rather than per branch? No one claiming to be a release manager

  1   2   >