bot-vitess[bot]
commented
1 year ago Review Checklist
Hello reviewers! :wave: Please follow this checklist when reviewing this Pull Request.
General
- [x] Ensure that the Pull Request has a descriptive title.
- [x] If this is a change that users need to know about, please apply the
release notes (needs details)label so that merging is blocked unless the summary release notes document is included. - [x] If a test is added or modified, there should be a documentation on top of the test to explain what the expected behavior is what the test does.
If a new flag is being introduced:
- [ ] Is it really necessary to add this flag?
- [ ] Flag names should be clear and intuitive (as far as possible)
- [ ] Help text should be descriptive.
- [ ] Flag names should use dashes (
-) as word separators rather than underscores (_).
If a workflow is added or modified:
- [ ] Each item in
Jobsshould be named in order to mark it asrequired. - [ ] If the workflow should be required, the maintainer team should be notified.
Bug fixes
- [ ] There should be at least one unit or end-to-end test.
- [ ] The Pull Request description should include a link to an issue that describes the bug.
Non-trivial changes
- [ ] There should be some code comments as to why things are implemented the way they are.
New/Existing features
- [ ] Should be documented, either by modifying the existing documentation or creating new documentation.
- [ ] New features should have a link to a feature request issue or an RFC that documents the use cases, corner cases and test cases.
Backward compatibility
- [ ] Protobuf changes should be wire-compatible.
- [ ] Changes to
_vttables and RPCs need to be backward compatible. - [ ]
vtctlcommand output order should be stable andawk-able. - [ ] RPC changes should be compatible with vitess-operator
- [ ] If a flag is removed, then it should also be removed from VTop, if used there.
netlify[bot]
Documenting the changes in https://github.com/vitessio/vitess/pull/12963