+1
On Thu, Jun 3, 2021 at 2:14 PM 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 announcement t
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 announcement that no further regular Hadoop 3.1.x releases
will be made after 3.1.4.
(2
Thank you for your comments. I'll create a vote thread to mark 3.1.x EOL.
-Akira
On Tue, May 25, 2021 at 12:46 AM Ayush Saxena wrote:
>
> +1, to mark 3.1.x EOL.
> Apache Hive does depends on 3.1.0 as of now, but due to guave upgrade on
> branch-3.1, the attempt to migrate to latest 3.1.x didn’t
For more details, see
https://ci-hadoop.apache.org/job/hadoop-qbt-branch-2.10-java7-linux-x86_64/318/
No changes
-1 overall
The following subsystems voted -1:
asflicense hadolint mvnsite pathlen unit
The following subsystems voted -1 but
were configured to be filtered/ignored:
cc
For more details, see
https://ci-hadoop.apache.org/job/hadoop-qbt-trunk-java8-linux-x86_64/526/
[Jun 1, 2021 3:04:56 AM] (Ayush Saxena) HDFS-16051. Misspelt words in
DataXceiver.java line 881 and line 885. Contributed by Ning Sheng.
[Jun 1, 2021 3:08:13 AM] (Ayush Saxena) Revert "HDFS-15982. Del
Currently how the addendum will be added to PR??
Won’t be another PR?? Where build run again ??
On Thu, 3 Jun 2021 at 1:33 AM, Eric Badger
wrote:
> I'm of a similar opinion to most here. If the backport is clean, I think
> it's ok to do it with just the +1 on the original patch. However, plea
I'm of a similar opinion to most here. If the backport is clean, I think
it's ok to do it with just the +1 on the original patch. However, please
please please build the code on the target branch before backporting
Eric
On Wed, Jun 2, 2021 at 2:46 PM Ayush Saxena wrote:
> For trivial changes, l
For trivial changes, like changes in import or conflicts due to line number or
other trivial stuff, I don’t think that is required. Unless the general logic
isn’t changing, we can go ahead, may be we can do a test run before merging, to
be on the safer side as and when required. :-)
-Ayush
>
It is okay to go ahead and backport as long as there are no major refactoring
necessary.Minor conflict fixes should be fine.-Eric
On Tuesday, June 1, 2021, 11:43:44 PM CDT, Wei-Chiu Chuang
wrote:
I'm curious about the GitHub PR conventions we use today... say I want to
backport a commit fro
I think it comes down to "do you think somebody else needs to review it?".
I do like to test before a cherrypick -at least of all the tests which
the patch changed, and for object store stuff a full test run is good due
diligence, but I think at least for me
cherrypick no merge issues: local comp
wangzhaohui created HDFS-16053:
--
Summary: Make the way of get heartbeat interval from conf
consistent between Balancer and TestBalancer
Key: HDFS-16053
URL: https://issues.apache.org/jira/browse/HDFS-16053
11 matches
Mail list logo
