Just discovered this ticket. Should it be part of the gen3-middleware work? I'm not sure how we can do DM-21915 without it. (Though I also don't understand why DM-21862 is unrelated.)

Yes, this is a blocker on using decam data for testing.

I think Jim Bosch didn't remember that I'd filed this when he filed DM-21862: this ticket is one component of 21862 (which I think should be a small epic, but whatever).

AFAIK we're all free to break up these tickets if we think it makes sense.

.  I have been using blocker umbrella tickets instead of Epics just because Epics can have special meaning for T/CAMs and special rules about Team assignments in some contexts and I didn't want to stomp on any of that.

Jenkins run:
https://ci.lsst.codes/blue/organizations/jenkins/stack-os-matrix/detail/stack-os-matrix/30899/pipeline

I've had a look at the branches on this ticket and I can try to see if I can rescue them. It seems to me that we are using the term "instrument signature data" rather than "curated calibrations" – can someone explain whether these are different or the same? Is "instrument signature data" a superset of curated calibrations? We have started to call "curated calibrations" the standardized calibrations that live in the obs_x_data packages. Should writeCuratedCalibrations be renamed to writeInstrumentSignatureData?

The obs_lsst branch removes gen3 from the module hierarchy. If we are going to do that then sooner rather than later is better before we start embedding the class name everywhere? Jim Bosch I assume you don't mind if we drop gen3. Also, do we want to use the Task infrastructure for running writeCuratedCalibrations or is a simple command that becomes part of the unified command line tools fine? Is any configuration needed other than specifying the instrument and (possibly) collection?

John Swinbank From an earned value perspective, since I'm not on AP and haven't already spent a lot of time on this ticket, should I do the work on a different ticket (DM-23976) that I thought I would be working on anyhow?

I started the "curated calibrations" -> "instrument signature data" rename because nobody had provided a definition of "curated calibrations" and the things we referred to by that name are the things that go into instrument signature removal. `writeCuratedCalibrations` would be renamed `writeInstrumentSignatureData`, yes.

Jim Bosch and I had agreed to remove the `gen3` hierarchy from things as soon as we could. It should also get pulled from HSC.

We should also decide on a coherent set of names for Instrument classes: are they `BlahCameraInstrument` or just `BlahCamera`? I don't know how much it matters, but the time to standardize is now.

From a pure EV perspective, yes, if this work is being handed off from AP to Architecture, let's do that by writing a brief summary of what happened on this ticket, marking it as done, and then using another ticket for Arch activities. (It's not obvious from the description here whether that other ticket is DM-23976, but I have no horse in that race.)

I think I will put renaming of instrument classes (removal of gen3) onto a new ticket since it doesn't affect any of the other discussions. I absolutely agree that now is the time to change names and class paths.

DM-23980 has been created for the instrument class renames.

Should we close this as either `Invalid` or `Done`, given DM-23976?

DM-23976 has implemented writeCuratedCalibrations for obs_decam, so defects and camera are now taken care of. DM-23980 took care of removing the `gen3` bit from the module hierarchies. The other cleanups and renames on this ticket are probably not worth trying to sort out in what would likely be an ugly rebase, and many of them depend on the not yet finished plan for how calibrations will be handled in general.

I will close the four PRs on this ticket, and am marking the ticket as "done" because at least defects are now being managed per the ticket description.