Date   

Re: Iroha DCO update

Nikolay Yushkevich <nikolai@...>
 

Happy to hear that!

I am currently away for a short vacation — someone from the team might jump in and help now. Let me check this after Monday next week.

Nikolai

On 28 Mar 2019, at 09:35, Dave Huseby <dhuseby@...> wrote:

Hi TSC,

I just completed an updated DCO audit of Iroha. The list of people we should try to contact is now down to 10. I got there by taking all of the Iroha repos and finding all of the commits that do *not* have the "Signed-off-by" metadata that occurred before June 5, 2017.  The reason for the date cutoff is that between June 5, 2017 and April 12, 2018, we were using the CLA Assistant and any commits between those dates that does not have the "Signed-off-by" metadata is OK. Only commits prior to June 5, 2017 that do not have the "Signed-off-by" are a problem.

I have sent the list to Nikolai to see if they can contact those authors and get emails from them stating that they accept the DCO and declare that it applies to their commits.

Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Iroha DCO update

Dave Huseby <dhuseby@...>
 

Hi TSC,

I just completed an updated DCO audit of Iroha. The list of people we should try to contact is now down to 10. I got there by taking all of the Iroha repos and finding all of the commits that do *not* have the "Signed-off-by" metadata that occurred before June 5, 2017.  The reason for the date cutoff is that between June 5, 2017 and April 12, 2018, we were using the CLA Assistant and any commits between those dates that does not have the "Signed-off-by" metadata is OK. Only commits prior to June 5, 2017 that do not have the "Signed-off-by" are a problem.

I have sent the list to Nikolai to see if they can contact those authors and get emails from them stating that they accept the DCO and declare that it applies to their commits.

Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Re: CI/CD and testnets proposal for discussion tomorrow

Dave Huseby <dhuseby@...>
 

To Shawn,

This idea is based off of what Sovrin has set up for Ursa. Mike Lodder had done the bulk of the legwork here and deserves most of the credit...unless you guys hate the proposal, then blame me, it was my idea to propose to take this HL-wide. Ursa is hosted on HL github, uses HL Jira/Confluence, and now uses a temporary Gitlab (CE version) running on Sovrin infrastructure. This is after Sovrin spent months trying to take the existing HL CI/CD stuff and failing to modify it for Indy and Ursa.

To Casey,

In the proposal I say that the best part of Gitlab is that runners can be contributions from the community. HL will run a couple of shared runners to make sure that projects without community provided runners will have a minimum level of CI/CD capabilities.  We will run the CE version because all we need is AD/LDAP integration so we can use LFID's as well as the CI/CD pipeline. In summary, the gitlab would be running on HL infrastructure, the runners on community contributed hardware.  

I just set up a spare machine as a runner for the Ursa builds and plugged it into the Sovrin Gitlab in just a few minutes.

Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


On Wed, Mar 27, 2019 at 3:42 PM Casey Kuhlman <casey@...> wrote:
Dave, 

Can you elaborate on the proposed direction of travel regarding testnets? Is the idea that HL will run a CE instance of Gitlab in some infrastructure or that gitlab.com will be the instance? If the latter where are the runners going to live infrastructure wise? If in gitlab.com's infrastructure that would be fine for CI from our (Burrow's) perspective, but won't be ideal for testnets due to CI timeouts. 

For burrow we have extensive helm charts, gitlab CI configs, and testnet / stressnet mechanisms built already which we operate from Monax's self hosted Gitlab in our Kubernetes cluster. So in general this direction of travel gets a ++ from me. If we (burrow maintainers) have access to running testnets / stressnets in a Kubernetes cluster that's not Monax's via Gitlab CI we would be very happy campers indeed.

Thanks in advance,
~Casey

On Wed, Mar 27, 2019, 22:12 Shawn Amundson <amundson@...> wrote:
Sounds cool. Perhaps we could do an evaluation period were projects can evaluate using the gitlab setup to determine if it is sufficient to replace existing tooling, with the intent to report back on the experience to the TSC. Is Ursa already using this setup? How much effort would it take from HL staff to do such a evaluation period?

