Page History

...

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
  - 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-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/design
  - BC.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 Not looking at building against 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:
  1. A timeframe to start
    1. Would like to start the process in November if possible
  2. A timeframe for external review (X):
    1. X=18 hours, Y=24 hours
      1. 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
      2. 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.
  3. What projects it should affect?
    1. Node is preferred for now (disrupt one project at a time)
      1. Most fixes at the moment are in Plenum, so can include them as well
    2. We are not proposing SDK as it will be split to Aries in any case.
  4. Who is going to commit to participate in this process?
    1. Ken: one review a week, at a minimum
    2. Kiva: could probably start in a month-or-so
  5. How to notify:
    1. GitHub list of reviewers
    2. Rocket chat #indy-maintainers can help us highlight priority reviews
- Improvements to the proposal

...

Space shortcuts

Page tree

Versions Compared

Old Version 6

New Version 7

Key

Main Business