[WaveCalibrator] Upgrade Readiness Review

[Alex Olivas]

Things to check:
1) Changes (if any) needed to be made to support upgrade modules.
2) Is the documentation up to date?
3) Do all the example modules run?
4) What's the test coverage like? Is there room for improvement?
5) Sign up for a software call to report.

o June 12th
o June 26th
o July 10th
o July 24th
o August 7th
o August 21
o September 4th

[Alex Olivas]

Software Call Signup on Sheet2:
​https://docs.google.com/spreadsheets/d/1w7nMywL3asPPVE0eIb3K_fBIcGzDA40zAes5VyU-vIU/edit#gid=2082111224

[Alex Olivas]

It's time to start thinking about the next milestone. Going to try something new, since waiting until the code sprints to attack tickets hasn't provided the results we were hoping for.

If you're the owner of this ticket, please acknowledge you're at least receiving email updates by 'accept'ing this ticket in 3 easy steps.

1) Click "Modify Ticket"
2) Click "accept"
3) Click "Submit changes"

[Alex Olivas]

To the owner of this ticket. Signal you're aware if this ticket, by 'accept'ing it.

[Jim Braun]

This should be relatively straightforward since waveforms from upgrade DOMs will be much simpler. Changes to wavedeform will not be trivial. We need to refactor the code to build response matrices from different module types. This means we need dynamic waveform templates and specific handling routines for waveform data from each OM type.

This, along with ticket #2303, can mostly be summarized as "get pulses from Upgrade OMs working in IceTray?", including changes to dataclasses, etc. It is certainly best if one person handles all of the changes so that they're coherent. No changes should be made to the code until we precisely know the following for a given OM type:

1. The contents of the waveform data
2. The calibration information needed to use the waveform data

Changes should be made in the following order, after the above is known:

1. Write GC dataclasses to support this data
2. Modify waveform processing to handle new OM types
3. Modify gcdserver to read/write/store the calibration data needed to support this data

Come to think of it, pulse templates should probably go into the GCD database. Hard-coding the templates into dataclasses is a hack.

[Alex Olivas]

These are all moving to smartsheets 'projects'