edmCheckMultithreading: check for non multithreading-compliant modules

[fwyzard]

Check if the modules used by the CONFIG python file are legacy,
global, stream or one modules, and if they implement the
fillDescriptions() method.

[fwyzard]

@Martin-Grunewald , @perrotta , here is the script to check if any modules used by a CMSSW python configuration are multithreading-friendly or not.

[cmsbuild]

A new Pull Request was created by @fwyzard (Andrea Bocci) for CMSSW_7_4_X.

edmCheckMultithreading: check for non multithreading-compliant modules

It involves the following packages:

FWCore/Utilities

@cmsbuild, @smuzaffar, @Dr15Jones can you please review it and eventually sign? Thanks.
@makortel, @Martin-Grunewald, @wddgit, @wmtan this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
If you are a L2 or a release manager you can ask for tests by saying 'please test' in the first line of a comment.
@Degano you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[Martin-Grunewald]

Great, but what is the difference to CMSSW/​HLTrigger/​Tools/​scripts/​cmsCheckMultithreading ?
Will it now run for each PR automatically? With a warning for fillDescription, and an error
for non-MT?

[fwyzard]

please test

[fwyzard]

though it just adds a new script, so it's very unlikely to break anything...

[cmsbuild]

The tests are being triggered in jenkins.

[fwyzard]

Great, but what is the difference to CMSSW/​HLTrigger/​Tools/​scripts/​cmsCheckMultithreading ?
Will it now run for each PR automatically? With a warning for fillDescription, and an error
for non-MT?

That's something I forgot putting there... and it's likely an older version, which was breaking when looking for the package where each module is defined.

And the new one has colours, too :-)

Anyway, no, it's not automatically run, it's something we should add to hltIntegrationTest, but I would do that only after this PR is merged.

[cmsbuild]

+1
Tested at: 894081e
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-11241/8044/summary.html

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-11241/8044/summary.html

[Dr15Jones]

Why was a backport needed?

[fwyzard]

because HLT will stay with CMSSW 7.4.x for the rest of the year (at least for pp collisions), and I would like to add this to the standard checks that we request from the developers

[Dr15Jones]

+1

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_4_X IBs once checked with relvals in the development release cycle of CMSSW (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar

[davidlange6]

+1