Comment 3 for bug 1888656

[Summary]
This looks mostly ok, it essentially is just an advanced shell script.

A 473 line config file suggests plenty of hidden complexity and special
cases, so with this becoming fully supported the owning team needs to be aware
of some hard debugging hours.
At the same time there are no self-tests - so I feel this might break at any
time and then will need attention.
The open Debian bugs kind of reflect this.
Nothing to stop the MIR, but I wanted to raise awareness for this.

Required before ack:
- The package has a no team bug subscriber, this is a hard requirement

Recommended before ack:
- Some shellcheck errors (mostly sh vs bash things) are worth to clean up.
- think how to add at least some regular testing for this package

MIR Team Ack once the conditions above are fulfilled.

There seems to be no inherent security risk, for this MIR no security review
is needed.

[Duplication]
There are a few kernel interfaces, but no package providing a configurable
place. The UI configs e.g. power options in gnome - do not cover these options.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
  - in main are hdparm wireless-tools pci-utils rfkill usbutils ethtool
    and network-manager
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

[Common blockers]
OK:
- does not FTBFS currently (no actual build)
- no translation present, but none needed for this case (user visible)?
- not a python package, no extra constraints to consider int hat regard
- no new python2 dependency

Problems:
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- does have a test suite that runs as autopkgtest
=> I'm unsure what tests we could do, due to the nature testing this right
   to have a vast matrix of different bare metal systems

- The package has a no team bug subscriber, this is a hard requirement

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is ok
- Debian/Ubuntu update history is ok
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- not using Built-Using
- Does not have Built-Using

[Upstream red flags]
OK:
- no Errors/warnings during the build (this is only shell)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks

Problems:
- there are no show stoppers, but shellcheck isn't entirely happy
  a cleanup session by the owning team would certainly be helpful