Skip to content
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

Include common review comments in the PR template #351

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

BrieucF
Copy link
Contributor

@BrieucF BrieucF commented Jul 5, 2024

I open this PR to discuss the content of .github/PULL_REQUEST_TEMPLATE

BEGINRELEASENOTES

  • Include common review comments in the PR template

ENDRELEASENOTES

Comment on lines 1 to 8
To ease the review process, please consider the following before to open the pull request:
- is your code well commented?
- did you update the relevant README(s)? See e.g. https://github.com/key4hep/k4geo/blob/main/detector/calorimeter/README.md or https://github.com/key4hep/k4geo/blob/main/FCCee/IDEA/compact/README.md
- if you added some code, is is covered by tests? See https://github.com/key4hep/k4geo/blob/main/lcgeoTests/CMakeLists.txt
- is your PR branch up to date with origin 'main'?
- are you not adding/modifying files that should not have been added/modified (or at least, not in this PR)?

If your modifications are compliant with the above: delete thoses lines from the PR description, populate the release note text below, and open the PR!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can make this a comment block using <!-- and -->. That way the text would still show up for people if they open a PR, but it would not clutter the PR once it has been submitted, because it won't be visible. This obviously depends a bit on whether you want to make it harder to ignore or not ;)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am also not sure if PRs also have the fancy features that issues have (see, e.g. DD4hep issues)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think we can make it a comment block (it is anyway easy to ignore :-P )

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

People are going to ignore it anyway, so if we make it checkboxes, we can see from the PR overview that we can also ignore the PR!

@jmcarcell
Copy link
Contributor

Another question would be if we want the same templates for all of the Key4hep repositories or not; at least the questions in the template in this PR are quite generic and don't need to refer to the exact file in the current repository.

@BrieucF
Copy link
Contributor Author

BrieucF commented Jul 5, 2024

Another question would be if we want the same templates for all of the Key4hep repositories or not; at least the questions in the template in this PR are quite generic and don't need to refer to the exact file in the current repository.

That is a good point, what is written there is indeed very generic. The only thing is that I wanted to link the README(s) and the tests here because people might not know where they are... But ok, this is not a super strong argument, I let you guys decide

@tmadlener
Copy link
Contributor

I think (most of) the other Key4hep ones already pull theirs from the central templates. k4geo is likely a special case due to its history and the fact that it was originally in the iLCSoft organisation.

I have no strong opinion either, but as Brieuc has already pointed out two things that are somewhat k4geo specific, I would lean slightly towards keeping the dedicated template here.

.github/PULL_REQUEST_TEMPLATE Show resolved Hide resolved
@@ -1,8 +1,19 @@
<!--
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the XML comment signs?

Change everything into checkboxes?

Comment on lines +2 to +8
To ease the review process, please consider the following before to open the pull request:
- is your code well commented?
- did you update the relevant README(s)? See e.g. https://github.com/key4hep/k4geo/blob/main/detector/calorimeter/README.md or https://github.com/key4hep/k4geo/blob/main/FCCee/IDEA/compact/README.md
- if you added some code, is it covered by tests? See https://github.com/key4hep/k4geo/blob/main/lcgeoTests/CMakeLists.txt
- is your PR branch up to date with origin 'main'?
- are you not adding/modifying files that should not have been added/modified (or at least, not in this PR)?
- if you added/modified a detector geometry, have you checked that was no overlap? You can do so with the following command: ddsim --compactFile PATH_TO_COMPACT_FILE --runType run --ui.commandsInitialize "/geometry/test/run" >> overlapDump.txt
Copy link
Contributor

@andresailer andresailer Jul 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
To ease the review process, please consider the following before to open the pull request:
- is your code well commented?
- did you update the relevant README(s)? See e.g. https://github.com/key4hep/k4geo/blob/main/detector/calorimeter/README.md or https://github.com/key4hep/k4geo/blob/main/FCCee/IDEA/compact/README.md
- if you added some code, is it covered by tests? See https://github.com/key4hep/k4geo/blob/main/lcgeoTests/CMakeLists.txt
- is your PR branch up to date with origin 'main'?
- are you not adding/modifying files that should not have been added/modified (or at least, not in this PR)?
- if you added/modified a detector geometry, have you checked that was no overlap? You can do so with the following command: ddsim --compactFile PATH_TO_COMPACT_FILE --runType run --ui.commandsInitialize "/geometry/test/run" >> overlapDump.txt
To ease the review process, please consider the following before to open the pull request:
- [ ] the code is sufficiently well documented
- [ ] the relevant README(s) were updated. See e.g. https://github.com/key4hep/k4geo/blob/main/detector/calorimeter/README.md or https://github.com/key4hep/k4geo/blob/main/FCCee/IDEA/compact/README.md
- [ ] the code is covered by tests. See https://github.com/key4hep/k4geo/blob/main/test/CMakeLists.txt
- [ ] the PR source branch has been rebased (`--ff-only`) to `k4geo/main`
- [ ] the PR does not contain any additions or modifications that do not belong to it
- [ ] the changes in this PR have not introduced any overlaps. You can do so with the following command: ddsim --compactFile PATH_TO_COMPACT_FILE --runType run --ui.commandsInitialize "/geometry/test/run" >> overlapDump.txt


If your modifications are compliant with the above, populate the release note text below, and open the PR!
-->

BEGINRELEASENOTES
- Thank you for writing the text to appear in the release notes. It will show up
exactly as it appears between the two bold lines
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
exactly as it appears between the two bold lines
exactly as it appears between the two ALL CAPS lines


If your modifications are compliant with the above, populate the release note text below, and open the PR!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If your modifications are compliant with the above, populate the release note text below, and open the PR!
- [ ] The release notes below contain a succinct and comprehensive description of the changes that are sufficiently self-explanatory

@atolosadelgado
Copy link
Contributor

There is a battery of tests I do for geometries, can we add these as check boxes, at least it would be useful for ourselves as Andre suggested :)

  • overlap check (maybe increasing the number of points up to 100k or more). I think this one is already in the list
  • simulation with geantinos, 300k or more. If error is print out during navigation, one has to go back to previous point. Verbosity can be increased to catch inconsistencies
  • material scan. This one is more handmade, because one has to spot the error by oneself (that is, if you expect aluminum and the geantinos do not see aluminum, there is a problem)
  • simulation with physical particles (particle gun), which can trigger errors during navigation (as it was the case of the twisted tube)

Even with default verbosity, the amount of text printed out is too much, so I usually redirect the output to a file and then look for some keywords such as error and G4-Exception.

The tests of the simulation with physical particles and geantinos are also useful to get an idea of the speed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants