[
https://issues.apache.org/jira/browse/YARN-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17278425#comment-17278425
]
Ahmed Hussein commented on YARN-10585:
--------------------------------------
The process to deal with those fixes is not defined in the community.
Therefore, it is done by personal styling and preference.
My point regarding the difference between reverting Vs filing-new-jira:
* Yetus analyses the code based on the diff. This means that splitting the PR
into two phases implies that the UTs and the code analysis have not been done
on the whole changes together. These are couple of 2 sample examples for such
cases:
** Take YARN-10352 which were committed with two findbugs errors. Both errors
were lost because the report expired. The followup Jira YARN-10611 that was
supposed to fix an import, shows only one findbugs report.
** Another example: if the follow-up Jira does not touch UT files, then Yetus
won't trigger the tests cases. If the follow-up fixes break the unit tests,
Yetus won't detect that leading to the merge of the broken code.
* While I agree that findbugs/checkstyles reports have a lot of
false-positives, they occasionally point out to bugs. This was the case with
YARN-10352 which breaks the Hadoop dependencies.
* In the last couple of weeks, there were at least 3 code merges with Yetus
errors, with the first one being breaking the dependencies of Guava: 1)
YARN-10352 - YARN-10611 , 2) YARN-10574 -YARN-10506 , 3) YARN-10585-
YARN-10612 .
> Create a class which can convert from legacy mapping rule format to the new
> JSON format
> ---------------------------------------------------------------------------------------
>
> Key: YARN-10585
> URL: https://issues.apache.org/jira/browse/YARN-10585
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Gergely Pollak
> Assignee: Gergely Pollak
> Priority: Major
> Fix For: 3.4.0
>
> Attachments: YARN-10585.001.patch, YARN-10585.002.patch,
> YARN-10585.003.patch
>
>
> To make transition easier we need to create tooling to support the migration
> effort. The first step is to create a class which can migrate from legacy to
> the new JSON format.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
