Conversation
Signed-off-by: Robert Young <robertyoungnz@gmail.com>
robobario
force-pushed
the
design-process
branch
from
ec2d412 to
5ef06be
Compare
| * Wire-protocol changes (e.g. format of encrypted data emitted by Proxy) | ||
|
|
||
| Design proposals should be submitted to the [design repository](https://github.com/kroxylicious/design). | ||
|
|
There was a problem hiding this comment.
Should the cross posting of the design proposal kroxylicious-dev@googlegroups.com be part of the process?
There was a problem hiding this comment.
Yes, please! In fact I'd advocate:
- When the PR is "Ready for Review" (i.e. it's fine to open it as a Draft a solicit feedback from individual etc, but then announce to the whole community when you're ready for feedback from the whole community)
- If we end up doing formal voting on PRs: when asking to start the vote.
- When and if the PR is accepted (i.e. merged).
tombentley
left a comment
tombentley
left a comment
There was a problem hiding this comment.
Thanks @robobario I left a few comments.
|
|
||
| Public APIs include (but are not limited to): | ||
| * Proxy configuration YAML | ||
| * Filter configuration YAML |
There was a problem hiding this comment.
I think we can generalise this from Filter to Plugin configuration. But also we should be clear that this only applies to those Plugins provided by the project ("1st party plugins" is the phrase I would use, but maybe it's worth a sentence to define it in words).
| * Proxy configuration YAML | ||
| * Filter configuration YAML | ||
| * Kubernetes CRDs | ||
| * Operator manifested resources (like public bootstrap server addresses) |
There was a problem hiding this comment.
I didn't immediately understand what you meant here. But really I think this is mostly covered by the CRD part isn't it?
The semantics you want are a bit tricky, because it's not the kube resource themselves, so much as the visible parts of them. For example, so long as the hostname, port and expected protocol of a VC didn't change we are at liberty to change how those are provided in terms of the Kube resources.
| * Kubernetes CRDs | ||
| * Operator manifested resources (like public bootstrap server addresses) | ||
| * Filter API (and other plugins) interfaces | ||
| * Wire-protocol changes (e.g. format of encrypted data emitted by Proxy) |
There was a problem hiding this comment.
Question: What about the test support maven modules? And the record tools module?
Aside: We should probably fix the split packages in those modules as part of Kroxylicious 1.0, so that we're moving towards having jars which are Java modules.
| * Changes to existing API signatures or behavior | ||
| * Removal or deprecation of APIs | ||
|
|
||
| Public APIs include (but are not limited to): |
There was a problem hiding this comment.
I need to define public API for the Kroxylicious 1.0 proposal, and it's also helpful to refer to it from a CLAUDE.md, so I think we should actually have a single source of truth as an .md in the kroxylicious/kroxylicious repo.
We should also make it an exhaustive list "Public APIs are:" not "include (but not limited to)". Otherwise it's all a bit too vague.
| * Wire-protocol changes (e.g. format of encrypted data emitted by Proxy) | ||
|
|
||
| Design proposals should be submitted to the [design repository](https://github.com/kroxylicious/design). | ||
|
|
There was a problem hiding this comment.
Yes, please! In fact I'd advocate:
- When the PR is "Ready for Review" (i.e. it's fine to open it as a Draft a solicit feedback from individual etc, but then announce to the whole community when you're ready for feedback from the whole community)
- If we end up doing formal voting on PRs: when asking to start the vote.
- When and if the PR is accepted (i.e. merged).
3 participants
We decided in our community call to require a design proposal for public API changes