7 files changed, 77 insertions, 40 deletions
diff --git a/docs/markdown/Adding-new-projects-to-wrapdb.md b/docs/markdown/Adding-new-projects-to-wrapdb.md
index bbe945d..25fb61c 100644
--- a/docs/markdown/Adding-new-projects-to-wrapdb.md
+++ b/docs/markdown/Adding-new-projects-to-wrapdb.md
@@ -6,14 +6,17 @@
 Each wrap repository has a master branch with only one initial commit and *no* wrap files.
 And that is the only commit ever made on that branch.
 
-For every release of a project a new branch is created. The new branch is named after the 
-the upstream release number (e.g. `1.0.0`). This branch holds a wrap file for 
+For every release of a project a new branch is created. The new branch is named after the
+the upstream release number (e.g. `1.0.0`). This branch holds a wrap file for
 this particular release.
 
 There are two types of wraps on WrapDB - regular wraps and wraps with Meson build
 definition patches. A wrap file in a repository on WrapDB must have a name `upstream.wrap`.
 
-Wraps with Meson build definition patches work in much the same way as Debian: we take the unaltered upstream source package and add a new build system to it as a patch. These build systems are stored as Git repositories on GitHub. They only contain build definition files. You may also think of them as an overlay to upstream source.
+Wraps with Meson build definition patches work in much the same way as Debian:
+we take the unaltered upstream source package and add a new build system to it as a patch.
+These build systems are stored as Git repositories on GitHub. They only contain build definition files.
+You may also think of them as an overlay to upstream source.
 
 Whenever a new commit is pushed into GitHub's project branch, a new wrap is generated
 with an incremented version number. All the old releases remain unaltered.
@@ -21,13 +24,15 @@ New commits are always done via GitHub merge requests and must be reviewed by
 someone other than the submitter.
 
 Note that your Git repo with wrap must not contain the subdirectory of the source
-release. That gets added automatically by the service. You also must not commit 
+release. That gets added automatically by the service. You also must not commit
 any source code from the original tarball into the wrap repository.
 
 ## Choosing the repository name
 
 Wrapped subprojects are used much like external dependencies. Thus
-they should have the same name as the upstream projects. 
+they should have the same name as the upstream projects.
+
+NOTE: Repo names must fully match this regexp: `[a-z0-9._]+`.
 
 If the project provides a pkg-config file, then the repository name should be
 the same as the pkg-config name. Usually this is the name of the
@@ -36,16 +41,19 @@ however. As an example the libogg project's chosen pkg-config name is
 `ogg` instead of `libogg`, which is the reason why the repository is
 named plain `ogg`.
 
-If there is no a pkg-config file, the name the project uses/promotes should be used, 
+If there is no a pkg-config file, the name the project uses/promotes should be used,
 lowercase only (Catch2 -> catch2).
 
+If the project name is too generic or ambiguous (e.g. `benchmark`),
+consider using `organization-project` naming format (e.g. `google-benchmark`).
+
 ## How to contribute a new wrap
 
 If the project already uses Meson build system, then only a wrap file - `upstream.wrap`
-should be provided. In other case a Meson build definition patch - a set of `meson.build` 
+should be provided. In other case a Meson build definition patch - a set of `meson.build`
 files - should be also provided.
 
