docs: update RELEASE_PROCESS.md and README.md

Update our release process and README documentation based on our
current plans.  These docs can (and should!) be updated as needed to
reflect changes in our processes.

Acked-by: Tom Hromatka <[email protected]>
Signed-off-by: Paul Moore <[email protected]>

Author: pcmoore

README.md

@@ -26,9 +26,33 @@ Documentation for this package is also available at:
 
 * https://pkg.go.dev/github.com/seccomp/libseccomp-golang
 
+## Verifying Releases
+
+Starting with libseccomp-golang v0.9.2, the git tag corresponding to each
+release should be signed by one of the libseccomp-golang maintainers.  It is
+recommended that before use you verify the release tags using the following
+command:
+
+	% git tag -v <tag>
+
+At present, only the following keys, specified via the fingerprints below, are
+authorized to sign official libseccomp-golang release tags:
+
+	Paul Moore <[email protected]>
+	7100 AADF AE6E 6E94 0D2E  0AD6 55E4 5A5A E8CA 7C8A
+
+	Tom Hromatka <[email protected]>
+	47A6 8FCE 37C7 D702 4FD6  5E11 356C E62C 2B52 4099
+
+	Kir Kolyshkin <[email protected]>
+	C242 8CD7 5720 FACD CF76  B6EA 17DE 5ECB 75A1 100E
+
+More information on GnuPG and git tag verification can be found at their
+respective websites: https://git-scm.com/docs/git and https://gnupg.org.
+
 ## Installing the package
 
-	# go get github.com/seccomp/libseccomp-golang
+	% go get github.com/seccomp/libseccomp-golang
 
 ## Contributing
 

doc/admin/RELEASE_PROCESS.md

@@ -5,6 +5,45 @@ https://github.com/seccomp/libseccomp-golang
 This is the process that should be followed when creating a new
 libseccomp-golang release.
 
-#### TODO: create a release process using libseccomp as a reference
+#### 1. Verify that all issues assigned to the release milestone have been resolved
 
-* https://github.com/seccomp/libseccomp/blob/main/doc/admin/RELEASE_PROCESS.md
+  * https://github.com/seccomp/libseccomp-golang/milestones
+
+#### 2. Verify that the syntax/style meets the guidelines
+
+	% make check-syntax
+
+#### 3. Verify that the bundled tests run without error
+
+	% make vet
+	% make check
+
+#### 4. If any problems were found up to this point that resulted in code changes, restart the process
+
+#### 5. Update the CHANGELOG file with significant changes since the last release
+
+#### 6. If this is a new major/minor release, create new 'release-X.Y' branch
+
+	% stg branch -c "release-X.Y"
+
+	... or ...
+
+	% git branch "release-X.Y"
+
+#### 7. Tag the release in the local repository with a signed tag
+
+	% git tag -s -m "version X.Y.Z" vX.Y.Z
+
+#### 8. Push the release tag to the main GitHub repository
+
+	% git push <repo> vX.Y.Z
+
+#### 9. Create a new GitHub release using the associated tag, add the relevant section from the CHANGELOG file
+
+#### 19. Update the GitHub release notes for older releases which are now unsupported
+
+The following Markdown text is suggested at the top of the release note, see old GitHub releases for examples.
+
+```
+***This release is no longer supported upstream, please use a more recent release***
+```