Kevin Burke

Here's when I downloaded the "wrong" checksum ``` $ cat /Users/kevinburke/pkg/mod/cache/download/github.com/argoproj/argo-rollouts/@v/v1.2.0.info {"Version":"v1.2.0","Time":"2022-03-21T20:45:35Z"} ``` Here's the contents of sum.golang.org ``` $ curl https://sum.golang.org/lookup/github.com/argoproj/[email protected] 9679416 github.com/argoproj/argo-rollouts v1.2.0 h1:3CxEe2tyeZd9I6qWQo7RUAYyGb3qAnXo4SgSVBJBEBs= github.com/argoproj/argo-rollouts v1.2.0/go.mod h1:k4e3rCEMfta7WfJvOmkSHsPhqq2IqfUf8swth+pTQ+E= go.sum...

Aha, I figured it out - the module in proxy.golang.org works fine but the contents behind the proxy - ie if you do GOPROXY=direct - do not match up.

Sorry - what I'm trying to tell you is the contents in the proxy don't match what's on Github. That indicates that the tag contents were changed at some point....

Here's the diff I see between what's available for download from proxy.golang.org and what's available if I check out v1.2.0 of the source directly, with these commands (which Go runs):...

It also looks like there were two different CI builds (for two different commits) attempted for v1.2.0, and I am guessing for v1.2.1 as well https://github.com/argoproj/argo-rollouts/runs/5634127235?check_suite_focus=true https://github.com/argoproj/argo-rollouts/runs/5634458780?check_suite_focus=true

FYI I get the same issue when I try to download v1.2.1 ``` $ GO111MODULE=on GOPROXY=direct go mod download github.com/argoproj/[email protected] go: github.com/argoproj/[email protected]: verifying module: checksum mismatch downloaded: h1:8txnRKukYXvWMlLRQ4biixj9FdrLEGECyrW2eFsLTyc= sum.golang.org: h1:4hSgKEqpQsZreZBv+XcLsB+oBaRGMVW19nMScx5ikIQ=...

Hey, just wondering if there's any chance you could tag a new release, even tagging 1.2.2 to point at the same commit that is currently present in proxy.golang.org would be...

Is it worth using https://github.com/orijtech/structslop to optimize the order that we put the fields in each struct? > the parquet spec does not mention it unfortunately Can we open a...

Is []byte the best type to represent a bitmap? Otherwise looks good.

This all sounds reasonable. I don't know. I guess just to me the `...Option` style is too much overhead when all we're doing is setting single properties on a configuration...