You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@yetus.apache.org by "Nick Dimiduk (Jira)" <ji...@apache.org> on 2019/10/30 18:43:00 UTC

[jira] [Created] (YETUS-922) Precommit qualitative checks vote be -0 on overall improvement

Nick Dimiduk created YETUS-922:
----------------------------------

             Summary: Precommit qualitative checks vote be -0 on overall improvement
                 Key: YETUS-922
                 URL: https://issues.apache.org/jira/browse/YETUS-922
             Project: Yetus
          Issue Type: Improvement
          Components: Precommit
            Reporter: Nick Dimiduk


Looking at the output over on [hbase/775|https://github.com/apache/hbase/pull/775#issuecomment-547725241], I think the -1 votes on qualitative checks are a bit harsh. The tests I'm looking at are {{javac}} and {checkstyle}}, where we have a qualitative measure of change in quality. In this case, the patch improved quality by reducing the overall number of failure occurrences. I think these should be voted as -0 rather than -1. I suspect the reasoning behind the -1 vote is that the patch is viewed to have introduced new failures. The thing is, with patches that refactor code, this simple diff isn't able to distinguish between an actual new failure and a moved failure.

I could also argue that they should actually be +1 when {{total}} is less than {{previous}} because it's positive trajectory for the code base.

{noformat}
javac | hbase-server generated 1 new + 3 unchanged - 3 fixed = 4 total (was 6)
checkstyle | hbase-server: The patch generated 12 new + 270 unchanged - 37 fixed = 282 total (was 307)
{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)