New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider allowing more linters #1579
Comments
I’m sorry, that attribution is incorrect; those linters have been disabled for years, and I don’t now care to track what was the default at which time. My primary point is that we are now very much diverging from the current default, which seems unintuitive — linter developers probably don’t care about utility / comprehensive coverage of our chosen set of linters, and per the examples above, quite likely to be suboptimal for this project. |
What are the list of linters, you believe we should enable? |
I have no expertise in that at all; that’s partly why this is an issue and not a PR. At this point my recommendation would be to either just switch to the default set (if we don’t have any opinion at all), or to at least enable the default set (because it’s likely enough to be useful, and if we want to be more strict, sure, why not). |
I agree, I think we need to start turning on more of the linters and starting with the default set would be great. Getting to the point that podman, buildah, common, image and storage supported the same set should be the goal. |
This was changed in #1615 , but the configuration still disables 4/7 default linters. |
#1522has disabled 5 out of the 7 default golangci-lint linters. That seems excessive.For the record, currently:
At least the “error return”, “return copies lock value”, “the cancel function returned by context.WithTimeout should be called” parts seem relevant and valuable.
The text was updated successfully, but these errors were encountered: