Attendees: Chris Jones, Erica Snider, Tom Junk, Herb Greenlee, Katherine Lato, Tracy Usher (in a follow on meeting)

Chris Jones shared information on GitHub – The current  way of operating is unsustainable as more experiments start taking data and need to closely manage their production LArSoft releases. So we asked Chris to share his experience in CMS with GitHub and the use of pull requests to manage code integration. His slides are available at CMS GitHub Usage for LArSoft. A zoom recording of his presentation is available upon private request.

The discussion included extensive details on the CMS-specific infrastructure used to support that system, and how elements could be adapted to the LArSoft community. Differences between how such a system might be used in single-experiment versus a multi-experiment collaboration were examined, along with various strategies for deploying the system. A significant finding was that the CMS system was initially deployed with relatively little supporting infrastructure. Despite this, Chris believed the system gained widespread approval quickly, due in part to the ease of using the tools provided by GitHub. This then led to a rapid and organic growth of tools that in time produced the current, highly sophisticated system. It is unclear how much, if any of the existing CMS code could be used or adapted to a non-CMS system.

In the CMS pull request system, there are three roles defined:  developers, reviewer and release managers. Most of the positions have at least two people in them. In CMS, people are adding comments because it’s easy. They didn’t expect this, but it happened. They built seven releases. Testing lots of things. ROOT, GEANT. They are a continuous integration machine. This presentation provided useful background.

• Update on LArSoft items
  • Progress on event display technology evaluation. Seeking input from community
    • Go over the four options + evaluation categories / criteria
    • Option A. Web browser-based system, three.js
    • Option B. Custom application
    • Option C. Vtk-based application
    • Option D. TEve-based application
    • Criteria — https://cdcvs.fnal.gov/redmine/issues/19037
      • Some of these solutions don’t directly talk to LArSoft. Instead, they read and interpret art-root files directly. We would prefer something that talks directly to LArSoft.
      • Lack of documentation on TEve will make it difficult to use.
  • Overlay workshop is on March 4th. Details are: here 
  • Experiments learning to build their own patch releases of LArSoft
    • Noted that MicroBooNE has asked for a new patch release, and is expected to ask for another by the end of the week
    • LArSoft team has limited capacity for creating releases, so tight production schedules will be difficult to manage, particularly with multiple experiments taking data. Experiments should expand their current release manager roles to include creation of LArSoft patch releases for production.
    • No major objections raised
  • Genie v3 status:  MicroBooNE has performed detailed validation, has patches for Genie, working to integrate it into MCC9 patch release
    • LArSoft team wants all experiments to be using v3 at the same time, if possible
    • Need input from DUNE on their plans asap
    • Will try to share the validation results from MicroBooNE, since nothing there was actually specific to MicroBooNE
• Round robin discussion
  • MicroBooNE
    • No issues to discuss
  • DUNE
    • The longer DUNE takes, the more prototypes we’ll have. ICEBERG is one of them.
    • Has been working mostly on GArSoft and ICEBERG recently
    • Happier with LArSoft than with dunetpc. Need to break that into smaller chunks

Please email Katherine Lato or Erica Snider for any corrections or additions to these notes.