Codify the expectations for the OpenShift development phases - #2070
Codify the expectations for the OpenShift development phases#2070dgoodwin wants to merge 4 commits into
Conversation
dgoodwin
changed the title
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: openshift/coderabbit/.coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughAdds a development phases guide with rules for feature gating, approvals, stabilization, deferral, and post-GA backports. The feature implementation guide links to this document before implementation begins. ChangesDevelopment guidance
Estimated code review effort: 1 (Trivial) | ~3 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@dev-guide/development-phases.md`:
- Around line 8-10: Update the prose around “historical,” “last minute,” and
“long standing” to use the hyphenated compound modifiers “well-documented,”
“last-minute,” and “long-standing”; also hyphenate any relevant “release
blocking” usage as “release-blocking.”
🪄 Autofix (Beta)
❌ Autofix failed (check again to retry)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: d19b2c49-40fd-465f-9775-9169731bdccd
📒 Files selected for processing (2)
dev-guide/development-phases.mddev-guide/feature-zero-to-hero.md
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. An unexpected error occurred while generating fixes: Not Found - https://docs.github.com/rest/git/refs#get-a-reference |
|
/lgtm |
|
Changes here LGTM, one possible improvement would be to link out to documentation on the SBAR process, what's our best source of guidance on SBAR? I also note that this is on the agenda for today's arch call, lets hold of merging until we have discussed there |
openshift-ci
Bot
added
the
do-not-merge/hold
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
|
||
| ## Guidelines | ||
|
|
||
| NOTE: See [How to file an SBAR](https://docs.google.com/document/d/1-Lq4p7KhHRUFhkhpZ1ntDOcvDZgj9YVIBOmLSRlNkq0/edit?usp=sharing) and the template linked within if you need to file an SBAR per the guidelines below. |
There was a problem hiding this comment.
A link to OpenShift schedule would be helpful too. The official one for 5.0 is at https://productpages.redhat.com/openshift-5.0/schedule/tasks/ (internal only).
And most importantly, sync the schedule items with the description here. For example, the schedule shows "Stabilization for 5.0 Fri 2026-08-21 - Fri 2026-10-23", but it's a different kind of stabilization than described here. We apparently have two stabilization phases now.
There was a problem hiding this comment.
I would rather not make this document release specific, and lets defer on-going complaints about the second naming caused by the complaints about the first naming until a later date and see if it's actually causing problems. From my PoV we can just assume it's primarily all stabilization after the first stabilization date. (unless you're behind a feature gate, or have an exception)
| | Phase | Development | Stabilization | Post-Branching / Feature Freeze | Post GA | | ||
| | :--- | :--- | :--- | :--- | :--- | | ||
| | **Focus** | Ranked/prioritized feature development.<br>Getting features to done and limiting WIP.<br>Relatively rapid response to regressions. | Bug fixes, stabilizing CI.<br>Landing release blocking features, if possible.<br>Exercising caution on anything merging at this time.<br>Ack critical fixes or staff eng approved label requirements may be turned on if CI is struggling. | Bug fixes.<br>Ack critical fixes may be turned on if the pending release blocking bug count is too high, to allow for fixes to land smoothly for backporting.<br>Proceed with feature work for next release, avoid getting anchored to prior whenever possible. | Bug fixes.<br>Minimal backporting of feature gates and promotion for features that nearly made it in for GA.<br>Proceed with feature work for next release, avoid getting anchored to prior whenever possible. | | ||
| | **Gated Release Blocking Features** | Can merge and promote per normal processes. | Can merge code and [promote via normal processes](https://github.com/openshift/enhancements/blob/master/dev-guide/featuresets.md#id-like-to-declare-a-feature-accessible-by-default--what-is-the-process).<br>Promotion requires additional approval from an OCP architect. No SBAR required.<br>Logically impossible gaps in test coverage can be approved by API reviewers/architects.<br>Any other gaps in testing require an SBAR. | SBAR required to promote. | Can pursue a backport to land in an early z-stream release:<br>SBAR required, submitted once release is GA and feature is promoted to default in main.<br>Wait for SBAR approval before beginning backporting work. | |
There was a problem hiding this comment.
Can merge and promote per normal processes.
Please link the process. I can see it's linked in some other cells.
There was a problem hiding this comment.
Moved to a central links section above.
There was a problem hiding this comment.
@jsafrane we could potentially get the schedule changed such that the stabilization phase here (the part before branching) is called one thing while the time from branch to final GA build another.
Maybe rough timelines at the top would help?
Development (4-6 three week sprints)
Stabilization (2-3 weeks)
Post-Branching / Feature Freeze (3-6 weeks)
Post GA (forever!!!)
|
@dgoodwin: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
/lgtm I appreciate Jan's feedback and agree we should make sure that this aligns with the terminology used in the schedule. I don't care which way we go, either the names from here into the schedule or the names from the schedule updated here. But the phases and attributes of the phases seem correct to me. |
5 participants
Summary by CodeRabbit