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 be
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.
> So
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 de
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
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
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.
>
>
> Ube
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 downstream
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
volunteeri
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 extend
+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 announceme
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
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 writ
[
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
t;
>> <https://lists.apache.org/thread.html/7813c2f8a49b1d1e7655dad180f2d915a280b2f4d562cfe981e1dd4e%401406489966%40%3Ccommon-dev.hadoop.apache.org%3E>>>;
>> > -
>> >
>> https://lists.apache.org/thread.html/3e1785cbbe14dcab9bb970fa0f534811cfe00795a8cd1100580f27
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 enfor
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 nightl
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 precom
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 abandone
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 folks
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
+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
> https://lists.apache.org/thread.html/e49d60b2e0e021206e22bb
+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 your
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 tha
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, 20
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 proje
st part that works 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
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 unsu
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
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
-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 toolin
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 Ke
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 with
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". There'll
apologies, copying back in common-dev@ with my question about the code.
On Tue, May 15, 2018 at 2:36 PM, Sean Busbey wrote:
> > Internal constraints prevented this feature from being developed in
> Apache, so we want to ensure that all the code is discussed, maintainable,
> and d
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, it seems that now jira
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 we have any solid evid
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,
> Akira
>
>
> On 2017/
his 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 wrote:
>
>> When Apache Yetus formed, it started with s
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 Y
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 commit process which
> says "
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
> 57bcaa1219fb9ad985f8750ba1@%3Cdev.yetus.apache.org%3E
>
> I unfortunately don
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 invest some time into integrating the HBase
> > fla
e L just notice the
break before we could finish the 10 hours it takes to get qbt done?
How solid would qbt have to be for us to do something drastic like
auto-revert changes after a failure?
On Thu, Sep 14, 2017 at 11:05 AM, Allen Wittenauer wrote:
>
> > On Sep 14, 2017, at 8:03 AM, S
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 app
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
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
GPLv
-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 grab the .gitignore file fro
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
our
>> products (source code releases),
>> > then this is an acceptable usage.
>> >
>> > Cheers,
>> > Chris
>>
>>
>> So I think we are in the clear with respect to zstd usage as long as we
>> keep it as an optional codec where the
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
wrote:
>
>
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 commit hash since it was recor
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
On Wed, Mar 8, 2017 at 2:04 PM, Allen Wittenauer
wrote:
>
>> On Mar 8, 2017, at 9:34 AM, Sean Busbey wrote:
>>
>> Is this HADOOP-13951?
>
> Almost certainly. Here's the run that broke it again:
>
> https://builds.apache.org/job/PreCommit-HDFS-Build
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 2:12 PM, Allen Wittenauer
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
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
[
https://issues.apache.org/jira/browse/HADOOP-13920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey resolved HADOOP-13920.
--
Resolution: Duplicate
Assignee: (was: Sean Busbey)
> add integration tests
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
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
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
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
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
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
Should be all set now.
On Tue, Nov 8, 2016 at 5:54 PM, Sean Busbey 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 giving things
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 t
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
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
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
/apache/hadoop/tree/release-2.7.1> does exist
>
>
>
> On Mon, Oct 24, 2016 at 6:49 PM, Sean Busbey wrote:
>>
>> here they are:
>>
>>
>> https://git1-us-west.apache.org/repos/asf?p=hadoop.git;a=tag;h=refs/tags/rel/release-2.7.2
>>
>>
>>
here they are:
https://git1-us-west.apache.org/repos/asf?p=hadoop.git;a=tag;h=refs/tags/rel/release-2.7.2
https://git1-us-west.apache.org/repos/asf?p=hadoop.git;a=tag;h=refs/tags/rel/release-2.7.3
On Mon, Oct 24, 2016 at 9:00 AM, Lars Francke wrote:
> Hi,
>
> it looks like the tags for releases
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.
--
busbey
-
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 --keyserver pgp.mit.edu --recv
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:
> https://issues.apache.org/jira/browse/HADOOP-13410
>
> It appear
have
been puppetized?
On Thu, Aug 4, 2016 at 5:05 PM, Gav wrote:
>
>
> On Fri, Aug 5, 2016 at 7:52 AM, Sean Busbey wrote:
>>
>> On Thu, Aug 4, 2016 at 4:16 PM, Gav wrote:
>> >
>> >
>> > On Fri, Aug 5, 2016 at 3:14 AM, Sean Busbey wrote:
>> >
Okay, I'll get something together today.
Thanks for the response Chris!
--
Sean Busbey
On Aug 6, 2016 10:48, "Chris Nauroth" wrote:
> Hello Sean,
>
> Thank you for bringing this up. The lack of response could indicate that
> we’re not doing enough recently to main
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
there some
particular mailing list thread or a wiki page or something?
--
Sean Busbey
On Thu, Aug 4, 2016 at 4:16 PM, Gav wrote:
>
>
> On Fri, Aug 5, 2016 at 3:14 AM, Sean Busbey wrote:
>>
>> > 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
> 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
t
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
[
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
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 fol
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_Hadoop2.html)
>>
>> Thoughts?
>>
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
My work on HADOOP-11804 *only* helps processes that sit outside of YARN. :)
On Fri, Jul 22, 2016 at 10:48 AM, Allen Wittenauer
wrote:
>
> Does any of this work actually help processes that sit outside of YARN?
>
>> On Jul 21, 2016, at 12:29 PM, Sean Busbey wrote:
>>
>&g
On Thu, Jul 21, 2016 at 6:49 PM, Sean Busbey 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
> across the H* hosts
jobs, just a heads up).
On Thu, Jul 21, 2016 at 4:54 PM, Akira Ajisaka
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 been puppetizing the Y! h
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 if it was related to some othe
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 branch-3.0.0-alpha1 is ready
> 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 unrel
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, r
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 wrote:
> H
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 line. Is it time to
>> get ready for a 2.6.
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
Sean Busbey created HADOOP-13348:
Summary: delete spurious 'master' branch
Key: HADOOP-13348
URL: https://issues.apache.org/jira/browse/HADOOP-13348
Project: Hadoop Common
Issue
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
ces, but couldn't get the plugin to 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 wrote:
>>
>> If it's generated and we're following The
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
> hadoop-build-tools/src/main/resources/META-INF/ as an u
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 it
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 see
1 - 100 of 199 matches
Mail list logo