Document requirement for annotated tags

docs/abra/hack.md

@@ -127,16 +127,7 @@ Then, before running tests, set `export BATS_LIB_PATH=~/.local/share/bats/`
 ##### Debian
 
 ```
-apt install bats-file bats-assert bats-support jq make git
-```
-
-Unfortunately, the latest `bats` version in Debian stable does not have the "filter tests by tags" feature, which is very handy for running a subset of the tests. For this, we need to install `bats` from source. It's easy.
-
-```
-apt purge -y bats
-git clone https://github.com/bats-core/bats-core.git
-cd bats-core
-sudo ./install.sh /usr/local
+apt install bats bats-file bats-assert bats-support jq make git
 ```
 
 #### Setup Test Server

docs/federation/resolutions/passed/032.md

@@ -1,5 +1,5 @@
 ---
-title: "Resolution 032: RIM joins"
+title: "Resolution 032: RTM joins"
 ---
 
 - Topic: RTM joins Coopcloud
@@ -11,7 +11,7 @@ title: "Resolution 032: RIM joins"
 
 Ammar's membership was approved in [Resolution 022](/federation/resolutions/passed/022).
 
-Since the establishment of RTM (Resist Rech Monopolies) collective in Seattle, Ammar has been unofficially representing the collective with coopcloud and vice versa.
+Since the establishment of RTM (Resist Tech Monopolies) collective in Seattle, Ammar has been unofficially representing the collective with coopcloud and vice versa.
 	
 ### Details
 	

docs/maintainers/handbook.md

@@ -368,7 +368,7 @@ You'll notice that `abra` figured out how to upgrade the Co-op Cloud version lab
 At this point, we're all set, we can run `abra recipe release --publish wordpress`. This will do the following:
 
 1. run `git commit` the new changes
-1. run `git tag` to create a new git tag named `1.1.0+5.9.0`
+1. run `git tag -am "chore: publish 1.1.0+5.9.0 release" 1.1.0+5.9.0` to create a new annotated git tag named `1.1.0+5.9.0` (abra only accepts annotated tags)
 1. run `git push` to publish changes to the Wordpress repository
 
 !!! warning "Here be more SSH dragons"
@@ -702,10 +702,10 @@ Please note:
 1. The `file_env` / `_FILE` hack is to pass secrets into the container runtime without exposing them in plaintext in the configuration. See [this entry](/maintainers/handbook/#exposing-secrets) for more.
 
 1. In order to pass execution back to the original entrypoint, it's a good idea to find the original entrypoint script and run it from your own entrypoint script. If there is none, you may want to reference the `CMD` definition or if that isn't working, try to actually specify `cmd: ...` in the `compose.yml` definition (there are other recipes which do this).
-  
+
 1. Also it might be necessary to define command: although there is an original entrypoint. That's [due to the fact](https://docs.docker.com/reference/compose-file/services/#entrypoint) that if entrypoint is non-null, Compose ignores any default command from the image, for example the `CMD` instruction in the Dockerfile.
 
-  1. Pratically you would e.g. look for the Dockerfile of the upstream image. In there you should find the docker-entrypoint.sh (or similar) and where it's located. Furthermore you find the `CMD`-line there. 
+  1. Pratically you would e.g. look for the Dockerfile of the upstream image. In there you should find the docker-entrypoint.sh (or similar) and where it's located. Furthermore you find the `CMD`-line there.
   1. Just put in your entrypoint.sh in the last line: exec /path/to/docker-entrypoint.sh "@" (path and filename you should find in upstream Dockerfile) and insert  command:  to your service in compose.yml with the value of what you find in the CMD line of the Dockerfile.
 
 1. If you're feeling reckless, you can also use the Golang templating engine to do things conditionally.