-Shawn

On Wed, Mar 27, 2019 at 4:04 PM Dave Huseby <dhuseby@...> wrote:
Hi TSC,

I put together a summary with details on what I propose we do to rework the HL CI/CD pipeline. The proposal can be found here: https://wiki.hyperledger.org/display/HYP/Software+Delivery

As usual, comment there, discuss here.

Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Re: CI/CD and testnets proposal for discussion tomorrow

Casey Kuhlman
 

Dave, 

Can you elaborate on the proposed direction of travel regarding testnets? Is the idea that HL will run a CE instance of Gitlab in some infrastructure or that gitlab.com will be the instance? If the latter where are the runners going to live infrastructure wise? If in gitlab.com's infrastructure that would be fine for CI from our (Burrow's) perspective, but won't be ideal for testnets due to CI timeouts. 

For burrow we have extensive helm charts, gitlab CI configs, and testnet / stressnet mechanisms built already which we operate from Monax's self hosted Gitlab in our Kubernetes cluster. So in general this direction of travel gets a ++ from me. If we (burrow maintainers) have access to running testnets / stressnets in a Kubernetes cluster that's not Monax's via Gitlab CI we would be very happy campers indeed.

Thanks in advance,
~Casey

On Wed, Mar 27, 2019, 22:12 Shawn Amundson <amundson@...> wrote:
Sounds cool. Perhaps we could do an evaluation period were projects can evaluate using the gitlab setup to determine if it is sufficient to replace existing tooling, with the intent to report back on the experience to the TSC. Is Ursa already using this setup? How much effort would it take from HL staff to do such a evaluation period?

-Shawn

On Wed, Mar 27, 2019 at 4:04 PM Dave Huseby <dhuseby@...> wrote:
Hi TSC,

I put together a summary with details on what I propose we do to rework the HL CI/CD pipeline. The proposal can be found here: https://wiki.hyperledger.org/display/HYP/Software+Delivery

As usual, comment there, discuss here.

Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Re: CI/CD and testnets proposal for discussion tomorrow

Shawn Amundson
 

Sounds cool. Perhaps we could do an evaluation period were projects can evaluate using the gitlab setup to determine if it is sufficient to replace existing tooling, with the intent to report back on the experience to the TSC. Is Ursa already using this setup? How much effort would it take from HL staff to do such a evaluation period?

-Shawn

On Wed, Mar 27, 2019 at 4:04 PM Dave Huseby <dhuseby@...> wrote:
Hi TSC,

I put together a summary with details on what I propose we do to rework the HL CI/CD pipeline. The proposal can be found here: https://wiki.hyperledger.org/display/HYP/Software+Delivery

As usual, comment there, discuss here.

Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


CI/CD and testnets proposal for discussion tomorrow

Dave Huseby <dhuseby@...>
 

Hi TSC,

I put together a summary with details on what I propose we do to rework the HL CI/CD pipeline. The proposal can be found here: https://wiki.hyperledger.org/display/HYP/Software+Delivery

As usual, comment there, discuss here.

Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Moving Indy from incubation to active status.

Nathan George <nathan.george@...>
 

I am pleased to announce that last week Hyperledger Indy finished the last outstanding CII badge requirement, and with that last hurdle cleared, we believe the project is ready to move from incubating to active status and would like to put it before the Hyperledger TSC for a vote.  As you might remember, Indy was the admitted just prior to Fabric's 1.0 release with the unusual circumstance of having already released its 1.0 in 2016.  Indy-SDK stable release is now at 1.8, and the ledger code is currently at 1.6, with new updates coming soon and a 2.0 release of the SDK planned for later this summer.

More information about status readiness can be found on our incubation graduation notes page (now located on the wiki) here: https://wiki.hyperledger.org/display/indy/Request+to+exit+Incubation+status+for+Hyperledger+Indy

