fddaq-v4.4.x Release Coordination

Thursday 2 May 2024, 07:30 → 08:30 US/Central

Kurt Biery (Fermilab), Wesley Ketchum (Fermi National Accelerator Laboratory)

Zoom:  https://fnal.zoom.us/j/92847431247

Please Note that the meeting will take place at 07:30 Chicago, 13:30 UK, and 14:30 Geneva.

Notes from the meeting:

• [Wes] wibmod changes from Roger, which patch release TBD, expect that it will be ready early next week
• [Wes] CRT, Wes and Matt Murphy working together, configuration pieces from Matt, ready for testing at NP04, working through readout issues; as complete as possible by next week, patch maybe possible by 17-May
• [Wes] needs to check with SSP folks; integration with DAPHNE controller
• [Marco] two small things with DAPHNE controller, we'll check again next week on the progress and possible ready date
• [Artur] TriggerPrimitive Fragments being saved from both readout and trigger, no plan to change this for V4, will be configurable in V5; [Michal] there are a couple of options if we want a change for v4.x
  • [Alessandro] it is important to be able to check both ends of the pipe (readout and trigger), it is also important to be able to tell them apart
  • [Artur] reminder that it would be good to check with a wide-ish audience regarding any changes here
  • [Michal and Kurt] our belief is that the readout TP fragments have sourceID 0-N-1, trigger TP fragments have N to 2N-1.
• [Artur] a number of other trigger changes are expected; one change is on the latency side, measuring latencies in trgtools and live, patch possible next week or week after;  another change:  expanding replay and other tools to handle multiple RUs;  CTB and CIB work.
  • [Michal] software dev and Grafana plot changes, <= 1 week
  • [Michal] how we deal with TC types...  grouping of related types, some gaps to allow for future additions (trgdataformats plus other repos?)  [Wes] we should check with offline  [Josh] reminder that offline may not use the trigger_type bits strictly (or at all?)  [Alessandro] agrees with sentiment that it may be a little close to the run to change this [Artur] TC types and trigger bits will be overhauled in V5
• [Wes] cryostat full, purification starting over the weekend; we are running with TPs being written out
• [Stoyan]  PDS has asked for additional lfunctionlty to confiugrat the timing master via run control, not clear when, maybe not urgent.
• [Kurt] couple of changes in hdf5libs
• [John] rawdatautils needs a dependency on detchannelmaps; otherwise data quality checker script doesn't work
• [Wes] DQM meeting later today, resuming DQM work, in dev software areas initialy, will want to  apture changes around the end of the month, dqmtoolsl and justintime, some core repos possible too
• [Ivana] TPG changes from recent testing already went in.  investigations ongoing
• [Artur] split of TPG configuration per plane - will this go into v4?  [Alex] working on this, more challenging than expected, timeline not yet clear (desireable to get in...)
• [Pierre] couple of minor things in nanorc
• [Josh] how to handle urgent changes that become obvious once NP04 running starts  [Wes] in short terms, we can run out of development areas
• K8s - not obvious that testing this along with detector chagnes is a good choice, maybe focus on monitoring runs for K8s use
• [Matthew Man, Danaisis]  Good for nP04, testing focussed on Np02

 

Notes for specific patch releases?

• fddaq-v4.4.1
  • when?
  • with what changes?
• fddaq-v4.4.2?
  • when?
  • with what changes?

 

07:30 → 08:00 Discussion

What changes might be ready when?

Questions about logistics for the patch releases?

Operational issues?

Speakers: Kurt Biery (Fermilab), Wesley Ketchum (Fermi National Accelerator Laboratory)

Here are the elements of the plan:

• additional releases in the 4.x line of development will be patch releases on top of fddaq-v4.4.0
• developers should use the standard workflow for patch branches when preparing any additional code changes (see the “patch branch” subsection of the development workflow document here).  I’ve included sample steps below.
• Pull Requests should have their target branch set to patch/fddaq-v4.4.x, and PRs should be tested, reviewed, and approved normally.  However, we ask that PRs do not get merged until they are discussed in a Release Coordination meeting.  This will allow us to have good control and understand of what gets included in each patch release.
• Pull Requests should have their Target Release set to fddaq-v4.4.x.  (Target Release is a Tracking Project field.)  We will use this field to help coordinate what gets included in each patch release, and we will change its value to a particular patch release version when we decide which patch release the change should be included in.
• if you are making correlated changes in multiple repositories, we suggest that you use the same feature branch name in all of the repositories.  This will help us keep track of such groups of changes.
• we expect to have Release Coordination meetings at least once per week with the first one tentatively scheduled for Thursday, 02-May.  I’ll send a separate email announcing this meeting.

 

 

Here are sample steps for creating and using the appropriate patch branches in GitHub:

• <clone a copy of the desired repo; cd into the resulting directory>
• # if the patch/v4.4.x branch doesn’t already exist
  • git checkout fddaq-v4.4.0 # for FD packages, or ‘git checkout coredaq-v4.5.0’ for core software packages
  • git checkout -b patch/fddaq-v4.4.x
  • git push origin patch/fddaq-v4.4.x
• # if the patch/v4.4.x branch does already exist
  • git checkout patch/fddaq-v4.4.x
• git checkout -b <name of your feature branch>
• <modify code, commit changes>
• git push origin <name of your feature branch>