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 "CCB:Ready" label as a queue for the next set of issues and pull requests to discuss.
The following GitHub search keys are useful for finding new pull requests and issues for discussion at the CCB:
label:CCB:Ready label:CCB:FastTrack is:new is:pr is:open