The cFS CCB Process
The cFS Configuration Control Board (CCB) reviews proposed design changes on a weekly cadence. This is done by evaluating open issues and pull request that are marked with "CCB" prefixed labels.
Specifically, we ask that pull request (PR) and issue authors mark their submissions with the labels "CCB-READY" or "CCB-FASTTRACK" when they are ready to discuss the item.
The bulk of the CCB discussions focus on code review of new pull requests(PR). A PR marked with "CCB-READY" can be either finished or under development. We ask that PR authors who wish to mark things for review first request a review using GitHub's "reviewers" panel. If you don't know who to tag, visit the cFS Subject Matter Experts List to see who is better equipped to tag each repository. Though this step is not required, it usually accelerates how quickly a pull request will be merged into the codebase.
The label "CCB-FASTTRACK" is used by authors to request a pull request be merged quickly with minimal CCB review. For fast-tracked pull requests, please request a review using the GitHub interface and tag the maintainers in the cFS Subject Matter Experts List. Fast-tracked pull requests tend to be small documentation changes or urgent bug fixes needed by a stakeholder.
An issue marked as "CCB-READY" usually requires design-focused discussions with the cFS Architects and NASA stakeholders. Some examples include changes to the API, proposals for deprecation, and other proposals that change how cFS functions, is built, or deployed. Typically, issues affecting multiple components or stakeholders will be discussed at the weekly CCB meeting and then a topic-specific discussion will be scheduled later in that week.
Once a pull request has been discussed at the CCB it can be either approved, marked for changes, or assigned for discussion.
Pull request that are approved at a CCB are included in the next integration candidate cycle. The cFS bundle and each of its components has an integration-candidate branch that serves as a testing ground where things get merged before putting them on the main branch. The pull request flow happens on a weekly cadence as indicated in the diagram below.
Sometimes the CCB determines that a submitted pull request is not ready or warrants more discussion. In these cases the pull request can be
- marked with specific changes for the author to implement,
- closed and reopened with a new or different approach,
- split up into multiple pull requests to accelerate implementation of approved components,
- tagged for review by specific subject matter experts, often the architects, or
- tagged with a "splinter" label indicating that an in-depth, synchronous discussion needs to happen
cFS maintainers use the cFS framework Kanban Board (internal-only) to place issues and pull requests from across the cFS framework's repositories into the appropriate status column.
We use the "Ready for CCB" column of the cfs-framework GitHub project as a queue for the next set of issues and pull requests to discuss. Adding new items to the CCB queue often requires searching for new pull requests and issues and adding them to the "cfs-framework" GitHub project.
The following GitHub search keys are useful for finding new pull requests and issues for discussion at the CCB:
label:CCB_READY``label:CCB_FASTRACK is:new is:pr is:open
The other columns in the Kanban board represent an issue's life cycle:
Waiting for PR - Issue discussed in the CCB that does not have a related pull request
Issues being worked on - Issue discussed in the CCB that has an associated pull request
In-progress PRs - Pull requests that is in draft form and waiting for GitHub approvals
In Review - Pull requests that have been reviewed by at least one person
Ready for CCB - Issues and Pull Requests that are ready to be discussed in the next CCB
Discussed in CCB - Issues and pull requests that have just been discussed in the CCB
Integration Candidate - Pull Requests that are ready to be merged into the integration candidate
Done - Closed Issues or Pull Requests