Implement the process for moving packages from testing to stable (#81)

* Implement the process proposed in #20
* Open merge PRs on Saturdays instead of Mondays
* Additional package testing criteria
* Add clause for allowing bug fixes
* Update link to stable/testing docs in README
* Add info on how to switch branches

README.md

@@ -56,7 +56,7 @@ $ opkg upgrade
 ```
 
 [See information about advanced Opkg commands →](https://openwrt.org/docs/guide-user/additional-software/opkg)\
-[Choose between the _stable_ and _testing_ channels →](docs/channels.md)
+[Choose between _stable_ and _testing_ →](docs/branches.md)
 
 ### Build it
 

docs/branches.md

@@ -0,0 +1,36 @@
+## Release branches
+
+There are two release branches in Toltec, [stable](https://toltec.delab.re/stable) and [testing](https://toltec.delab.re/testing).
+As a user, **you always want to use the stable branch**, which is the default one when following the install instructions.
+The testing branch exists solely for the repository maintainers to make sure that packages work correctly before distributing them to users.
+It may contain packages that could cause breakage if you install them on your device.
+
+> To use the testing branch, update the `/opt/etc/opkg.conf` file on an existing install or set the `toltec_branch` variable to `testing` when installing through the bootstrap script.
+
+### Adding or updating a package
+
+New packages or package updates are exclusively proposed through pull requests based on the testing branch.
+A proposal can be merged into testing after it is reviewed by a maintainer and if it builds successfully in the CI.
+If it is a proposal for a new package, the maintainer who reviews the pull request becomes the maintainer for that package.
+If it updates an existing package, the maintainer of that specific package should do the review.
+
+### Moving a package from testing to stable
+
+Each Saturday, a pull request can be opened with selected updates from the testing branch to merge in the stable branch.
+Only bug fixes may be added to existing merge PRs over the weekend.
+This pull request can only be merged from the following Monday.
+Each of these package changes must be tested by a maintainer different from the maintainer of the affected package.
+
+Here are important things to check when testing a package:
+
+1. The package should work as intended by upstream.
+2. It should not have any known major bugs.
+3. It must not destroy any user data (e.g. from previous versions of the same package, from other packages, from the home directory).
+4. It must not break other packages.
+5. It must not lock the device in a state where it cannot be used without rebooting or troubleshooting through SSH.
+
+### Orphaning a package
+
+The maintainer of a package can, for any reason, choose to orphan a package.
+To do so, they need to send a pull request to reset the [`maintainer` metadata field](docs/package.md#maintainer-required) of that package to `None <none@example.org>`.
+The next person to review a pull request regarding an orphaned package becomes its new maintainer and must update the `maintainer` field accordingly.

docs/package.md

@@ -141,7 +141,9 @@ If the package does not fit into one of the existing sections, add a new one to
     </tr>
 </table>
 
-**TODO:** Documentation.
+The package maintainer’s name and current email address, in RFC822 format (e.g. `John Doe <doe@example.org>`).
+This is the person in charge of reviewing any pull request regarding the package.
+This field may be equal to `None <none@example.org>` if a package is orphaned or when a package is initially proposed.
 
 #### `license`