+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 everyone'
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 3.1/3.2
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 kno
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 discuss
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 c
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 c
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 downl
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: Sub
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 Wed
10 matches
Mail list logo
