I recall there were at least 2 that we prefer not to enable; see https://github.com/moby/sys/blob/c9593b2d4e2ac2478a7d1e1cdaa08436a89ca079/.golangci.yml#L14-L20

Specifically QF1008 was too opinionated to apply as a general rule; see moby/sys#187 (comment)

What do you expect me to do here, just remove the FIXME part and keep the documentation part ?

Sorry, I was a bit brief, as I had to head out.

Yes, we should probably put those as "permanent" (without a "fixme"). That's not to say we won't revisit its suggestions where it makes sense, but those were a bit too opinionated to be used as a strict requirement.

As to our usual flow for these (none of this is a "hard rule", just a flow that worked well before)

• Where possible, we make the changes to make the linters happy first; usually that's in a separate PR (or a couple PR's, depending).
• Reason there is that in most cases, such fixes already apply, just that older linters may not have detected them.
• Of course there's exceptions; sometimes newer linters became more "relaxed" (so some "nolint" comments becoming redundant); those can go in together with the PR that updates the linters, if removing them ahead of time would cause CI to fail).
• 👆if there's many changes, I usually try to keep them in smaller commits (sometimes grouped by package), which can help if such changes would have to be backported to a release branch.
• If there's new rules that result in an exceptionally large number of issues; for those it may indeed be good to add a global exclude, and depending on the changes, perhaps a tracking ticket (for cases where the linter is "correct", but the issues non critical, or requiring further investigation or discussion)
• Depending on that discussion, we can decide to make an exception "permanent" (won't fix)

After the linting fixes are merged (which allows us to verify they look good, also on older linters), we can update the linters (that PR would only contain the updates required for updating the linter)

I opened #49885

what is left concerning staticcheck would be

    staticcheck:
      checks:
        - all
        - -QF1008 # Omit embedded fields from selector expression
        - -S1000  # Use plain channel send or receive instead of single-case select
        - -SA4006 # A value assigned to a variable is never read before being overwritten. Forgotten error check or dead code?
        - -SA5011 # Possible nil pointer dereference
        - -ST1000 # Incorrect or missing package comment
        - -ST1003 # Poorly chosen identifier
        - -ST1005 # Incorrectly formatted error string
        - -ST1020 # The documentation of an exported function should start with the function’s name

Looks like this one is only hit in a single location, which may be fixable, but probably fine for a follow-up (or I may have a quick look)

☝️ I'm OK with addressing this one in a follow up if I didn't find time to look at the correct patch.