fddaq-v4.4.x Release Coordination

Wednesday 8 May 2024, 07:30 → 08:00 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.

07:30 → 08:00 Discussion

What changes do we want to get into the first patch release?

• link to the Tracking Project page
• Specific questions:
  • is the sspmodules PR planned to be included in fddaq-v4.4.1? If so, then the target branch in the PR needs to be changed to patch/fddaq-v4.4.x (and that target branch needs to be created)

When will we want to build a first patch release?

Updates:

• Marco mentioned that his daphnemodules work will likely take 3 weeks.

Reminders/questions:

• do our standard procedures include release candidates for patch releases?
• do we want prep-release/fddaq-v4.4.0 branches to be merged to production/v4 branches? (not that it matters for patch branches...)
• preliminary software area instructions for testing patch release changes are here

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

np04_v4.4.1_prep.pdf

Here are reminders of logistical details...

• 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

 

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>