On 06/11/2019 23:53, Andrew Grimberg wrote:

On 11/6/19 2:40 PM, Eric Ball wrote:

All: I'm going to abandon the previously-linked patch request, and
break it out into separate commits by project.

Robert: I've updated the Sonarcloud user permissions to match
SonarQube, where all registered users can administer issues. As for
the history import, it is not supported. We will have to leave the
history behind.

A couple of notes about this:

1) Registered users are going to be users that are logging into
SonarCloud using a GitHub account that is associated with the
OpenDaylight GitHub organization. We presently have no quick and easy
way of figuring out what those identities are so we'll have to do it on
a case by case basis right now.

Okay, so what is the process to gain access? We have the controller
being analyzed and the number of utterly false positives is not funny
and I have no way to close them down.

Two examples:

https://sonarcloud.io/project/issues?id=opendaylight_controller-sonarcloud&issues=AW6UsvtubRr7khNgdg70&open=AW6UsvtubRr7khNgdg70
is so utterly and completely wrong it's hard to describe -- target
object type is a simple enum, having no state, hence it all the points
about safe publication are utter BS in this context.

https://sonarcloud.io/project/issues?id=opendaylight_controller-sonarcloud&issues=AW6Usvo9bRr7khNgdg5r&open=AW6Usvo9bRr7khNgdg5r
is also utterly wrong -- there is even a
@SuppressFBWarnings(VO_VOLATILE_REFERENCE_TO_ARRAY) to mark that yes, we
really know what we are doing (it is a cache of the serialized form, and
no, we do not really care about double-checked loading).

Furthermore, what is the process to evolve the rule sets?

Thanks,
Robert