Devices that are working quite well get lost in the big matrix of booting devices. To improve the situation, devices postmarketOS runs on will be grouped into the following categories.
|main||yes, >= 2 people|| Everything in community, plus required working features (where available):
Not required (shall change in the future):
Devices in main must run a (close to) mainline kernel and must not use Halium/libhybris.
See also: postmarketos#25
|community||yes|| No fixed feature requirements. Purpose of community is to increase visibility of devices that:
See also: postmarketos#24
|testing||no||All other device ports, including new ones. Maintainers can create merge requests to move devices to community if requirements are met.|
|unmaintained||no||Known broken device ports are stored here, binary packages are not built for these. The rationale is, that it is easier to restore ports from such an unmaintained dir.|
A device maintainer must own the device and be able to test changes. They must make sure that the device port stays in good shape.
Moving between categories
Moving to a higher category
Moving from testing to community, from community to main or even from testing straight to main.
- Make sure that the device fulfills all requirements for the new category (see table above).
- Create a new merge request in which you move the files.
- Add new maintainers to the device's APKBUILD in the merge request, if necessary.
- The core team collects approvals as usual, but requires four approvals (instead of the usual two).
- Everyone should be given the chance to look at the entire device port again, to identify issues/possible improvements. Therefore the MR should not be merged before a minimum time of one week passed.
- Reviewers should look at all files that were moved and add comments as necessary. (GitLab currently doesn't allow in-line comments for moved files gitlab#213446, so just add comments below the merge request.)
- Reviewers should verify that the device fulfills all requirements for the new category (see table above).
- Reviewers should pay special attention to consistency issues, as outlined in postmarketos#24.
- Consistency issues/possible improvements in the existing features (not missing features) should be discussed and ideally fixed before merge.
- Consistency changes that require lots of work should be documented as issues at least. (Let's not unnecessarily delay merge, that's annoying for everyone.)
Moving to a lower category
If rules to keep a device in a category are no longer fulfilled, we should create a merge request to move them to the now appropriate category. So far we did not come up with extra rules, so we would treat it just like any other merge request.