ADMIN: change maintainers of the libseccomp-golang project

[pcmoore]

With @mheon stepping down (see this comment in PR #35) let's shift maintenance of the the libseccomp golang bindings to @drakenclimber and myself. The checklist below is a work in progress (expect it to be edited while this issue remains open) but should be used to guide this work.

Work Items:

• Ensure @drakenclimber and @pcmoore have the appropriate repo permissions on GitHub
• Remove @mheon's write permissions
• Convert README to Markdown
• Convert SUBMITTING_PATCHES to Markdown and rename to CONTRIBUTING.md
• Add a SECURITY.md guidance doc
• Add a doc/admin/MAINTAINER_PROCESS.md guidance doc
• Add a doc/admin/RELEASE_PROCESS.md guidance doc. Add a step to ensure the test matrix is updated.
• Triage all outstanding issues and PRs (ensure proper labeling, status, etc.)
• Add @kolyshkin as a libseccomp-golang maintainer (see ADMIN: add Kir Kolyshkin as a maintainer #87)
• Assess current milestones and release plans

[pcmoore]

@drakenclimber I know we talked briefly about this over email a while back, but I'm roping you into this now like it or not :) It's probably a good thing as it will mean tighter integration between the bindings and the main library, but it does mean we will need to get a bit more versed in golang (also not an entirely bad thing).

Comments are welcome, but objections to your new role will be ignored ;)

[pcmoore]

Regarding docs, we should update the existing README (also convert it to Markdown), SUBMITTING_PATCHES (Markdown conversion, rename to CONTRIBUTING.md so the GH magic works better) and add in a SECURITY.md and doc/admin/MAINTAINER_PROCESS.md and doc/admin/RELEASE_PROCESS.md.

The main libseccomp docs should be a good starting point, but those docs will need to be re-examined in the context of golang conventions and this project.

[drakenclimber]

Sounds good. I can help with the update.

Your checklist looks like a really good starting point.

[drakenclimber]

I have some time until my next meeting. I'll start working on converting the README to markdown.

[kolyshkin]

[ ] Convert SUBMITTING_PATCHES to Markdown and rename to CONTRIBUTING.md

This item is actually already DONE (#46 / commit 3c63c27); please check it.

[pcmoore]

At this point I think we've done a basic triage of the outstanding issues (NOTE: we've triaged them, not resolved them) so I'm marking that as done.

[pcmoore]

I think one of the biggest outstanding items on our list now is the RELEASE_PROCESS.md doc; while we've now got a stub in the repo, it's pretty useless. With golang being a bit different, I don't think a simple copy-n-paste is a good idea, but I think there are a few key ideas we can take from the core library's release process:

1. Verify that all issues assigned to the release milestone have been resolved
2. Verify that the syntax/style meets the guidelines
3. Verify that the tests run without error
4. Update the CHANGELOG file with significant changes since the last release
5. Tag the release, generate the release artifacts (tarball, checksum, etc.) and sign them
6. Push the tag to the repo, upload the release artifacts, and make a GH "release"

One thing I'm not certain about is branching, and this is likely an area where @kolyshkin could be of help: do golang projects typically have branches for different release streams (similar to what the core libseccomp library does)?

Any other thoughts @drakenclimber @kolyshkin?

[drakenclimber]

1. Verify that all issues assigned to the release milestone have been resolved
2. Verify that the syntax/style meets the guidelines
3. Verify that the tests run without error
4. Update the CHANGELOG file with significant changes since the last release
5. Tag the release, generate the release artifacts (tarball, checksum, etc.) and sign them
6. Push the tag to the repo, upload the release artifacts, and make a GH "release"

This looks reasonable to me.

One thing I'm not certain about is branching, and this is likely an area where @kolyshkin could be of help: do golang projects typically have branches for different release streams (similar to what the core libseccomp library does)?

I would love to hear this as well.

Any other thoughts @drakenclimber @kolyshkin?

Can't think of anything.

[kolyshkin]

One thing I'm not certain about is branching, and this is likely an area where @kolyshkin could be of help:
do golang projects typically have branches for different release streams (similar to what the core libseccomp library does)?

Yes. It's totally fine to have branches and we do so in a number of projects, e.g. runc, where we use release-x.y branches for backports. Go does not impose any rules on branch naming. What matters is versioning (i.e. tags).

PS I am silent because I am on vacation for the most of March.

[pcmoore]

Yes. It's totally fine to have branches and we do so in a number of projects, e.g. runc, where we use release-x.y branches for backports. Go does not impose any rules on branch naming. What matters is versioning (i.e. tags).

Thanks for the info, it seems like the core libseccomp model of branches/tags would fit here quite well so we might as well stick with that.

PS I am silent because I am on vacation for the most of March.

Enjoy your time away, and feel free to ignore us until you get back! ;)

[pcmoore]

Now that we have this sorted out a bit more, I'll work on putting together a RELEASE_PROCESS.md draft in a PR and we can discuss the process further there.

[pcmoore]

The only remaining item in this issue is "assess current milestones and release plans", and considering that we have the milestone tagging in place, a basic release process, and existing issues like #19 I think we can consider this item resolved. Arguably, that item probably shouldn't have been a hard requirement on the maintainer switchover anyway; we've obviously managed to transfer the role from Matt and add @kolyshkin so I think we've been successful in that regard.

Thoughts @drakenclimber and @kolyshkin?

[kolyshkin]

Yes, I think this one can be closed.

[pcmoore]

Done.