Closed EdDev closed 6 months ago
Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all
/sig api
@EdDev: The label(s) sig/api
cannot be applied, because the repository doesn't have them.
@EdDev gentle ping
@EdDev gentle ping
I had to finish other tasks, but now I'm focus on it. Looking to finish going over all the feedback and respond today.
@EdDev gentle ping
I had to finish other tasks, but now I'm focus on it. Looking to finish going over all the feedback and respond today.
Done.
/hold
Just holding this to allow me to review this by tomorrow
/assign @alaypatel07
Let me summarize (just so I'd have all of this in a single place).
Comment still needs to be addressed:
Future tasks / things to remember:
While I think this proposal is not complete, and just the first phase of this effort, I think it's a great start and overall I'm very much for it. One again, thanks a lot @EdDev for driving this forward after my work on the subject was abandoned while I was drafted. This wouldn't be possible without you, or at least would have been dragged out for much longer. Thank you, great job!!!
/lgtm
EDIT: you're welcome to ping me for approval once you feel there's a broad agreement and everyone had a chance to raise their concerns.
While I think this proposal is not complete, […] it's a great start and overall I'm very much for it. One again, thanks a lot @EdDev
+1
Maybe somewhere we want to note: It does not have to be perfect, but better than before.
@EdDev thanks for taking this journey. Please look at converging the opern conversations, and then it seems like there is much support for this proposal.
I do think that we should look at some things async
@EdDev is the following flow correct:
flowchart LR
Start --> Design
Design -- Accepted --> Implementation
Design -- Rejected --> END
Implementation --> QAlpha
QAlpha{Requires Alpha?}
QAlpha -- Yes --> Alpha
QAlpha -- No --> QBeta
QBeta{Requires Beta?}
QBeta -- Yes --> Beta
QBeta -- No --> GA
GA --> Maintenance
Maintenance --> QDeprecation
QDeprecation{Should be deprecated?}
QDeprecation -- Yes --> Deprecation --> Removal
Maintenance & Removal --> END
END
@EdDev is the following flow correct:
Nice.
How about something like this:
flowchart LR
Start --> Design
Design -- Accepted --> Implementation
Design -- Rejected --> END
Implementation --> QGA
QGA{Requires evaluation?}
QGA -- Yes --> QAlpha
QGA -- No --> GA
QAlpha{Requires Alpha?}
QAlpha -- Yes --> Alpha
QAlpha -- No --> Beta
Alpha -- Successful --> Beta
Alpha -- Aborted --> Deprecation
Beta -- Successful --> GA
Beta -- Aborted --> Deprecation
GA --> Maintenance
Maintenance -- Exception --> Deprecation
Deprecation --> Removal
Removal --> END
Maintenance --> Maintenance
END
Nice!
Fixed some arrows and added new major api:
flowchart LR
Start --> Design
Design -- Accepted --> Implementation
Design -- Rejected --> END
Implementation --> QGA
QGA{Requires evaluation?}
QGA -- Yes --> QAlpha
Beta -- Successful --> GA
QGA -- No --> GA
QAlpha{Requires Alpha?}
QAlpha -- Yes --> Alpha
Alpha -- Successful --> Beta
QAlpha -- No --> Beta
Alpha -- Aborted --> Deprecation
Beta -- Aborted --> Deprecation
GA --> Maintenance
Maintenance -- Exception --> Deprecation
Deprecation --> Removal
Removal --> END
Maintenance --> Maintenance
Maintenance -- New Major API --> Removal
END
Approvers, where do we stand?
/lgtm
Looks like no one else is objecting besides me, so let's proceed with this. /approve
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: vladikr
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Approvers, where do we stand?
/lgtm
Aren't you an approver @fabiand ?
I am. But I was looking for a consensus and thus seeked for somebody else to approve
/hold
Just to make sure that all discussion converges.
@fabiand , do you think we have enough agreement to take this in? (we have other members & approvers lgtm it already)
I was only looking for another approver to chime in. Vladik did so, thus:
/unhold
Folks, this is dope! :)
@edDev now that you have became a writer (the doc is so detailed and long) - How do you feel about 3 things
IOW we should make sure that people start to learn about this. Specifically: FG are maturity switches, not configuration. etc
Kubevirt requires a process with a clear policy on how features are introduced, evaluated and finally graduated or dropped.
This proposal defines the steps and policies to follow in order to manage a feature (lifecycle) in Kubevirt.
This work is attempting to formalize various discussions held at different occasions in the last few years. Mostly triggered by the observation that we collect unused features and frag them for long periods with the need to maintain them in the codebase and documentation.
A previous draft version of this content has been started by @iholder101^1. It is a bit different in the format and focus, but it tried to solve the same challenge.
There has also been a fruitful discussion in the new sig-api, on several API stability topics^2, some with strong relation to the topics discussed in this proposal.
We should continue the discussion and evolve the proposal in order to agree on a formal policy. I hope to see the big picture agreed on first, letting the details follow up immediately after (not necessarily in this proposal).
The feature lifecycle can be summarized with the following flowchart: