2019-11-18 Indy Contributors Call
Summary
Work updates
Updates on the status of Plenum
Pull request review process for Indy Node
Timezone: Europe afternoon / US morning
We intend to record this call.
Remember the Hyperledger Code of Conduct
Anti-Trust Policy
Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.
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.
Introductions
Attendees
Name (Employer) <email>
@Richard Esplin (Evernym) <richard.esplin@evernym.com>
@Matt Raffel (Kiva) <mattr@kiva.org>
@Nemanja Patrnogic <nemanja.patrnogic@evernym.com>
@Alexander Sherbakov (Evernym) <alexander.shcherbakov@evernym.com>
@Syed Awais Ahmad (Prove) <awais.ahmad@proveglobal.com>
@Ken Ebert (Sovrin Foundation) <ken@sovrin.org>
Related Calls and Announcements
Aries Workshop/Connectathon December 3-5 in Provo, Utah
ssimeetup.org webinars
Peer DIDs Nov 21 at 1 PM MST,
December 17: Deep dive into the Plenum Ledger
Previous Indy Contributors call
Identity Implementors Working Group call
Main place to get project updates, release status, and announcements.
Release Status and Work Updates
Indy Node
November: 1.12.1
Bug fixes
Ubuntu 18.04 (Kiva)
Need to check additional dependencies:
Error rendering macro 'jira' : null
Replacing Indy Crypto with Ursa (Kiva)
Additional rich schemas objects: schema object (Sovrin Foundation)
Just posted Indy HIPE
https://github.com/hyperledger/indy-hipe/pull/149PR of schema object in progress for November
Making progress on other RFCs for objects and one that shows how all the objects fit together.
December / January: 1.23.0
Remove replicas (Aardvark BFT) ?
Rich Schema progress: encoding object
Future
Anoncreds 2.0 (Sovrin Foundation)
Indy SDK
November 1.13.0
Issue reported by BC.gov:
https://github.com/hyperledger/indy-sdk/pull/1893Need to include a manual release of iOS artifacts
LibVCX support for some Aries protocols
Deprecating some docs (IS-1425: Getting Started Guides) and wrappers (IS-1423: Python and DotNet)
Bug fixes
Future
Deprecate additional wrappers (IS-1424) and LibVCX (IS-1416)
GitLab migration alongside Jenkins (Foundation)?
Warnings from rust cargo clippy (Mike and Axel), epic: IS-1401
Indy Catalyst
Production deployment testing: volume loads.
Trying to identify performance bottlenecks. Currently think it's calls to the database.
Performance problems is preventing going to production.
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
Overview launch date: November 21st
More content will follow
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/designBC.gov will implement the existing revocation capability in ACA-Py for use in constrained cases
Looking to build against Anoncreds 2.0 as soon as it is available.
Unable to contribute to the Anoncreds 2.0 revocation capability at this time - no resources for that work.
Main Business
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?
PR checklist items from Evernym team:
has a link to the issue in Jira
fix is correct according to requirements and the according to Plan of Attack (PoA) as shown in the Jira ticket and approved by an architect
covered by tests (implementation is TDD style: both unit and integration tests)
plan for documentation changes in the same issue, or links to other issues for documentation when it is a large effort (diagram creation)
follows good design patterns
follows https://github.com/hyperledger/indy-node/blob/master/docs/source/write-code-guideline.md
multiple small pull requests are better than a single huge pull request
PoA helps decomposition of work
Documentation can be a separate PR for the same ticket
Good review feedback
Don't merge until the problem is fixed.
But can merge if the suggestions are all a matter-of-taste, or smaller items that can be done in a follow-up pull request.
Try to provide specific suggestions on how to respond to the feedback as a list or code-sample.
Proposed process for cross-organization PR reviews (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.), and with reporting afterwards
Items to be defined with the Community:
A timeframe to start
Would like to start the process in November if possible
A timeframe for external review (X):
X=18 hours, Y=24 hours
X being 18 hours would mean that the team doesn't usually merge pull requests in the same day they are created, but can be merged at the start of the next business day
Y being 24 hours means that the review will complete the review within a day of saying that he wants to do the review. Some reviews might take longer, if the reviewer asks for additional time to complete the complicated review.
What projects it should affect?
Node is preferred for now (disrupt one project at a time)
Most fixes at the moment are in Plenum, so can include them as well
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?
Ken: one review a week, at a minimum
Kiva: could probably start in a month-or-so
How to notify:
GitHub list of reviewers
Rocket chat #indy-maintainers can help us highlight priority reviews
Improvements to the proposal
Alex's team labels PRs that they think would most benefit from reviews.
We can schedule appointments for reviewing specific PRs together.
Future Calls
Migration of Indy-SDK to Aries-Core
Requirements question: IS-1099, should we allow duplicate credentials from the same issuer?
Non-secrets in the Indy Wallet
Cam is working on pluggable crypto. The wallet shouldn't decide what encryption you should be using.
Use cases where we would want to move keys between wallets
Moving the link secret / credential data from one device to another (synchronized storage).
Debug use cases
Richard's hit other uses cases that were better solved with DID Doc, pre-signing, signing API.
Work-around with the web-crypto API
Action items
HIPE #138, Issue #144 (Ken and Brent)