RFR: WIP/RFC: added ProblemLists check to jcheck

Igor Ignatyev iignatyev at openjdk.java.net
Thu Mar 19 23:53:23 UTC 2020

On Thu, 19 Mar 2020 08:21:38 GMT, Erik Helin <ehelin at openjdk.org> wrote:

>> Hi all,
>> This is more of a request for comments than an actual PR.
>> The idea behind the patch is to ensure that whenever someone fixes a bug, its ID is not used in any of the problem
>> lists. As some of you might know this is not a hypothetical issue, people forget to clean problem lists quite often,
>> which in some cases results in poorly tested patches. Although it's true that even if we ensure that all commits are
>> correct, there still will be ways to have "fixed" bugs in problem lists, e.g. closing as WNF, duplicate, etc, it's
>> nevertheless believed that the majority (or the most annoying) "violations" are caused by commits.  The proposed check
>> parses all problem lists specified by `dirs` (bar-separated list of test suites) and `pattern` (regexp pattern for
>> files withing the `dirs`) and verifies that none of the issues fixed by a patch is listed in any of problem lists. The
>> original / python-time [patch](http://cr.openjdk.java.net/~iignatyev//jcheck/problem-list/webrev.00/index.html) used a
>> list glob-pattern, but unfortunately, Java SE doesn't have a good(fast) API to find all files matching a glob, and I
>> didn't want to bring 3rd party dependency just for this use-case.  Thanks,
>> -- Igor
> Hi Igor,
> thanks for contributing ��
> We are in general very positive to bring in additional "jchecks" to upstream since they can easily be configured per
> repository. The different OpenJDK projects usually choose the checks they want enabled/disabled themselves.
> I think the check you are proposing makes a lot of sense, I've run into this scenario myself in the past. I had a brief
> look at the code, will do a more in-depth review later, but at a first glance it looks really good �� One thing that
> stands out: could you please add one or more unit tests for your new check? You can use the unit tests for other checks
> as an inspiration, please see the tests in
> [jcheck/src/test/java/org/openjdk/skara/jcheck](https://github.com/openjdk/skara/tree/master/jcheck/src/test/java/org/openjdk/skara/jcheck).
> Thanks, Erik

Hi Erik,

Thanks for your prompt response. One of the reasons I haven't written any tests for this check is that I 1st wanted to
get opinions on whether such a check will be accepted to skara/jcheck as my previous experience with jcheck.py showed
that it's near to impossible to extend it with any new checks. Another reason is that this check reads the content of
files in a repo, which AFAICT none of the existing tests do. Anyhow, I'll work on developing tests.

-- Igor


PR: https://git.openjdk.java.net/skara/pull/518

More information about the skara-dev mailing list