Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: daf_butler
-
Story Points:3
-
Team:Architecture
-
Urgent?:No
Description
In recent discussions it was suggested that something like "band", "waveband" (or "energyband" – following CAOM formalism, although that is "optical" vs "radio") could be less confusing than "abstract filter". It was clear that people weren't entirely sure what "abstract" means and we get some people thinking it means a generic filter name such as "all red filters are called r" and others who think it's nothing more than a label (so "r" and "r2" and "r3" are all abstract). Gen3 is trying to use abstract filter to mean "you can probably co-add these and get a useful answer that you expect".
Consider also renaming physical_filter to just filter if we have band. Physical filter always refers to a specific piece of hardware.
If we wish to make this change to registry and butler then we should change it before we declare schema stability.
This ticket can be marked invalid if we decide against it but I need a placeholder.
Attachments
Issue Links
- mentioned in
-
Page Loading...
Activity
There are a lot of packages to review so I've added a lot of reviewers and maybe you can split things up a bit (if you see someone else has reviewed just move on to the next package).
If people feel that a s/abstract_filter/band/g only needs a cursory review then also let me know. Once this is reviewed I can work with Krzysztof Findeisen to get the ap_verify changes sorted out.
Looks good, and please merge away. But do coordinate with Krzysztof Findeisen, because the ap_verify_testdata changes do not look sufficient to me, either.
ci_hsc_gen3 and pipelines_check passed on Jenkins. I'll talk to Krzysztof Findeisen about ap_verify_testdata regeneration and will see if I can merge all these today.
Unfortunately this also broke validate_drp_gen3 which just got added to the nightly on Wednesday. It's off in another completely different organization, so I'm not pointing any fingers. I'm just requesting that I be looped in on changes like this in the future.
No objections to merging ASAP, it would surely be simpler for everyone not to have a bunch of changes floating around in limbo. Having multiple ap_verify breakages seems by far the lesser evil.