Reporting bugs requires too much effort

[powerman]

While I understand why you guys ask all that info just to create new bugreport… it's about too much! Some time ago I realized I'm just trying hard to avoid reporting issues on golangci-lint because it requires too much time:

1. Go download .tar.gz with binary release. Yes, just like many others I don't use binary release and install it with go install. Is binary vs non-binary difference are really that important? If yes, then maybe it's possible to somehow fix your build process to make it less important?
2. Unpack .tar.gz, make sure you're running right binary. Why don't you provide single binary file downloads, to make it possible to skip archive unpacking?
3. Check is stand-alone linter has same issue. Guess what? I don't have it, and don't wanna have it - that's why we love golangci-lint, because we don't have to spend time on dozens of different tools. So… we've several more things to do:
4. Open golangci-lint repo, find link to it's documentation, open it, find there specific linter, open linter's repo.
5. Read docs in linter's repo to find out how to install and use it.
6. Install that linter, configure, run.
7. It it doesn't have the issue: finally, check item in golangci-lint bugreport's template.
8. It it does have the issue: create bugreport for that linter instead (huh, that will be much easier!) but… now there is no easy way to know when the fix will became available not just in stand-alone linter (which, if you remember, we don't use anyway), but in golangci-lint… because there is no corresponding issue in golangci-lint repo (and if you'll open one it will be immediately closed because "it's an upstream issue" - I've tried).

And unlikely I'm the only one who feels this way. Which means you're losing bugreports because people just give up on using some feature instead asking to fix them.

Please consider making this process more user-friendly!

When I have an issue with my Linux distribution I report it in distro's bugtracker - no matter is it some tool's packaging-for-the-distro issue or just a bug in the tool itself. Even if tool has own bugtracker and this issue is already reported there - we anyway needs an issue in distro's bugtracker, because distro user's don't bother much it tool itself was already fixed, they bother is their distro has the fix (so user can have it too with ease) or not.

As you've chosen to embed dozens tools in your binary and let your users use only one tool instead of dozens - then you should take one more step further this road and let users report ALL issues they've with your tool, no matter is it actually some embedded upstream tool's issue or your tool's issue.

[powerman]

BTW, you may implement a feature to make it easier for users to test stand-alone linters: provide a command to install all such linters and example command how to run specific linter in a way matching current .golangci.yml setup.

[bombsimon]

1. Go download .tar.gz with binary release. Yes, just like many others I don't use binary release and install it with go install. Is binary vs non-binary difference are really that important? If yes, then maybe it's possible to somehow fix your build process to make it less important?

Yes and no. If you build from main/latest it is not guaranteed to work. If you build from a tagged version not so much but it can make it harder to reproduce. I don't think installing the binary version is very complex, just run

https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh \
    | sh -s -- -b /tmp/ v1.46.0

I made a small tool not too long ago to easily install multiple versions and switch between them; gclv

2. Unpack .tar.gz, make sure you're running right binary. Why don't you provide single binary file downloads, to make it possible to skip archive unpacking?

Not sure I follow, if you use the install.sh recommended way from the documentation you will get the binary unpacked without any extra steps.

3. Check is stand-alone linter has same issue. Guess what? I don't have it, and don't wanna have it - that's why we love golangci-lint, because we don't have to spend time on dozens of different tools.

This is a bit weird to me, why would anyone else that contributes to this linter for free want to download and install it? I also don't have all the linters installed locally but when troubleshooting I kinda have to install them. If the issue is with the upstream linter there's nothing anyone maintaining golangci-lint can do. And I don't see why anyone else should download and install them for you.

If the issue is reproducible with the standalone linter the one that would look into that should be the maintainer of the linter, not a maintainer of golangci-lint. Therefore, any issues that is reproducible in the standalone linter should be reported in the upstream repository and to me has nothing to do with golangci-lint. Even if we did track the issue in golangci-lint it would still require the reporter to test the standalone linter and file an upstream issue.

One thing that we (@ldez) have been working on lately is a new template when integrating a linter to golangci-lint. One bullet in that list is

• The linter should be published as a binary. (useful to diagnose bug origins)

This is to address the concerns you're talking about, having a single binary that you can download from the release page.

I also don't think the problem is as big as you describe, I've been looking into a lot of issues the last few years and in the majority of cases I would say the steps to test this would be:

go install github.com/user/linter
linter ./pkg # or ./file.go

---

I think the bug reporting process should be easy and I'll gladly work for simplifying it. But is your suggestion that you just file an issue with a linter and the maintainers of golangci-lint are the ones that will download the standalone linter, test it and file an upstream issue if it's reproducible in the standalone linter?

[powerman]

If you build from a tagged version not so much but it can make it harder to reproduce.

Tagged, of course. But in any case it'll be easy to tell which version user use from --version output:

$ go install github.com/golangci/golangci-lint/cmd/golangci-lint@master
$ golangci-lint --version
golangci-lint has version v1.46.2-0.20220512104658-86321a53d5eb built from (unknown, mod sum: "h1:QZ9B7P8eyJM0LC4WmRFUbAg2r84ral6uMZ3rhuQtq80=") on (unknown)
$ go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest
$ golangci-lint --version
golangci-lint has version v1.46.1 built from (unknown, mod sum: "h1:sc3XD0pprdZuqZkl6snUfnmUT1XW4dTTyLeOBvxn+3M=") on (unknown)

And what exactly makes it harder to reproduce than binary release?

just run

While I understand running downloaded shell script and a binary from same repo is probably same thing from security point of view I tend to avoid running such an installation shell scripts. It's okay to run them on CI, but on my main workstation - no, thanks. Shell scripts are too error-prone, tend to make wrong assumptions about my environment and as result make wrong changes on my file system.

But is your suggestion that you just file an issue with a linter and the maintainers of golangci-lint are the ones that will download the standalone linter, test it and file an upstream issue if it's reproducible in the standalone linter?

Yes. It may sounds weird or unfair to golangci-lint developers, but it makes sense if you consider my example with linux distro bugreports. The fact is: golangci-lint is so popular, so no one actually use linters you depend on. Which means all these linters should be handled more like usual library dependencies. If there is a bug in some 3rd-party library used by some tool - where people usually report issue? Right, on the tool itself. And then tool's developer report related issue on 3rd-party library, maybe even provide a PR, maybe make a fork with a fix, updates the tool, and only then close the original issue - and this signals the user he can start using fixed version of the tool. No one asks users to report on 3rd-party libraries instead.