Location
Zoom link available on Slack channel.
(Back to the DMCCB page)
Time
From 9.00 to 09.30 PT, Wednesdays.
Attendees: Wil O'Mullane Tim Jenness Kian-Tat Lim Steve Pietrowicz Jim Bosch Leanne Guy Colin Slater Matthias Wittgen
Regrets: frossie
DMCCB Meeting Goals
- See DMCCB responsibilities listed in LDM-294 section 7.4
DMCCB Additional Resources
- #dm-ccb slack channel
Summary (AI companion zoom)
The meeting discussed the need for a reliable way to determine whether the sky was visible during observations. The current observation type cannot be trusted for auditing purposes, so there was a discussion about adding a flag or modifying the translator to ensure accurate information. There were also conversations about transferring data to France and the challenges involved. Leanne has some actions to complete, and Robert is working on the star tracker Obs package. Overall, the meeting focused on finding solutions to ensure data integrity and efficient data transfer.
Detailed AI summary
Edited to remove absolute junk .. it also added a lot of sub headings i took out (for each cell below) - also things like Rfc, 9,7,4 (we call out the numbers .. so ). start tracker → star tracker ops → obs
Observation Reason /Embargo | |
The team discussed the issue of trusting various inputs from the observation process. Tim Jenness emphasized the need for a reliable way to determine whether an observation occurred on the sky, as this information is crucial for deciding whether to send data to France or keep it in an embargo rack. The team debated the idea of creating a separate flag in the system, but it was unclear how this flag would be set and what it would indicate. The discussion ended without a clear resolution on how to ensure the trustworthiness of the observation reason. | |
The team discussed the need to set a sentinel value to fix issues with headers in pipelines. Jim proposed treating any image with this issue as broken and giving it an observation reason. K-T Lim suggested eventually handling this based on dataset type. There was also a discussion about the possibility of having images taken in both repo main and repo embargo, but K-T clarified that it doesn't have to be exclusive. Colin expressed concerns about breaking the system that gives people the data today and emphasized the need for one repository that can be reliably used. There were also comments about the French wanting the data as quickly as possible, and concerns were raised about the work involved to avoid having to SSH to USDF. | |
The team discussed a proposal from Jim about handling observation types. The core idea was to label observation types as invalid and deal with them upstream. However, the team raised concerns about the complexity of determining the number of valid observation types and the potential complications of having different data set types. They suggested alternatives such as adding a suffix to the observation type or making it a queryable field. The team agreed on the need for further discussions and potential patches to the header. | |
The team discussed the handling of data in a specific repository and the issues related to data reprocessing. They considered the options of using a flag or modifying the translator, with William emphasizing the importance of assessing the level of effort involved. The conversation also highlighted the difficulties of distinguishing between calibrations and non-calibrations, as well as between data that is on sky and data that is not. The team agreed to explore modifying the translator and extending the observation type to better track and understand the data. | |
Data Transfer Policy and Observation Handling Discussion | |
The team discussed the policy and procedure for transferring specific subsets of data. They agreed that the list of data to be transferred should be explicit and not the other way around. There was a debate about whether to transfer only data from closed shutters, but this idea was countered by the need to send calibration data. The team also discussed the potential of handling different types of observations at the translator level, provided they have policies in place to manage them. William was asked to ponder this and write a comment. | |
RFC Discussion and Client Upgrade Considerations | |
Tim Jenness, K-T Lim, Jim Bosch, Matthias Wittgen, and William O'Mullane discussed a new RFC, with a decision to wait for a Kt comment on Rfc, 974. There was also a discussion about upgrading the client format version and the potential impact on the code base. Matthias Wittgen reported issues with ??? releases and clang versions, with a suggestion not to spend too much time trying to fix the 24 build. The team agreed not to support OsX ARM on the 24 build. | |
Ticket Ownership and Action Progress | |
Tim Jenness and Leanne Guy discuss old tickets, scones, and open actions. Leanne Guy has completed two actions and is working on a new one, while Robert is currently working on the star tracker Ops package. Jim Bosch confirms that Robert considers Tim's requests reasonable, and they discuss whether Robert owns the star tracker obs package or someone else does. Tim will mark this as done until they find out who owns the last 10% of the ticket. | |
Next steps | |
• Jim will work on the proposal to make the observation type trustworthy in the translator. | |
• William will ponder the discussion about the on-sky flag and write a comment. | |
• K-T will decide whether to upgrade the client format version and comment on RFC 974. |
Discussion Items
Item | Description | CCB Notes |
---|---|---|
Flagged RFCs (To be approved by the DMCCB) |
| 958 - still awaiting Jim ? and John 976 - no activity for long time 984 - recommend 32 - unlimited may not work for some other libraries 986 - need to confirm calibs are really not on sky - so we can send to France outside embargo. Could change in translator .. but need upstream determination - translator has to work out its on sci and see obstype is wrong - need to enumerate types .. dome or camera shutter close is similar work in translator. NEED a translator policy . 987 has another week |
Board Recommended RFCs | ||
Proposed RFCs (to review, do not require DMCCB approval) | 974 - needs comment from KT .. what would change with new clang format. Devs use this not pacakges | |
Adopted RFCs without Triggering issues (to create implementing DM issues) | ||
Open LCRs | ||
Adopted RFCs with all triggered work COMPLETED (to set status as 'IMPLEMENTED') | ||
RFCs adopted since the last DMCCB (to review, no action required) |
| 26 is out 24 is stuck on arm clang .. no solution apparent .. could say arm is not available/supported for 24 - we agree on this. This coudl come back it may only coincidentally work in 25 though there are no new root builds of clang. lets not spend much time on 24 clan ARM issues.. |
RFCs implemented (or withdrawn) since the last DMCCB (to review, no action required) | ||
Releases
| v26.0.0 released | |
Monitor Jira issues status:
|
Unresolved issues: 4688 | lots of SCONs .. |
Open Actions | ||
AOB | Frossie weekly_04 ok ? | no objections |
Next DM-CCB | 2024-02-14 (2024 Feb 6-8 DM/RPF JTM & All Hands Meeting next week) |
Pending Flagged RFCs
Pending Proposed RFCs
Oldest issues
Meeting outcome
Pending DMCCB Actions
Description | Due date | Assignee | Task appears on |
---|---|---|---|
| 25 Apr 2024 | Frossie Economou | DMCCB#197 (2024 - 04 - 14) |