Skip to content

Requirements for devices in community/

Related: #16 (closed)

At the moment the wiki says:

Some base functionality must be working (no fixed feature set). As actively maintained implies, it is usable in some way, or there is at least some goal that maintainers are trying to achieve.

But it doesn't really make it clear how we decide if a device can be moved to community/.

I think it's quite hard to set fixed requirements, since the point of community/ is not to have X features working, but rather to increase visibility of devices that:

  • a lot of work was put into
  • are working quite well (usable in some way, even if just for testing/improving some desktop environments, creating apps, ...)
  • stay working quite well (i.e. they are tested occasionally to find and fix regressions)
  • are still being improved or are considered completed at some point (because some functionality is just too complicated/impossible)
  • are overall in good shape (good as a reference to link to in case of questions)
  • stay in good shape (e.g. if some new feature is added to postmarketOS that needs configuration, the device should be updated/tested with necessary changes)

Consistency

I think it is also important that (at least supported) devices behave consistently. When I install postmarketOS on two different supported devices it should behave the same (except for hardware differences). At the moment we sometimes introduce inconsistent behavior by implementing certain functionality in the device package, even though the problem being solved is a generic one (that affects all devices).

A few (random) examples:

  • pine64-pinephone enables several generic services (bluez, gpsd) by default (for all installations).
    • IMO these should be usually activated as part of some desktop environment, or installed+activated by the user. Otherwise the none installation just becomes unnecessarily large/bloated.
    • For that reason I do not install+activate bluez for devices I maintain for example, which means (I guess?) that users need to install+activate BlueZ before Bluetooth works in a DE like Phosh.
    • I have opened a separate issue for this: https://gitlab.com/postmarketOS/pmaports/-/issues/531
  • pine64-pinephone sets a custom Bluetooth device name, but none of the other devices do: https://gitlab.com/postmarketOS/pmaports/-/issues/530
  • purism-librem5 also configures a USB serial gadget, while others just have USB network: https://gitlab.com/postmarketOS/pmaports/-/issues/526
  • The kernel configurations are very inconsistent, we don't have a shared place where we could enable Anbox, WireGuard or just some peripherals for all mainline kernels for example.

Sometimes this is fine as temporary measure to speed up the bring up (either because of device-specific quirks or to not slow it down with endless discussions/preparations). But in long term stuff like that will cause confusion and makes porting new devices more complicated.
(Once you run into the problem you duplicate the solution into your device package, but the next person will run into it again.)

The reason I mention this here is because I think that moving a device to community/ (or main/) is a good chance to identify these kind of differences, and start discussion (e.g. in extra issues) how to handle it in a consistent way. Just like I did above. With our normal MR process it's easy to miss certain changes.

Requesting move to community/

  • This can be done with a simple MR.
  • We can collect approvals as usual (maybe some more, e.g. 4 instead of 2?)
  • Everyone should be given the chance to look at the entire device port again, to identify issues/possible improvements like the above.
    • The MR should be open for some time, e.g. a minimum of 1 week, maybe a bit more
  • Issues/possible improvements in the existing features (not missing features) should be discussed and ideally fixed before merge.
    • Changes that require lots of work should be documented as issues at least (I don't think it makes sense to unnecessarily delay merge, that's annoying for everyone)
Edited by Administrator
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information