Page History

...

• Name (Employer) <email>
• Richard Esplin (Evernym) <richard.esplin@evernym.com>
• Matt Raffel (Kiva) <mattr@kiva.org>
• Nemanja Patrnogic (donqui) <nemanja.patrnogic@evernym.com>
• Alexander Shcherbakov (Evernym) <alexander.shcherbakov@evernym.com>
• Syed Ahmad (Prove) <awais.ahmad@proveglobal.com>
• Ken Ebert (Sovrin Foundation) <ken@sovrin.org>

...

• Indy Node
  • November: 1.12.1
    • Bug fixes
    • Ubuntu 18.04 (Kiva)
      • Need to check additional dependencies: 

        Jira
        server Hyperledger JIRA serverId 6326cb0b-65b2-38fd-a82c-67a89277103b key INDY-2196

    • 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/149
      • Aries RFC
        https://github.com/hyperledger/aries-rfcs/pull/281
      • PR 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
    Advanced Schemas and W3C creds (Ken)
    • Rich schema schema object support for November
    Anoncreds 2.0 (Sovrin Foundation)
• Indy SDK
  • November 1.13.0
    • Issue reported by BC.gov:
      https://github.com/hyperledger/indy-sdk/pull/1893
    • Need 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-14101401
• 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/design
    • BC.gov will implement the existing revocation capability in ACA-Py for use in constrained cases
      • Not looking at building against Anoncreds 2.0

...

• 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 PR checklist items from Evernym team:
      covered by tests
      • has a link to the issue in Jira
      • fixed 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 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.), and with reporting afterwards
  • Items to be defined with the Community:
    1. A timeframe for external review (X):
       - X=12 hours, Y=2 days?
    2. 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
    3. Who is going to commit to participate in this process?

...