@opencontainers/runc-maintainers PTAL I didn't tag a version yet, pending if we're all in agreement 😃

(I split this PR into two commits, so that we can potentially cherry-pick the first one into existing release branches).

I guess these are things we could address before tagging a release as well;

Can we have a tag?

Yes, we can, but I wanted to be sure we were all in agreement (I want this to be a "move" of a package, and not ending up with a (friendly) fork) 😅 #4017 (comment)

I didn't tag a version yet, pending if we're all in agreement

Here's what I'm proposing;

• Tag v0.1.0 with the module as-is: this tag is a straight move (no changes, other than adding what's required; go.mod etc)
• Fix things like the camel-casing (LookupUid -> LookupUID etc). Given that we'll be aliasing the functions inside libcontainer/user that change will be transparent to any consumer of libcontainer/user (but consumers should ultimately move)
• Tag those changes as v0.2.0 ?

Perhaps there's some more cleaning up to do, so I didn't want to move straight on to v1.0.0. SemVer recommendation is to start at v0.1.0 (but of course that's assuming "fresh, new code"; technically a v1.0.0 would be warranted as this code has been used in production already).

I'll have a look at the linting failures (I guess it complains because it's considering it "new code" now)

Also: I'm more than happy to add additional runc maintainers as maintainer on moby/sys, if people want to participate in maintaining that code-base (as it has modules that are common among various projects).

Tagged a v0.1.0

Thanks! I'll also have a look at fixing the CameCase nits in moby/sys (for a v0.2.0, or whatever version it will be); for this one I wanted it to be a clean "move"