When the Sovrin Foundation moved its identity code-base to Hyperledger just over two years ago the project was primarily sponsored by Evernym, where I was employed.  Since then I was hired away from Evernym to work for the Sovrin Foundation, where we facilitate vendor-neutral open standards to make self-sovereign identity available around the world.  And while Evernym continues to be the largest contributor to the open source system, we have been joined by developers from many additional organizations.  The Hyperledger Indy project now boasts over 150 contributors all time with over 40 active contributors having merged code over the last three months.  Including the related sovrin-foundation, BCGov and streetcred-id repositories, our OpenSSI code bases have passed 200 unique github (code and specification) contributors, with many more volunteers working on policy, governance and other adoption initiatives.  We are very grateful to the community for their contributions and the progress it continues to enable.

-Nathan George
Hyperledger Indy Maintainer


Hyperledger Ursa Quarterly Update Due #tsc-project-update - Thu, 03/28/2019 #tsc-project-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder:
Hyperledger Ursa Quarterly Update Due #tsc-project-update

When:
Thursday, 28 March 2019

Organizer:
community-architects@...

Description:
The Hyperledger Ursa update to the TSC was due March 25, 2019, and it will be presented to the TSC on March 28, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.

View Event


Recap of the Identity WG Call 2019-03-20

Vipin Bharathan
 

Hi all,

A brief recap of the experiment conducted on the 20th which was to have two calls with roughly the same Agenda at different times to spur participation across the globe. Also, evangelized on other SIGs and working groups to have cross pollination.

The Identity WG calls had a lot of discussion and two compelling presentations on DiDs and related technologies (SSI). Please look at the meeting notes and recordings to get a sense of the depth of the analysis, questions, connections drawn.

We invite Identity experts from all of the DLTs in Hyperledger and elsewhere to give their views and guide us in what Enterprises are expecting today as far as Identity Management systems go and their pain-points and their solutions. Also useful would be insight into actual use cases and their plans to integrate divided Identity systems.  

We will continue the two call format going forward; the next call(s) on the 3rd of April.
- There will be a presentation on the India Community Group on April 1(sic) on the ID WG; 
- Updated paper is being driven towards a draft version.

Suggested Agenda for the next call :

1. Demo of universal resolver by DiF
2. Convergence of solutions (DiF, Solid and others), how they affect us 
3. Layer 2 Identity protocols (for privacy of data and meta-data)- common effects
4. Roadmap towards an Agent 2 Agent protocol
5. Digital Wallets and their importance for Identity Management

Suggestions and comments are welcome.

Best,
Vipin  
 


Internship survey is out

Dave Huseby <dhuseby@...>
 

Hi TSC,

I just sent out the final survey to the Internship selection committee. They have today to fill it out. I will report the final selections tomorrow to this list.

Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Re: Agenda Reminder

Brian Behlendorf
 

On 3/21/19 7:05 AM, Mic Bowman wrote:
also without sounding too snarky... i would suggest that the access controls on that page are broken. for something as important as the agenda, it seems rather important to have a single owner who can coordinate updates.
I understand the concern; but since all writes require a login (as opposed to anonymous), the version history is kept, and authors being notified on edits (and others like me who subscribe to the whole wiki change stream) the general principle of allowing edits still seems to outweigh the risks.  Though, I think it's worth locking some pages from time to time, like agendas for meetings past, meeting notes, or accepted new project proposals, so that no further edits are allowed.

and... fwiw... offline i asked silona for permission to edit, we discussed the right way to edit, and i added the link to Dave's document into his work item in the backlog.
Ah!  Had missed that, though it seemed germane to the topic on the agenda.

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: Agenda Reminder

Mic Bowman
 

also without sounding too snarky... i would suggest that the access controls on that page are broken. for something as important as the agenda, it seems rather important to have a single owner who can coordinate updates.

and... fwiw... offline i asked silona for permission to edit, we discussed the right way to edit, and i added the link to Dave's document into his work item in the backlog.

--mic


