From 0dfb500db2b3b8b0e93b1ac333df1a57b05224e5 Mon Sep 17 00:00:00 2001 From: Gianluca Petrillo Date: Fri, 9 Sep 2022 11:13:42 -0700 Subject: [PATCH 1/2] Adding some procedure for pull requests --- .../The_ICARUS_Guide_to_using_LArSoft.md | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/icaruscode_wiki/The_ICARUS_Guide_to_using_LArSoft.md b/icaruscode_wiki/The_ICARUS_Guide_to_using_LArSoft.md index c755e03bd..94ae02bfb 100644 --- a/icaruscode_wiki/The_ICARUS_Guide_to_using_LArSoft.md +++ b/icaruscode_wiki/The_ICARUS_Guide_to_using_LArSoft.md @@ -40,6 +40,28 @@ run and develop applications in LArSoft. The following assumes: date^[1]. +Development model +------------------ + +ICARUS code is stored and released via GitHub under the wider [`SBNSoftware`](https://github.com/SBNSoftware) "organization" (this is a GitHub term). +A pull request pattern is used to merge code into any of the repositories in SBNSoftware: +1. The requesters create a GIT branch with the modifications they wish to merge; the recommended pattern for the branch name is `feature/_`, where `` is a unique identifier of the requesters (initials, surname...) and `` identifies the content; for example: `feature/gp_trigEff` may be a "feature" branch by Gianluca Petrillo about trigger efficiency (note that when Gray Putnam entered the collaboration, he had to resort to `gputnam` not to collide with the existing name, and if Gregory Putnam decided to contribute to SBN he would need to figure out something else). +2. The requester opens a pull request for that branch into the proper repository (e.g. `icaruscode`), describing + * the purpose of the changes + * which testing was performed + * a couple (or more) collaborators that can review the request in detail + * whether the change will be "breaking", i.e. if it will change the physics output (even not significantly) + * any other information that can facilitate the review or the merge + + Note that this information will stay with the pull request and will not be visible in the repository, so it's not a very good place to store long term information (although the commit with the merge will point to the pull request, so it's still possible to recover it). +3. At least one of the reviewers will need to "approve" the request; this person may evaluate, comment or request changes on both the coding form and substance. +4. If changes are required, the requester will perform the changes or coordinate with the reviewer to find an acceptable solution. This process is iterative. +5. Once the request is finally approved, the release manager will start the integration process, which will end with the request being merged into the `develop` branch of the repository (or a production branch, if that's the purpose of the change). + +If requesters are in the `SBNSoftware` organization, they can push a "feature" branch in there. +If they are not, they can either request to join that GitHub group, or to fork the repositories into their GitHub account (`mrb g --fork` works for that), push the feature branch in there and request its pull into `SBNSoftware`. + + Brief LArSoft overview. ----------------------------------------------------------------- From accadb70c9effdeabfcf91a2a0a41123bc4e56f9 Mon Sep 17 00:00:00 2001 From: Gianluca Petrillo Date: Fri, 9 Sep 2022 11:20:21 -0700 Subject: [PATCH 2/2] Update icaruscode_wiki/The_ICARUS_Guide_to_using_LArSoft.md --- icaruscode_wiki/The_ICARUS_Guide_to_using_LArSoft.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/icaruscode_wiki/The_ICARUS_Guide_to_using_LArSoft.md b/icaruscode_wiki/The_ICARUS_Guide_to_using_LArSoft.md index 94ae02bfb..42634fded 100644 --- a/icaruscode_wiki/The_ICARUS_Guide_to_using_LArSoft.md +++ b/icaruscode_wiki/The_ICARUS_Guide_to_using_LArSoft.md @@ -56,7 +56,7 @@ A pull request pattern is used to merge code into any of the repositories in SBN Note that this information will stay with the pull request and will not be visible in the repository, so it's not a very good place to store long term information (although the commit with the merge will point to the pull request, so it's still possible to recover it). 3. At least one of the reviewers will need to "approve" the request; this person may evaluate, comment or request changes on both the coding form and substance. 4. If changes are required, the requester will perform the changes or coordinate with the reviewer to find an acceptable solution. This process is iterative. -5. Once the request is finally approved, the release manager will start the integration process, which will end with the request being merged into the `develop` branch of the repository (or a production branch, if that's the purpose of the change). +5. Once the request is finally approved, the [release manager](../AnalysisInfrastructure/ReleaseManagement/rm_main,md) will start the integration process, which will end with the request being merged into the `develop` branch of the repository (or a production branch, if that's the purpose of the change). If requesters are in the `SBNSoftware` organization, they can push a "feature" branch in there. If they are not, they can either request to join that GitHub group, or to fork the repositories into their GitHub account (`mrb g --fork` works for that), push the feature branch in there and request its pull into `SBNSoftware`.