hyperledger-archives
Notifying users that new releases are not planned.
As our focus moves from the Indy SDK to replacement libraries, we should set the expectation with users of Indy SDK that future releases are not planned. We should also encourage contributors to participate in replacement efforts rather then submitting PRs here that may never be reviewed.
Signed-off-by: Richard Esplin [email protected]
Note that this PR should not be merged until we have the chance to discuss it in the next Indy Contributors call.
I believe that I've addressed all concerns that have been raised and this is ready for merging.
Can we find way around this? I see many useful pending PRs (especially asynchronicity in libindy 🚀 ) and I don't think the whole repo needs to "die" like this. Even though BC gov is doing great job providing alternatives in form of individual smaller libraries, libindy still has its users. The major issue I see with this repo is the pipeline. It's difficult for both maintainers and contributors - pipeline is unstable and private (no way for contributor to see Jenkins logs). Contributors don't know why their PR are failing so it's impossible to iterate, for maintainers the maintenance itself is expensive because managing Jenkins infra and pipelines is quite resource-expensive in my view.
My suggestion:
- Create Github Actions based pipeline with limited scope - obviously we can't do everything Jenkins was trying to do using GA runner infrastructure (test on multiple linux distributions for example). Smaller but working and fast CI is better than broken giant one. I think the starting scope for new CI should be compiling and test libindy and its wrappers (libvcx excluded from CI completely). Then start adding publishing or other stuff. Contributing GA CI code is much more accessible than contributing to Jenkins CI in its current form, so I believe it might organically grow if there will be interest in libindy.
- If the proposal seems reasonable way to keep indysdk breathing, we Absa, are open to contribute GA actions (in fact, I've started digging into this about a year ago already https://github.com/hyperledger/aries-vcx/actions/runs/438470126 ) as we've gained quite rich experience with them implementing GA for
libvcxforkaries-vcx- see example of our CI run https://github.com/hyperledger/aries-vcx/runs/1595971044
I agree @Patrik-Stas that this not be done or be done carefully -- that's what my suggested changes are about.
The GA changes are welcome, but in our opinion, the indy-node (and related repos) are more crucial at this time. If you and your team have GA experience, we would love your help on that.
@Patrik-Stas That is a generous offer, and resolves one of the biggest concerns with the Indy SDK. I welcome your team's contribution!
However, I still think a message like this is needed. By making it clear that the Indy SDK needs new maintainers, people will know that they either need to pitch in, or move on.
There are many useful PRs, but no one to review them. The list of unresolved issues in this repo is growing, and doesn't include the many issues in Jira that were thrown away. Many of the wrappers are very out-of-date. And there are reports that it doesn't build on the latest Ubuntu.
Your effort to migrate Indy SDK to GitHub Actions will significantly lower the cost of new contributions. I hope that others choose to join you and that it breathes new life into the project. If you decide that you want to take full ownership over the repo, I'll close this PR and encourage my team to keep contributing as well.
There are three components that have been created as an alternative to the indy-sdk:
- indy-vdr enables integration with the ledger. It can be run embedded in an app or as a service with an API
- https://github.com/hyperledger/indy-vdr
- indy-shared-rs implements the crypto (including AnonCreds) for indy by wrapping Ursa
- https://github.com/hyperledger/indy-shared-rs
- the storage in indy (unfortunately called "indy-wallet") can be replaced by aries-askar within Aries frameworks
- https://github.com/hyperledger/aries-askar
These components are complete but have not been used in other than test scenarios. Once the next version of ACA-Py is released, we'll be adding support for these into main so that they can be used in production use cases.
Also being added in different Aries frameworks are ways to use different ledgers and different verifiable credential formats.
As noted in comments above, ABSA and others is likely to continue to evolve the indy-sdk and to continue to release it.
@ianco @Patrik-Stas -- do either of you know how to get the pre-merge checks to pass?
@ianco @Patrik-Stas -- do either of you know how to get the pre-merge checks to pass?
In this case it's the android tests failing. I think this happens randomly and we just need to tell (ci) to please re-run the tests