On Wed, Mar 20, 2019 at 11:33 PM Brian Behlendorf <bbehlendorf@...> wrote:
Without trying to sound too snarky, there is an edit button in the upper right when you're logged in.  To atone for any inadvertant snark, I've added those links myself, aside from Arnaud's.

Brian

On 3/20/19 10:34 AM, Mic Bowman wrote:
Hi Silona!

Just trying to extract all the material from the mailing lists... Could you add into the agenda page the link to Dave's 1.0 criteria document (this one: https://wiki.hyperledger.org/display/HYP/Project+Readiness)? Also, Chris published the Fabric 1.0 criteria... that would be useful background material to capture (https://wiki.hyperledger.org/display/fabric/Release+Exit+Criteria). And.. Arnaud, have you had a chance to document your thoughts? 

--mic


On Wed, Mar 20, 2019 at 9:18 AM Silona Bonewald <sbonewald@...> wrote:

Remember you can suggest items for the TSC Agenda here.

Big item this time is going to be Iroha.

Thank you!
Silona

--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: Agenda Reminder

Christopher Ferris <chris.ferris@...>
 

Regrets, I’ve been pulled into a client briefing this morning.

Chris

On Mar 20, 2019, at 1:34 PM, Mic Bowman <cmickeyb@...> wrote:

Hi Silona!

Just trying to extract all the material from the mailing lists... Could you add into the agenda page the link to Dave's 1.0 criteria document (this one: https://wiki.hyperledger.org/display/HYP/Project+Readiness)? Also, Chris published the Fabric 1.0 criteria... that would be useful background material to capture (https://wiki.hyperledger.org/display/fabric/Release+Exit+Criteria). And.. Arnaud, have you had a chance to document your thoughts? 

--mic


On Wed, Mar 20, 2019 at 9:18 AM Silona Bonewald <sbonewald@...> wrote:

Remember you can suggest items for the TSC Agenda here.

Big item this time is going to be Iroha.

Thank you!
Silona

--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


Re: Agenda Reminder

Brian Behlendorf
 

Without trying to sound too snarky, there is an edit button in the upper right when you're logged in.  To atone for any inadvertant snark, I've added those links myself, aside from Arnaud's.

Brian

On 3/20/19 10:34 AM, Mic Bowman wrote:
Hi Silona!

Just trying to extract all the material from the mailing lists... Could you add into the agenda page the link to Dave's 1.0 criteria document (this one: https://wiki.hyperledger.org/display/HYP/Project+Readiness)? Also, Chris published the Fabric 1.0 criteria... that would be useful background material to capture (https://wiki.hyperledger.org/display/fabric/Release+Exit+Criteria). And.. Arnaud, have you had a chance to document your thoughts? 

--mic


On Wed, Mar 20, 2019 at 9:18 AM Silona Bonewald <sbonewald@...> wrote:

Remember you can suggest items for the TSC Agenda here.

Big item this time is going to be Iroha.

Thank you!
Silona

--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

Dan Hyperledger
 

I believe a production ready release should imply that the project embodies mature technology and open source practices including community. That is, the project is ready to use in production because the code and the community which maintains it are sound.

Additionally, the assessment of what constitutes mature for a project will continue to evolve with the maturity of this field as a whole.

In the specific case of Iroha and its active status, I recall an optimistic judgement that graduating Iroha would foster more community growth. That has not yet been the case. I'm reluctant to repeat that same calculus hoping for a different result. 

Regards,
Dan Middleton


On Wed, Mar 20, 2019 at 9:00 AM Christopher Ferris <chris.ferris@...> wrote:
Fabric had a set of release criteria for 1.0 documented here: 

These aren't Hyperledger criteria, these were what the maintainers came up with as a measure of 
maturity suitable for what we felt to be a 1.0 GA release.

I agree we are in a difficult position having already allowed Iroha to graduate to Active status.
While the full discussion is omitted, when we reviewed the request to graduate to Active status, we did
have a discussion of the diversity of contributors. If memory serves, there was a desire to continue to drive diversity
of contributor, and that resulted in DaveH visiting with the team to help them become more integrated
with the broader community. At the time, there were a few individual contributors that had fixed bugs etc,
yet if I look at the most recent 6 months, the contributions are almost exclusively from Soramitsu.

