• 6.8 Process
  • IDEA-1: Creating a "releases" to work on the 6.8 release and create tags from there. master is upstream and still be the main source of development.
    • PRO: Keeps a stable branch that our users can always point to without having to worry about current development.
    • CON: Possible challenges with nomenclature. Might be confusing to users "What's the difference between this and master?".
  • IDEA-2: Create a 6.8 branch and create tags from there. Delete branch when all 6.8 fixes are done. master is upstream and still be the main source of development.
    • PRO: Obvious purpose for branch. Familiar workflow since we did something similar for 6.7
    • CON: Questions about version numbering: "What do we do when we need to fix bugs?"
  • NOTE: We need to have a process for how things get into whatever branch strategy we choose.

Discussion: Pilot an approach that: 1) uses major/minor/patch identifiers, and 2) uses the git "describe" command for the build identifier (i.e., answers the question "what version of the development branch are you using") (could be done manually or a script that does it automatically on merge). Continue the discussion of implementation details in a splinter meeting.

• Use draft pull request feature as default
• Use "CCB-READY" label proactively
• If something isn't ready set it to draft status and add "WIP"
• How are you using cFS?: https://form.jotform.com/200561554287052
• GitHub project board: https://github.com/orgs/nasa/projects/4 (only accessible to cFS team members)

1. cFS Bundle PR #96
2. cFE PR #729
3. OSAL PR #487
4. PSP PR #167
5. ci_lab PR #50
6. sample_ap PR #71
7. to_lab PR #44
8. cFS-GroundSystem PR #101

1. cFS Bundle PR #102
2. cFE PR #743
3. OSAL PR #511
4. PSP PR #175
5. sample_ap PR #76
6. to_lab PR #46

• PSP PR #173 Fix #170, set exception context size.

Approved

• cFS PR #100 Fix #68, Add a reference to skeleton_app in README.md

CONGRATULATIONS on First PR!

1. cFS PR #100 Fix #68, Add a reference to skeleton_app in README.md

2. cFS-GroundSystem PR #100

Approved. Leor made reference to the "enumerate" function - more info on that available here: https://docs.python.org/3.8/library/functions.html#enumerate

3. cFE PR #738

Approved

4. PSP PR #172 Fix #169, make separate targets for PSP

5. PR #500 Fix #499, store all arguments in generic-linux BSP.

Approved

6. PR #503 Fix #502, Add extra assert macros

Approved for Fast Track (so team can start using immediately.

7. PR #504 Fix #501, add PIC library for ut assert.

Approved

8. PR #507 Fix #505, warnings in time base API test.

Approved

9. PR #508 Fix #506, enforce nonzero stack size.

Approved

10. PR #510 Fix #509, Remove uintmax_t usage.

Approved

11. PSP PR #173 Fix #170, set exception context size

Approved

12. OSAL PR #489 Fix #379, Add FileSysAddFixedMap functional API test

[P] = Present today

• Jacob Hageman (cFS Framework Lead) [P]
• Jonathan Wilmot (cFS Program Manager) [P]
• Alan Cudmore (cFS Architect) [P]
• Gerardo Cruz-Ortiz (cFS Management) [P]
• Dan Knutsen (cFS Developer) [P]
• Jay Czarnecki (Software Process Imp [P]
• Beth Timmons (GSFC Apps) [P]
• Dwaine Molock (Project Developer)
• Anhelina Yurkova (cFS Test Automation) [P]
• Leor Bleier (cFS Developer)[P]
• Olanrewaju Amoo [P]
• Jandlyn Bentley [P]
• Yasir Khan [P]
• Eric Pollack [P]

• Steve Duran (PSP, OSAL Developer)
• Ron Maglothin (Lunar CATALYST Developer)
• Allen Brown (AES Developer)
• Thomas Brain (AES Integration)
• Tam Ngo AES Lead
• Carrejo, Daniel Systems
• Schlesinger, Adam Avionics and Software
• Thad Flemming [P]

• Chris Knight (SBN Developer & Research) [P]
• Joseph (Pat) Castle
• Michael Scott
• Craig Pires

• Chris Thames (Lead/FSW Management)
• Noah Ryan (Software Developer)

• Deanna Whitehead
• Stefanie Justice
• Lisa Vanderaar (Software lead)

• Joe Hickey (cFS Developer) [P]

• Matt Grubb (SmallSat baseline, build testing)

• Chris Monaco

• Dave McComas (GSFC)