release strategy for logcheck

[pohly]

/kind feature

Right now, logcheck doesn't get released "properly" (no tag, no release notes). Kubernetes imports it via the commit hash (https://github.com/kubernetes/kubernetes/blob/0ade4678a7ba527d22f6baa81034dea423267608/hack/tools/go.mod#L14).

We could:

• tag it with hack/tools/v0.1.0
• move it to a separate repo
• do nothing and keep importing it via hash

Describe the solution you'd like

According to the discussion in kubernetes/kubernetes#108725 (comment), a separate repo seems more appropriate. There is no technical reason why the tool is in klog and releases are easier when it is a stand-alone repo.

[pohly]

Jordan's preference is to move it to a separate repo.

[dims]

+1 from me (separate repo)

[RinkiyaKeDad]

I can help with this. We'd need to create a PR to https://github.com/kubernetes/org for the repo request. Are we fine with simply taking the current code and starting fresh in a new repo, that is, not preserving the commit history?

/assign

[pohly]

Let's preserve history. Git can do it and there is valuable information in the commit history that shouldn't get lost.

I would to it with "git format-patch hack/tools/logcheck", mangling paths, and "git am". There are of course other options.

[pohly]

FWIW, +1 from me for moving to a separate repo.

[pohly]

What should be the name of the new repo? Just k8s.io/logcheck and thus just one tool in that repo or k8s.io/logtools with a logcheck directory?

I can see pros and cons for both: simpler structure, shorter path and release process when using k8s.io/logcheck, more flexibility when using k8s.io/logtools.

[dims]

@pohly need to poke the sig-instrumentation leads i think as they will be the owner?

[pohly]

@RinkiyaKeDad: can you drive this, including the discussion on #sig-instrumentation regarding the repo?

[RinkiyaKeDad]

Yup, I can take care of that! Will continue this discussion about the repo name there.