Summary
Excerpt |
---|
Planned topics:
|
...
Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.
...
- Indy Node
- October: 1.11.0
- PBFT view change
- November: 1.12.0
- Ubuntu 18.04
- Replacing Indy Node with Ursa
- Remove replicas (Aardvark BFT)
- Bug fixes
- Future
- Advanced Schemas and W3C creds (Ken)
- October: 1.11.0
- Indy SDK
- October: 1.12.1
- Bug fixes
- Might skip the release
- November
- LibVCX support for some Aries protocols
- Bug fixes
- Future
- GitLab migration alongside Jenkins (Foundation)?
- Anoncreds 2.0 (Sovrin Foundation, BC.gov?)
- Warnings from rust cargo clippy (Mike and Axel), epic: IS-1410
- October: 1.12.1
- Indy Catalyst
- Production deployment testing: volume loads.
- Won't go live in production at BC.gov until October.
- Not yet migrated to Hyperledger. Needs more documentation.
- Documentation improvements: Michael B and Stephen C
- Need to review and prune out-of-date documentation (Alice / Faber treatment of pairwise DIDs is a key pain point)
- Cloud Compass is building the Linux Foundation EdX courses for Indy and Aries
- New design for revocation / Anoncreds 2.0 (Mike)
- Would be useful to have a comparison in performance between Anoncreds 1.0 and Anoncreds 2.0
- Need a plan for changes to Indy Node
- HIPE for overall changes, then a design PR for the changes specific to the different repos.
https://github.com/hyperledger/indy-node/tree/master/design
- HIPE for overall changes, then a design PR for the changes specific to the different repos.
Main Business
- Problems with the iOS wrapper
- Lohan: We are using CocoaPods to manage our dependencies within our iOS project. We are experiencing some issues with the pod "libindy-objc".
- Others with the same issue: https://forum.sovrin.org/t/ios-indy-sdk-image-not-found/1306
- The future of Indy Wrappers in an Aries world
- Define the pull request review process for Indy Plenum/Node
- Should define the process, including how we handle exceptions (emergency fixes shouldn't be blocked, but would require notification)
- What is important in a good review?
- Items from Evernym team:
- covered by tests
- has a link to the issue in Jira
- fixed according to PoA
- follows https://github.com/hyperledger/indy-node/blob/master/docs/source/write-code-guideline.md
- Items from Evernym team:
- Proposed Process (by Evernym team):
- All Pull Requests can be reviewed by non-Evernym team members
- Evernym team members will also do internal review in addition to external one
- All interested parties are notified when a PR is sent
- If a person wants to do an external review, he or she puts a comment or tag. This needs to be done in X hours.
- Once a reviewer put a "want-to-review" tag, he or she need to finish review in Y hours
- If no one wants to review a PR in X hours, or review is not finished in Y hours, we can do our internal review and merge the PR
- An external review can be done against closed PRs as well, and Evernym team will process all findings ASAP
- We may merge a PR with internal review only in case of urgency (critical fixes, release preparation etc.)
- Items to be defined with the Community:
- A timeframe for external review (X):
- X=12 hours, Y=2 days? - What projects it should affect?
- Plenum and Node?
- Only Node?
- We are not proposing SDK as it will be split to Aries in any case - Who is going to commit to participate in this process?
- A timeframe for external review (X):
- Migration of Indy-SDK to Aries-Core
...