search

cilium / design-cfps

Repo to store Cilium CFP design docs
Apache License 2.0
31 stars 26 forks source link

Add maturity criteria #55

Open joestringer opened 2 months ago

joestringer commented 2 months ago

One of the things that is missing from the current CFP template and process is the notion of maturity criteria. Put simply, when should a feature be considered good enough for alpha, beta, stable status. This issue is intended to gather feedback on this aspect and how we can facilitate thought and discussion around feature maturity as part of the CFP process.

The CFP process doesn't necessarily need to encompass this - we could just publish guidelines on individual repositories and deal with feature maturity as part of the code review process. However if there is a CFP for a particular change, it would be useful to encourage designers and reviewers to consider maturity targets during the design process.

joestringer commented 2 months ago

We had a little bit of discussion about this during today's @cilium/sig-scalability discussion (notes here). One of the driving ideas is "what are 2-3 things you would want the feature to have in order to support it in a production environment?". A few brief considerations for maturity are listed below before reaching "stable":

marseel commented 2 months ago

The CFP process doesn't necessarily need to encompass this - we could just publish guidelines on individual repositories and deal with feature maturity as part of the code review process. However if there is a CFP for a particular change, it would be useful to encourage designers and reviewers to consider maturity targets during the design process.

I think it's alright to not know all criteria during initial CFP development for beta or stable status. But having this even as a placeholder in the template would encourage authors / reviewers to come back to CFP later on and fill in gaps that were discovered during the development process. This would allow us to review again at a later stage once we know more about a particular feature.

It's also a good idea to decouple it from regular code PR that marks the feature as stable, to fully reconsider what are limitations / gaps that need to be resolved. Example from K8s A similar example for CiliumEndpointSlices from Cilium: https://github.com/cilium/cilium/issues/31904 where we created "graduation" criteria later on.