-### Request a new repository or branch
+### Request a new repository
 
 Create an issue on the [wrapdb bug tracker](https://github.com/mesonbuild/wrapdb/issues)
 using *Title* and *Description* below as a template.
@@ -61,6 +69,9 @@ version: <version_you_have_a_wrap_for>
 Wait until the new repository or branch is created. A link to the new repository or branch
 will be posted in a comment to this issue.
 
+NOTE: Requesting a branch is not necessary. WrapDB maintainer can create the branch and
+modify the PR accordingly if the project repository exists.
+
 ### Add a new wrap
 
 First you need to fork the repository to your own page.
@@ -80,28 +91,28 @@ git commit -a -m 'Add wrap files for libfoo-1.0.0'
 git push origin 1.0.0
 ```
 
-Now you should create a pull request on GitHub. Remember to create it against the 
-correct branch rather than master (`1.0.0` branch in this example). GitHub should do 
+Now you should create a pull request on GitHub. Remember to create it against the
+correct branch rather than master (`1.0.0` branch in this example). GitHub should do
 this automatically.
 
+If the branch doesn't exist file a pull request against master.
+WrapDB maintainers can fix it before merging.
+
 ## What is done by WrapDB maintainers
 
+[mesonwrap tools](Wrap-maintainer-tools.md) must be used for the tasks below.
+
 ### Adding new project to the Wrap provider service
 
 Each project gets its own repo. It is initialized like this:
 
 ```
-git init
-git add readme.txt
-git add LICENSE.build
-git commit -a -m 'Create project foobar'
-git remote add origin <repo url>
-git push -u origin master
+mesonwrap new_repo --homepage=$HOMEPAGE --directory=$NEW_LOCAL_PROJECT_DIR $PROJECT_NAME
 ```
 
-Note that this is the *only* commit that will ever be made to master branch. All other commits are done to branches.
+The command creates a new repository and uploads it to Github.
 
-Repo names must fully match this regexp: `[a-z0-9._]+`.
+`--version` flag may be used to create a branch immediately.
 
 ### Adding a new branch to an existing project
 
@@ -129,12 +140,6 @@ to functionality. All such changes must be submitted to upstream. You
 may also host your own Git repo with the changes if you wish. The Wrap
 system has native support for Git subprojects.
 
-## Creator script
-
-The WrapDB repository has a
-[helper script](https://github.com/mesonbuild/mesonwrap/blob/master/mesonwrap.py)
-to generate new repositories, verify them and update them.
-
 ## Reviewing wraps
 
 See [Wrap review guidelines](Wrap-review-guidelines.md).
diff --git a/docs/markdown/Reference-tables.md b/docs/markdown/Reference-tables.md
index c42d608..60a9720 100644
--- a/docs/markdown/Reference-tables.md
+++ b/docs/markdown/Reference-tables.md
@@ -121,6 +121,7 @@ These are provided by the `.system()` method call.
 
 | Value               | Comment                         |
 | -----               | -------                         |
+| android             | By convention only, subject to change |
 | cygwin              | The Cygwin environment for Windows |
 | darwin              | Either OSX or iOS |
 | dragonfly           | DragonFly BSD |
diff --git a/docs/markdown/Unit-tests.md b/docs/markdown/Unit-tests.md
index bd91dbb..06664db6 100644
--- a/docs/markdown/Unit-tests.md
+++ b/docs/markdown/Unit-tests.md
@@ -136,7 +136,7 @@ For clarity, consider the meson.build containing:
 ```meson
 
 test('A', ..., suite: 'foo')
-test('B', ..., suite: 'foo')
+test('B', ..., suite: ['foo', 'bar'])
 test('C', ..., suite: 'bar')
 test('D', ..., suite: 'baz')
 
diff --git a/docs/markdown/Users.md b/docs/markdown/Users.md
index 41d8dfa..1867407 100644
--- a/docs/markdown/Users.md
+++ b/docs/markdown/Users.md
@@ -72,6 +72,7 @@ topic](https://github.com/topics/meson).
  - [Lc0](https://github.com/LeelaChessZero/lc0), LeelaChessZero is a UCI-compliant chess engine designed to play chess via neural network
  - [libcamera](https://git.linuxtv.org/libcamera.git/), a library to handle complex cameras on Linux, ChromeOS and Android
  - [Libdrm](https://gitlab.freedesktop.org/mesa/drm), a library for abstracting DRM kernel interfaces
+ - [libeconf](https://github.com/openSUSE/libeconf), Enhanced config file parsing library, which merges config files placed in several locations into one
  - [Libepoxy](https://github.com/anholt/libepoxy/), a library for handling OpenGL function pointer management
  - [libfuse](https://github.com/libfuse/libfuse), the reference implementation of the Linux FUSE (Filesystem in Userspace) interface
  - [Libgit2-glib](https://git.gnome.org/browse/libgit2-glib), a GLib wrapper for libgit2
diff --git a/docs/markdown/Wrap-maintainer-tools.md b/docs/markdown/Wrap-maintainer-tools.md
new file mode 100644
index 0000000..717d0d2
--- /dev/null
+++ b/docs/markdown/Wrap-maintainer-tools.md
@@ -0,0 +1,17 @@
+# Wrap maintainer tools
+
+The [mesonwrap repository](https://github.com/mesonbuild/mesonwrap) provides tools
+to maintain the WrapDB. Read-only features such can be used by anyone without Meson admin rights.
+
+## Personal access token
+
+Some tools require access to the Github API.
+A [personal access token](https://github.com/settings/tokens) may be required
+if the freebie Github API quota is exhausted. `public_repo` scope is required
+for write operations.
+
+```
+$ cat ~/.config/mesonwrap.ini
+[mesonwrap]
+github_token = <github token>
+```
diff --git a/docs/markdown/Wrap-review-guidelines.md b/docs/markdown/Wrap-review-guidelines.md
index 512353c..3e41a8d 100644
--- a/docs/markdown/Wrap-review-guidelines.md
+++ b/docs/markdown/Wrap-review-guidelines.md
@@ -7,18 +7,30 @@ package is rejected. What should be done will be determined on a
 case-by-case basis. Similarly meeting all these requirements does not
 guarantee that the package will get accepted. Use common sense.
 
-## Checklist
-
-Reviewer: copy-paste this to MR discussion box and tick all boxes that apply.
-
-    - [ ] project() has version string
-    - [ ] project() has license string
-    - [ ] if new project, master has tagged commit as only commit
-    - [ ] if new branch, it is branched from master
-    - [ ] contains a readme.txt
-    - [ ] contains an upstream.wrap file
-    - [ ] download link points to authoritative upstream location
-    - [ ] wrap repository contains only build system files
-    - [ ] merge request is pointed to correct target branch (not master)
-    - [ ] wrap works
-    - [ ] repo does not have useless top level directory (i.e. libfoobar-1.0.0)
+The review process is partially automated by the [mesonwrap](Wrap-maintainer-tools.md)
+`review` tool.
+
+```
+mesonwrap review zlib --pull-request=1 [--approve]
+```
+
+Since not every check can be automated please pay attention to the following during the review:
+
+- Download link points to an authoritative upstream location.
+- Version branch is created from master.
+- Except for the existing code, `LICENSE.build` is mandatory.
+- `project()` has a version and it matches the source version.
+- `project()` has a license.
+- Complex `configure_file()` inputs are documented.
+  If the file is a copy of a project file make sure it is clear what was changed.
+- Unit tests are enabled if the project provides them.
+- There are no guidelines if `install()` is a good or a bad thing in wraps.
+- If the project can't be tested on the host platform consider using the `--cross-file` flag.
+  See [the issue](https://github.com/mesonbuild/mesonwrap/issues/125).
+
+Encourage wrap readability. Use your own judgement.
+
+## Approval
+
+If the code looks good use the `--approve` flag to merge it.
+The tool automatically creates a release.
diff --git a/docs/sitemap.txt b/docs/sitemap.txt
index 4029a60..aa3f51a 100644
--- a/docs/sitemap.txt
+++ b/docs/sitemap.txt
@@ -72,6 +72,7 @@ index.md
 		Adding-new-projects-to-wrapdb.md
 		Using-the-WrapDB.md
 		Using-wraptool.md
+		Wrap-maintainer-tools.md
 		Wrap-best-practices-and-tips.md
 		Wrap-review-guidelines.md
 		Shipping-prebuilt-binaries-as-wraps.md