Here we are with a request to go to 1.0, and while the code may be robust, the diversity of contributing
organizations is actually much worse than it was reported at the request to graduate.

So, while I am in agreement that 1.0 should be a measure of maturity of the code, I really think that we need to reconsider how we evaluate requests to graduate. I also think that all of our projects need to double down on growing diversity of contributors and maintainers.

Chris


On Fri, Mar 15, 2019 at 10:58 AM Arnaud Le Hors <lehors@...> wrote:
I essentially agree with Dave. I think we found ourselves in an odd situation with Iroha in Active status without a diverse community of contributors but, pending resolution of the CDO issue, apparently ready for a 1.0 release.

I can't say that I know where Dave's criteria for a 1.0 release come from. While we have a fairly precise definition of what it takes for a project to move out of Incubation into Active status [1] I don't think we have anything similar for a 1.0 release, do we?

The key thing here is that the status of a project is meant to be representative of how the project operates, whether it has a good methodology, test suites, etc, independently of the maturity of the software being developed. One key criteria for moving out of incubation is to have a diversity of contributors. In Iroha's request to move out of incubation [2] it was stated that this was the case but that no longer seems to be true.

It's important to remember that we have agreed that in some cases we might allow for a project to have a 1.0 release (aka First Major Release) while still being in Incubation. [3]

On the face of today's situation, it would seem that the right thing to do is indeed to move the project back into Incubation - even though that's not a transition we had anticipated in the Project Lifecycle [4] - and allow for the release of Iroha 1.0.

[1] https://wiki.hyperledger.org/display/HYP/Project+Incubation+Exit+Criteria
[2] https://docs.google.com/document/d/1Vi_Ii0omj8lqjt-tdwIiEQPSku8V5DEku2aS5lr1Vo0/edit#
[3] https://wiki.hyperledger.org/display/HYP/Project+Lifecycle#ProjectLifecycle-first_major_release
[4] https://wiki.hyperledger.org/display/HYP/Project+Lifecycle
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Dave Huseby" <dhuseby@...>
To:        "hmontgomery@..." <hmontgomery@...>
Cc:        Vipin Bharathan <vipinsun@...>, Hyperledger List <tsc@...>
Date:        03/15/2019 05:18 AM
Subject:        Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Sent by:        tsc@...




Here's my 2p on this:

I think the "status" of a project (e.g. "inactive", "incubation", "active", etc) is about the status of the community. A project in the incubation phase is one that has a small core of developers working on a minimum viable product. Typically this is a group of students at the same university or a group of employees at the same company. Moving from incubation to active happens when the project's community outgrows that initial core group and has enough critical mass that the original creators could leave the project and it would keep going.

The authorization to release a 1.0 major release is based on all of the technical aspects of the project. Off the top of my head, that list includes the CII badge, public code repo, public mailing list, some form of CI/CD, public bug tracker, public roadmap, an outside security audit, and some form of change management system (e.g. 2+2 reviews) full DCO compliance, training/educational materials for bootcamps and webinars as well as online documentation.

By applying these standards, I think the appropriate position for the Iroha project is to be in "incubation" but to approve a 1.0. I think Chris demonstrated that the contributions are still 99.9% Soramitsu. I would push back a little and also look for the stats over the last quarter and last two quarters as a more accurate measure of their community diversification. I agree with Chris that a plan is good but actually diversification should be demonstrated.

I also believe that the Iroha team has met all of the technical standards for a 1.0. The code base is solid and real projects are being built.

If we flag Iroha as in "incubation" while releasing a 1.0, not only will it more closely reflect reality, but it also mirrors the status of other Hyperledger projects such as Indy. Indy has been diversifying their contributor and maintainers considerably over the last few quarters and is about to move out of incubation even though Indy node is nearing its 2.0 release.

