Flagged RFCs
(To be approved by the DMCCB)
Planned end: Jul/31/2020
Planned end Jul/31/2020
Planned end Jul/28/2020
Planned end Jul/24/2020
Planned end Jul/24/2020
Planned end: Jun/03/2020
Planned end: Aug/31/2020
- RFC-713: it should just be a procedural thing to approve the test cases already executed
- RFC-711: no comments, the outcome seems to keep the document, but add an obsolete flag on top of it
- CCB agreed to board recommend it. Tim Jenness commented.
- RFC-710/RFC-709: Leanne is preparing the LCR. CCB should approve the RFCs before the LCR is submitted.
- DMS-REQ-0066 needs to be resurrected. GPFD to review the original text. Leanne Guy to ping GPDF
- 710 board recommend
- 709 waiting for GPDF
- RFC-708:
- to keep it open for a couple of weeks more, until the final update from P6
- RFC-699
- RFC-695
Proposed RFCs
(to review, do not require DMCCB approval)
Planned end: Aug/5/2020
Planned end: Aug/6/2020
Planned end: Aug/7/2020
Planned end: Jul/31/2020
Planned end: Jun/30/2020
Planned end: June/11/2020
Planned end: Jun/7/2021
- RFC-720: see AOB point.
- Tim Jenness baseline environment needs to be approved by the DMCCB
- see discussion RFC-537
- Kian-Tat Lim this is still valid, even if the stab packages are conda packages now
- The problem is when a pkg is added to the env, existing pkgs will change their version, in order to keep consistency in the environment.
- this pull out a set of differences that need to be approved by the DMCCB
- Kian-Tat Lim suggests that a new RFC for this is not required, since this is the result of an impact analysis
- Tim Jenness Arch team, before moving the RFC to board recommend, need to provide the changes that a new package is generating in the environment. This will permit the CCB to decide if an RFC introducing a new package can be approved or not
- DMCCB agreed to board recommend RFC-720
- John Swinbank asked if we should check if the env change breaks the external user code
- Tim Jenness no, people usually pick a weekly and stick to it for months
- Colin Slater this is acceptable if it happens not so often
- Tim Jenness due to the use of conda-forge, we can't do puctual updates
- Kian-Tat Lim the idea is to move the environment in a conda metapackage, and this probably makes possible to pin back some package in the the environemtn
- Wil O'Mullane CCB needs to be aware that somebody may be affected when other packages changes
- RFC-719, is not under the radar of the DMCCB
- RFC-718
- this requires a new Jenkins job
- RFC-712, KT to look at it
- RFC-703 to move end date to Aug30
Adopted RFCs without Triggering issues
(to create implementing DM issues)
Adopted RFCs with all triggered work COMPLETED
(to set status as 'IMPLEMENTED')
RFCs adopted since last CCB
(to review, no action required)
RFCs implemented (or withdraw) since last CCB
(to review, no action required)
Releases
- Planned
- Changes to the release schedule
- Next planned Release 21.0.0
- Tentative schedule: November 2020
Monitor Jira issues status:
- the most forgotten 10 DM issues
- (resolution = Unresolved ORDER by updated asc)
Support to J. Swinbank monitoring activity.
3905 unresolved issues (3887 on July the29th)
Preassess before the CCB starts
- DM-9418 — reassigned to Architecture team.
- DM-2351 — needs a comment from Architecture.
- DM-9469 — needs a comment from the SUIT team.
- DM-9393 — added comment.
During CCB:
- DM-9469
- Unknown User (gcomoretto) to ping Gregory to add a comment to DM-9469
- DM-2351
- Kian-Tat Lim to comment and follow up on DM-2351
John Swinbank : Should changes to the scipipe_conda_env require an RFC? My reading of RFC-537 is that they should (although that RFC has only been adopted, not implemented). Does that still hold in the new Conda regime?
discussed above with RFC-720
