-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixing VID return value for HEEP Trk Iso: 11_0_X #27944
Fixing VID return value for HEEP Trk Iso: 11_0_X #27944
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-27944/11792
|
A new Pull Request was created by @Sam-Harper (Sam Harper) for master. It involves the following packages: RecoEgamma/ElectronIdentification @perrotta, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
Dear All,
This PR fixes a bug which occurred when unifying the heep & non-HEEP track isolation VID cut. While the correct value is cut upon, the returned value is incorrect and this fixes it.
Many thanks to @oglez (Oscar Gonzalez Lopez) for spotting and reporting the issue!
This bug has no impact on anything centrally run (we dont retrieve this value in any e/gamma workflow, its purely for users) so we expect zero changes. However our users may use this (and in fact do) so it needs to be fixed, also 10_6_X.
On code, there was the suggestion that the cut function should just use the result of the value function, on the face of it its a good idea however it means we have an extra dynamic cast + function call hence I kept it as is.
Best,
Sam