+1
- Verified signatures and checksums
- Built jars and docs from source
- Built hadoop trunk with hadoop-thirdparty 1.0.0
- Checked rat files and documents
- Checked LICENSE and NOTICE files
Thanks,
Akira
On Thu, Mar 12, 2020 at 5:26 AM Vinayakumar B
wrote:
> Hi folks,
>
> Thanks to
That is unfortunately true.
Now that I recognize the impact of guava update in Hadoop 3.1/3.2, how can
we make this better for downstreamers to consume? Like I proposed, I think
a middle ground is to shade guava in hadoop-thirdparty, and include the
hadoop-thirdparty jar in the next Hadoop
Thanx Vinay for driving the release.
+1(non-binding)
Built trunk with -Dhadoop-thirdparty-protobuf.version=1.0.0
Build from source on Ubuntu 19.10
Verified source checksum.
Good Luck!!!
-Ayush
On Thu, 12 Mar 2020 at 01:56, Vinayakumar B wrote:
> Hi folks,
>
> Thanks to everyone's help on this
If you can provide ARM release for future releases, I'm fine with that.
Thanks,
Akira
On Thu, Mar 12, 2020 at 9:41 PM Brahma Reddy Battula
wrote:
> thanks Akira.
>
> Currently only problem is dedicated ARM for future RM.This i want to sort
> out like below,if you've some other,please let me
thanks Akira.
Currently only problem is dedicated ARM for future RM.This i want to sort
out like below,if you've some other,please let me know.
i) Single machine and share cred to future RM ( as we can delete keys once
release is over).
ii) Creating the jenkins project ( may be we need to
For more details, see
https://builds.apache.org/job/hadoop-qbt-branch-2.10-java7-linux-x86/622/
No changes
-1 overall
The following subsystems voted -1:
asflicense findbugs hadolint pathlen unit xml
The following subsystems voted -1 but
were configured to be filtered/ignored:
cc
Hi Brahma,
I think we cannot do any of your proposed actions.
http://www.apache.org/legal/release-policy.html#owned-controlled-hardware
> Strictly speaking, releases must be verified on hardware owned and
controlled by the committer. That means hardware the committer has physical
possession and
Hello folks,
As currently trunk will support ARM based compilation and qbt(1) is running
from several months with quite stable, hence planning to propose ARM binary
this time.
( Note : As we'll know voting will be based on the source,so this will not
issue.)
*Proposed Change:*
Currently in
Bilahari T H created HADOOP-16922:
-
Summary: ABFS: Change in User-Agent header
Key: HADOOP-16922
URL: https://issues.apache.org/jira/browse/HADOOP-16922
Project: Hadoop Common
Issue Type:
How do you manage and version such dependency upgrades in subminor
Haoop/Spark/Hive versions in Cloudera then? I would imagine that some
upgrades will be breaking for customers and can not be shipped in subminor
CDH release? Or this is in preparation for the next major/minor release of
CDH?
On
10 matches
Mail list logo
