...
- The service should implement the functionality described in the Device Services Requirements document.
- The service should target either the current or development versions of EdgeX.
- The service should not rely on new or variant APIs.
- The service's name should should follow the usual form, ie edgex-{device-class}-{language} and not conflict with any other adopted service.
- Values must not be hardcoded where they might reasonably be configurable.
- A top-level README should be present and contain information on
- The types of device supported
- Host device requirements, especially if advanced features or operating modes are needed.
- Run-time dependencies
- Protocol feature support and roadmap
- Known limitations
- Information on asynchronous readings, if these are generated
- Build instructions, including build-time dependencies
- Usage information (command-line options)
- The following items must also be documented:
- Supported configuration options (including whether or not the service must be restarted for changes to take effect)
- Supported ProtocolProperties schemes.
- Supported Device Attributes.
- As part of the above, example Device Profiles and illustrative TOML for Device provisioning should be included.
- It must be possible to run the device service against simulated hardware. Documentation illustrating how to do so is also required. The review group should attempt to replicate the scenario described.
- Container packaging must use full confinement (i.e. no use of docker --privileged or snap --devmode). Where access to hardware is required, care must be taken to make exceptions for the specific required hardware and/or system resources, and the means to allow these exceptions should be documented.
- A default listening port will be assigned to the new service. Sample configurations supplied with the service should specify this port.
- The service should comply with the general EdgeX requirements as given in the Contributor's Guide.
In some cases a review may take place in a number of cycles, eg if the reviewers feel that one or more fundamental issues need to be addressed before detailed consideration is worthwhile. Where the reviewers feel that changes are necessary, issues should be created within GitHub for discussion and resolution. During the review process, other contributors may raise issues of their own; it is not compulsory that these are resolved but the review team should consider them before giving overall approval.
Should Upon successful completion of the review of , the WG will be invited to approve the service be successful. On approval, a unique default listening port will be assigned for the service, and the WG chair will propose to the TSC that the service notice is to be sent to the TSC and one week later the TSC will consider the new service and hold a vote via email as to whether it should be adopted into EdgeX.
If the TSC agrees, the following actions need be taken:
...