search

etcd-io / etcd

Distributed reliable key-value store for the most critical data of a distributed system
https://etcd.io
Apache License 2.0
46.77k stars 9.64k forks source link

[3.4] formatting: added package comments to fix revive linter errors. #18215

Open thedtripp opened 6 days ago

thedtripp commented 6 days ago

This is meant to address the failing revive checks mentioned in this issue: https://github.com/etcd-io/etcd/issues/17472

Screenshot of Revive linter errors: image

Output with code changes: image

k8s-ci-robot commented 6 days ago

Hi @thedtripp. Thanks for your PR.

I'm waiting for a etcd-io member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
thedtripp commented 4 days ago

What are your thoughts on this PR @jmhbnz?

ivanvc commented 1 day ago

This looks good overall. I wonder if a better approach would be to add a doc.go file to the rest of the packages that don't have the module documentation. However, I also don't know if that's something we want to do for 3.4 or if we should go with the current approach. Thoughts, @jmhbnz?

ivanvc commented 1 day ago

/ok-to-test

ivanvc commented 1 day ago

/retitle [3.4] formatting: added package comments to fix revive linter errors.

jmhbnz commented 1 hour ago

This looks good overall. I wonder if a better approach would be to add a doc.go file to the rest of the packages that don't have the module documentation. However, I also don't know if that's something we want to do for 3.4 or if we should go with the current approach. Thoughts, @jmhbnz?

This decision I think is best to be made by @ahrtr and/or @serathius who are were around for much more of 3.4 development than I was. Personally I would lean towards adding missing doc.go files but that might be overkill.