I disagree that it will harm Iroha diversification efforts to move back to "incubation" status. What is more important is to put out a solid 1.0 release and building relationships with people and organizations that can now take an enterprise-ready Iroha and build things with it. In many ways, I would expect that most projects will reach 1.0 before they have enough critical mass to move out of incubation. In fact, I think that the critical mass actually happens as a result of putting out a solid 1.0.

Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


On Thu, Mar 14, 2019 at 10:41 AM hmontgomery@...<hmontgomery@...> wrote:
Hi Everyone,

 

Thanks for the suggestion Vipin.  Could we define more rigorous metrics for this (or at least suggestions, with perhaps some gray area)?

 

Putting on my Ursa hat, at some point in the hopefully not too distant future we’ll want to push forward with these things.  Having the knowledge of specific requirements (and whether we’ve met them or not, or whether it is borderline) would be immensely useful.  Putting on my TSC hat, I really want to avoid having to repeat this discussion again and again (a la the “improving the hackfests” discussions over the years), so coming up with something solid and writing it down is really appealing.

 

Thanks,

Hart

 

From: tsc@...[mailto:tsc@...] On Behalf Of Vipin Bharathan
Sent:
Thursday, March 14, 2019 9:04 AM
Cc:
Hyperledger List <
tsc@...>
Subject:
[Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 

Hi all,

 

As suggested in today's tsc meeting I am raising the question Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

Are numbers like the number of lines of code (or equivalent measures) from companies available at time of 1.0 (in active) available for other frameworks that already passed this milestone?

 

Another interesting statistic would be increase in contributor diversity SINCE 1.0.

Just to ensure that criteria are applied fairly for all projects in 1.0. And to see whether adoption is linked to 1.0 announcement.

 

Please put this on next week's agenda.

 

Regards,

Vipin

 

Also added as comment on the Agenda.





Event: Hyperledger Sawtooth Quarterly Update Due #tsc-project-update - Thursday, 11 April 2019 #tsc-project-update #cal-invite

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Hyperledger Sawtooth Quarterly Update Due #tsc-project-update

When:
Thursday, 11 April 2019

Organizer:
community-architects@...

Description:
The Hyperledger Sawtooth update to the TSC was due April 8, 2019, and it will be presented to the TSC on April 11, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Event: Hyperledger Fabric Quarterly Update Due #tsc-project-update - Thursday, 4 April 2019 #tsc-project-update #cal-invite

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Hyperledger Fabric Quarterly Update Due #tsc-project-update

When:
Thursday, 4 April 2019

Organizer:
community-architects@...

Description:
The Hyperledger Fabric update to the TSC was due April 1, 2019, and it will be presented to the TSC on April 4, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Updated Event: Hyperledger Ursa Quarterly Update Due #tsc-project-update - Thursday, 28 March 2019 #tsc-project-update #cal-invite

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Hyperledger Ursa Quarterly Update Due #tsc-project-update

When:
Thursday, 28 March 2019

Organizer:
community-architects@...

Description:
The Hyperledger Ursa update to the TSC was due March 25, 2019, and it will be presented to the TSC on March 28, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Updated Event: Hyperledger Caliper Quarterly Update Due #tsc-project-update - Thursday, 21 March 2019 #cal-invite #tsc-project-update

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Hyperledger Caliper Quarterly Update Due #tsc-project-update

When:
Thursday, 21 March 2019

Organizer:
community-architects@...

Description:
The Hyperledger Caliper update to the TSC was due March 18, 2019, and it will be presented to the TSC on March 21, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Updated Event: Hyperledger Grid Quarterly Update Due #tsc-project-update - Thursday, 2 May 2019 #tsc-project-update #cal-invite

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Hyperledger Grid Quarterly Update Due #tsc-project-update

When:
Thursday, 2 May 2019

Organizer:
community-architects@...

Description:
The Hyperledger Grid project update to the TSC was due April 29, 2019, and it will be presented to the TSC on May 2, 2019. Please review prior to the meeting and bring your questions.

1761 - 1780 of 3898