Re: Reviving HADOOP-7435: Making Jenkins pre-commit build work with branches

+1 If we can make things look like HBase support for precommit testing on branches (HBASE-12944), that would make it easier for new and occasional contributors who might end up working in other ecosystem projects. AFAICT, Jonathan's proposal for branch names in patch names does this. On Wed,

Re: committing HADOOP-11746 test-patch improvements

On Wed, Apr 22, 2015 at 2:10 AM, Allen Wittenauer a...@altiscale.com wrote: * There have been a few runs which seems to indicate that *something* is destroying the artifact directory in the middle of runs…. which is very very odd and something I hadn’t seen in any of my testing. In any

Re: Set minimum version of Hadoop 3 to JDK 8

A few options: * Only change the builds for master to use jdk8 * build with both jdk7 and jdk8 by copying jobs * build with both jdk7 and jdk8 using a jenkins matrix build Robert, if you'd like help with any of these please send me a ping off-list. On Tue, Apr 21, 2015 at 8:19 PM, Vinod Kumar

Re: F 6/19: Jenkins clogged up

Thanks for hte heads up. On Fri, Jun 19, 2015 at 1:43 PM, Chris Nauroth cnaur...@hortonworks.com wrote: Hi everyone, I was just in contact with Apache infrastructure. Jenkins wasn't running jobs for a while, so there is a large backlog in the queue now (over 200 jobs). Infra has fixed the

Re: Planning Hadoop 2.6.1 release

Any update on a release plan for 2.6.1? On Wed, Jun 10, 2015 at 1:25 AM, Brahma Reddy Battula brahmareddy.batt...@huawei.com wrote: HI vinod any update on this..? are we planning to give 2.6.1 Or can we make 2.7.1 as stable give..? Thanks Regards Brahma Reddy Battula

Re: Planning Hadoop 2.6.1 release

If we haven't frozen yet, HDFS-8850 is a straight forward fix that is currently only in 2.8+ and would benefit 2.6 and 2.7. On Wed, Aug 5, 2015 at 2:56 PM, Junping Du j...@hortonworks.com wrote: I would like to nominate YARN-3832 as 2.6.1 candidate which is critical and I also saw it happened

Re: IMPORTANT: automatic changelog creation

On Jul 8, 2015 2:13 AM, Tsuyoshi Ozawa oz...@apache.org wrote: +1, thanks Allen and Andrew for taking lots effort! Is there any possibility that, we can restrict someone from editing the issue in jira once its marked as closed after release? Vinay's comment looks considerable for us to

Re: continuing releases on Apache Hadoop 2.6.x

Early december would be great, presuming the RC process doesn't take too long. By then it'll already have over a month since the 2.6.2 release and I'm sure the folks contributing the 18 patches we already have in would like to see their work out there. On Fri, Nov 20, 2015 at 7:51 AM, Junping Du

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

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

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

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

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

[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

Re: [NOTICE] breaking precommit checks

Should be all set now. On Tue, Nov 8, 2016 at 5:54 PM, Sean Busbey <bus...@cloudera.com> wrote: > 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

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

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

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

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

[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

[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

[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

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

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

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