- How far down in the review of a module/library does the vetting project go? Do we vet the use of the use of the use, etc. of a library?
- What are the criteria of acceptance of a module/library (license, usage, versioned, security concerns, etc.)
- Is it ok to accept a module/library that meets the criteria but could be smaller if we just did it ourselves (i.e. - is accepting a library that has 5 layers deep of imports ok?). How would we define / stipulate this as a criteria?
- James Gregg and Tony Espy to create short list of evaluation criteria based on James's list in https://github.com/jamesrgregg/1947-explore
- Next meeting: Jim White to use the evaluation list provided by Tony/James to review the 30+ library/module imports of edgex-go that are dynamically versioned (have no version number tag - example is bitbucket.org/bertimus9/systemstat v0.0.0-
- With the revised criteria list and module/library report, re-evaluate this at the next meeting.
- the draft vetting policy.
- PR Template for conventional commits is now in place for all repositories for all PRs but without TSC approval. It doesn’t appear to be affecting any problem. We need to finalize the shape of this and officially approve the template by the TSC.
- Mike, Lisa and Tony to provide improved template around conventional commits and any recommended policy for TSC approval.
- Add a service dot setting to set up the adapter for listen on web services (Lenny to provide more details)
- EdgeX UI - it is for dev/test right now. Would we ever want to have a UI for production? Under what constraints?
- How should we apply semantic versioning to modules? When do we update the minor and major versions of modules? (comes from the Hanoi planning meetings)PR Template for conventional commits is now in place for all repositories for all PRs but without TSC approval. It doesn’t appear to be affecting any problem. We need to finalize the shape of this and officially approve the template by the TSC.
- Extract of Device Service requirements to ADR legacy - what are all the pieces that need to be moved there?
- Per the Hanoi planning conference - we need to better define "bound checking" so that a design (and eventual implementation) can be brought forth to meet the requirements
- Currently considering limiting the number of operations that can be performed on a service (like a device service) over a period of time or setting the max request size (that lends to DoS attacks)
- Can the solution be more globally applied?
- Design metadata about the “gateway” or host platform (identity, location, …)
- How do address module and component version release needs for examples (per Slack exchange with Luis Obando). go.mod in the examples helps - or at least some documentation on dependencies.
- How should we deal with example code? Example code for app services lives in holding. Example code for Device Services lives in the device service SDK (although to some extent, device random and virtual are examples). Security is about to create some example code for SSH tunneling. Should all this be collected somewhere? Should it live in Github or in the docs (or on the Wiki or other location)? Should it be consolidated? Is it managed code or is it "buyer beware" code?