Date   

Brasil Bootcamp - Details and Ask

Karen Ottoni
 

Hi Everyone,

My apologies I had sound issues on the call earlier today. To recap what Daniela said, we're organizing the next bootcamp to take place in São Paulo, Brazil on June 24-25th. We are currently bringing together a core set of session leaders to ensure we'll have enough base content for the bootcamp before we announce it publicly for session proposals and registration late next week.

What we'd love from this community:
  1. Volunteer to lead a session! The Hyperledger Brasil community is very much budding and this would be a great way to onboard new contributors and diversify your community. We've got some local Fabric and Indy knowledge, but the more frameworks and tools the better. If you know of anyone to suggest to us please reach out.
  2. Mentor a session leader! Since it is a budding community there may not be representation of many of our projects, but this can be mitigated through mentoring so that someone locally is trained up over the next month to be able to do a 101 or intro session on your specific technology.
If you have any ideas or suggestions for the above please reach out to me, kottoni@... and Silona, sbonewald@....

Please also check out our Wiki to stay abreast of activities and how the agenda is being developed.

Thank you,
Karen


Karen L. Ottoni

Director of Ecosystem, Hyperledger
hosted by The Linux Foundation
Mobile: +1 919 699 8905
Website: http://hyperledger.org


Identity WG

Vipin Bharathan
 

Hello all,
As we have had some cancellations of calls we have not had the opportunity to report on the Identity Working Group paper. We also have a backlog of presentations (see below). This is a rough road map for efforts for the short term. Please remember we will have a call on May 29th.


There has been some progress on the paper which I report below.
  • Added some more text to the Identity WG paper and cleaned up the PSD2 section, 
  • lots of edits contributed by @mcemkilinc  getting the latest thoughts into analyzing the different identity models. 
  • Starting to write the DID section and will add Aries. 
  • Got a rough edit on the Iroha section, I will add that as well, thanks to Anton Khvorov from Iroha. 
Additional work projected to be done by May 29 (which is the date for our next call)

Fabric writeup
MiFID review
DiD writeup

Calling for contributions from Burrow, Quilt and others, also reviews before we integrate the paper into github for more  control (maybe in about a month)

Please comment or respond to this email.

Best,
Vipin


Re: Projects and Subprojects

Christopher Ferris <chrisfer@...>
 

This is a good discussion, and I am sorry I will miss the call.
 
I think that sub-projects is an interesting thought, but we kind of have that now, do we not?
I agree that there isn't necessarily consistency, but that is due to the fact that we allowed projects
to expand their repo footprint to support not only new features but refactoring, etc.
 
I do agree that it would be useful to have a more formal relationship between (sub)projects such as SDKs and the related top-level project(s) such that there can be a more formal path to integration into the formal release process. Of course, as each top-level project has its own governance, it is less clear how this would play out.
 
Frankly, I think that before we add in any additional top level framework projects, we should have a good long think about the implications.
 
As to Hart's last point, I think that the TSC and community architects should invest more time and energy in working on how we can encourage more organic cross-project interaction/integration/etc and that discussion should include the maintainers/leads of the various top level projects as they are most certainly invested in any outcome and have important insights that we should take under advisement.
 
Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402
 
 

----- Original message -----
From: "Silas Davis via Lists.Hyperledger.Org" <silas=monax.io@...>
Sent by: tsc@...
To: "hmontgomery@..." <hmontgomery@...>
Cc: tsc@...
Subject: [EXTERNAL] Re: [Hyperledger TSC] Projects and Subprojects
Date: Thu, May 23, 2019 4:42 AM
 
Thanks for putting this together Hart, the history is useful. Sorry for taking nearly 3 weeks to respond to it.
 
It seems like there are a few different resources that people are concerned with when thinking about projects, some of which are necessarily scarce and some of which are artificially scarce:
 
- TSC time
- Developer time
- Community support
- Political will
- Brand value/Attention
- Consumables (hosting, CI/CD, stickers, etc)
 
To scale the number of projects we need away to allocate these resources fairly and to maximise the resources a project brings with it (in terms of developer and community effort).
 
Looking at Brian's and other's previous statements it seems the desire for a flat project structure is motivated by giving all projects formal structures in terms of wiki, roadmap, maintainers and also opening the possibility of cross-project work. In practice it seems for the latter often amounts to wishful thinking in the absence of clear plans and motivation to do so.
 
It seems to me (though I haven't been around here long) that often new projects tend to have their origins/support from people in an existing top-level project (I think this has to do with the political will resource...) in which case it might be natural for a new project to 'report to' or be associated with an established project for the purposes of quarterly reviews and elements of governance and perhaps sharing resources (consumables and developer time. This would have the effect of scaling the amount of projects we could support and would give some kind of responsibility to the 'mentoring' projects.
 
The project/sub-project relationship seems to equate technical subsumption/sub-ordinance with an organisational subdivision. Could these concerns be meaningfully separated? Though it occurs to me as I write this that I might just be describing incubation with a twist... Also if a project is completely technically independent it might not make sense to shoe-horn TSC updates and testing under the same umbrella. Where there is significant overlap however, as with Transact and Sawtooth (at the time of writing), from a practical point of view it would probably work well, it''s just that that project has scope that is different to, and goes beyond Sawtooth in general.
 
I think the other issue particularly for incumbent projects is what proliferation of top level projects does for the Hyperledger brand and the distribution of attention across projects. If there are projects that are less mature or lower quality at the top level what effect does that have on the perceived value of existing projects? What effect does that have on levels of contribution or use of projects in the wild?
 
Another issue I think I raised on a TSC call is we don't really have a way to prune top level projects, which would be another way to address proliferation. Currently it would seem rather mean and drastic to strip a project of top-level status, perhaps we could address that and encourage more top-level project 'startups' - maybe they return to incubation or get decommissioned after a certain period of time. Maybe that kind of churn would degrade trust in Hyperledger.
 
I have managed to write quite a few paragraphs there without providing any answers. So:
 
- I broadly think sub-projects are a good idea (whether by that name or not)
- If organising cacucusses of projects in a hierarchy for the purposes of reporting and governance (i.e. projects give TSC update together, projects share CI resources) makes sense in practice I would support it
 
Perhaps we don't have a problem acute enough to be worth solving today. But I'd be interested in people's thoughts on the negative effects of project proliferation in terms of the types of resources listed above.
 
Silas
 
On Thu, 2 May 2019 at 17:27, hmontgomery@... <hmontgomery@...> wrote:

Hi Everyone,

 

In light of today’s discussion at the TSC meeting, I wanted to write up some of my thoughts on the project approval process.  I apologize in advance for the wall of text, but I wanted to summarize a lot of things.  I’ll start with a bit of history (we have been around long enough for that to matter!) and then explain what I think we should do.

 

At some point two or (more like) three years ago, we had a number of discussions about new projects in Hyperledger.  We were beginning to get quite a lot of interest from people who wanted to have their own project.  At the time, the popular opinion was that we should be very inclusive as to what qualified for a project approval, and even things like SDKs for DLT platforms (i.e. a single language SDK for a single DLT platform) deserved their own projects.  For instance, here (https://lists.hyperledger.org/g/tsc/message/668?p=,,,20,0,0,0::relevance,,Fabric-Go-SDK,20,2,0,17551967) and here (https://lists.hyperledger.org/g/tsc/message/668?p=,,,20,0,0,0::relevance,,Fabric-Go-SDK,20,2,0,17551967 ) are archived emails from Brian explaining his thoughts on this.  I believe this was the most popular (or at least the most commonly expressed) opinion at the time.

 

However, there was some worry about too much project proliferation (which seems to be one of the main concerns today).  I recall proposing that we have a tiered project structure, with projects and sub-projects.  The goal of this was to allow for subproject independence (and to give subprojects all the independent tools they needed) without putting a huge burden on the TSC through too many projects.  I don’t know that I was the originator of this idea, but here is an email from me to TSC list at the time:  https://lists.hyperledger.org/g/tsc/message/681?p=,,,20,0,0,0::relevance,,RFC+1149,20,2,0,17551967.  This idea got shot down, though—people thought it was best to have a flat project hierarchy, in an approach more like Apache.

 

Of course, we all know what happened.  We approved a bunch of projects that really didn’t become independent at all.  Chris brought up Composer today in the TSC meeting as an example, but perhaps an even more illustrative example is the Fabric Java SDK.  From a purely rules-based perspective, this is still officially a top-level Hyperledger project!  You can see this email where we approved it:  https://lists.hyperledger.org/g/tsc/message/321?p=,,,20,0,0,0::relevance,,Fabric-Java-SDK,20,2,0,17551816.  It doesn’t function as a top-level project at all:  we have neglected to require updates from it at TSC meetings (or any of the other “new” requirements we have made of projects), and the governance, as far as I can tell, is done completely within Fabric.  But we also haven’t done anything official to take away its status as a fully independent, top-level Hyperledger project, so it is sitting in some kind of mixed state where it is officially an independent project but not one in practice at all.

 

And now we have come full circle.  Yet again, we are in a period where people have proposed a lot of new projects (which is definitely a good thing!) and others are worried about project proliferation.  Yet again, I’d like to bring up the topic of project tiers and sub-projects.  I am curious if opinions have changed over the past two or three years as Hyperledger has matured.

 

I would like to get people’s feedback on the following idea:  in the future, in addition to project proposals, we allow for sub-project proposals (and thus, sub-projects).  If you don’t like my naming conventions (looking at you Silona) please feel free to suggest something else.  We define a sub-project to be a project that is exclusively dependent on or forked from a single (higher-level) project. Sub-projects have all of the tools available to them that regular projects do, but could potentially have slightly different governance:  they could do some reporting to the higher-level project, rather than directly to the TSC (although the TSC can step in to manage disputes as necessary), which would decrease the burden on the TSC.  If a sub-project matures to the point where it works with/supports/is used for multiple higher tier projects, then it should be promoted to full project without extensive discussion.  We can also allow the TSC to (with fair warning) demote projects that only support one higher-tier project into sub-projects.

 

The upside of this is that Hyperledger could support more projects this way (even the Fabric-Java-SDK, for instance, could be a sub-project), giving people perhaps more incentive to take ownership and try building new things.  Outsiders could very clearly see the project structure and how things work as well, and we could market sub-projects effectively too if this was desired or needed.  The downside of the hierarchical project structure is that it may decrease cross-project interaction as people might see sub-projects as part of a different project and not something to interoperate with (this was my interpretation of the core of Brian’s argument two and a half years ago).  Over time, I think we have learned that cross-project interaction doesn’t really seem to happen organically or spontaneously—it takes a lot of effort and, at least for Hyperledger, seems to take some central planning by project maintainers.  So I’m not sure this argument turned out to be correct.  

 

What do people think about this?  Is this reasonable?  Should we just continue with the flat project hierarchy?  Is there some other way to gracefully handle project proliferation?  I am curious to hear what people think about this.  I’m substantially less experienced in open source projects than many of the other people here, some of whom have been working on open source for longer than I have been alive, so it’s entirely possible that I am just completely missing the boat, and I welcome critical feedback.

 

If you’ve made it this far, thank you for reading, and sorry again for the wall of text. 

 

Thanks,

Hart

 

 

 

 

 


Re: Projects and Subprojects

Silas Davis
 

Thanks for putting this together Hart, the history is useful. Sorry for taking nearly 3 weeks to respond to it.

It seems like there are a few different resources that people are concerned with when thinking about projects, some of which are necessarily scarce and some of which are artificially scarce:

- TSC time
- Developer time
- Community support
- Political will
- Brand value/Attention
- Consumables (hosting, CI/CD, stickers, etc)

To scale the number of projects we need away to allocate these resources fairly and to maximise the resources a project brings with it (in terms of developer and community effort).

Looking at Brian's and other's previous statements it seems the desire for a flat project structure is motivated by giving all projects formal structures in terms of wiki, roadmap, maintainers and also opening the possibility of cross-project work. In practice it seems for the latter often amounts to wishful thinking in the absence of clear plans and motivation to do so.

It seems to me (though I haven't been around here long) that often new projects tend to have their origins/support from people in an existing top-level project (I think this has to do with the political will resource...) in which case it might be natural for a new project to 'report to' or be associated with an established project for the purposes of quarterly reviews and elements of governance and perhaps sharing resources (consumables and developer time. This would have the effect of scaling the amount of projects we could support and would give some kind of responsibility to the 'mentoring' projects.

The project/sub-project relationship seems to equate technical subsumption/sub-ordinance with an organisational subdivision. Could these concerns be meaningfully separated? Though it occurs to me as I write this that I might just be describing incubation with a twist... Also if a project is completely technically independent it might not make sense to shoe-horn TSC updates and testing under the same umbrella. Where there is significant overlap however, as with Transact and Sawtooth (at the time of writing), from a practical point of view it would probably work well, it''s just that that project has scope that is different to, and goes beyond Sawtooth in general.

I think the other issue particularly for incumbent projects is what proliferation of top level projects does for the Hyperledger brand and the distribution of attention across projects. If there are projects that are less mature or lower quality at the top level what effect does that have on the perceived value of existing projects? What effect does that have on levels of contribution or use of projects in the wild?

Another issue I think I raised on a TSC call is we don't really have a way to prune top level projects, which would be another way to address proliferation. Currently it would seem rather mean and drastic to strip a project of top-level status, perhaps we could address that and encourage more top-level project 'startups' - maybe they return to incubation or get decommissioned after a certain period of time. Maybe that kind of churn would degrade trust in Hyperledger.

I have managed to write quite a few paragraphs there without providing any answers. So:

- I broadly think sub-projects are a good idea (whether by that name or not)
- If organising cacucusses of projects in a hierarchy for the purposes of reporting and governance (i.e. projects give TSC update together, projects share CI resources) makes sense in practice I would support it

Perhaps we don't have a problem acute enough to be worth solving today. But I'd be interested in people's thoughts on the negative effects of project proliferation in terms of the types of resources listed above.

Silas


On Thu, 2 May 2019 at 17:27, hmontgomery@... <hmontgomery@...> wrote:

Hi Everyone,

 

In light of today’s discussion at the TSC meeting, I wanted to write up some of my thoughts on the project approval process.  I apologize in advance for the wall of text, but I wanted to summarize a lot of things.  I’ll start with a bit of history (we have been around long enough for that to matter!) and then explain what I think we should do.

 

At some point two or (more like) three years ago, we had a number of discussions about new projects in Hyperledger.  We were beginning to get quite a lot of interest from people who wanted to have their own project.  At the time, the popular opinion was that we should be very inclusive as to what qualified for a project approval, and even things like SDKs for DLT platforms (i.e. a single language SDK for a single DLT platform) deserved their own projects.  For instance, here (https://lists.hyperledger.org/g/tsc/message/668?p=,,,20,0,0,0::relevance,,Fabric-Go-SDK,20,2,0,17551967) and here (https://lists.hyperledger.org/g/tsc/message/668?p=,,,20,0,0,0::relevance,,Fabric-Go-SDK,20,2,0,17551967 ) are archived emails from Brian explaining his thoughts on this.  I believe this was the most popular (or at least the most commonly expressed) opinion at the time.

 

However, there was some worry about too much project proliferation (which seems to be one of the main concerns today).  I recall proposing that we have a tiered project structure, with projects and sub-projects.  The goal of this was to allow for subproject independence (and to give subprojects all the independent tools they needed) without putting a huge burden on the TSC through too many projects.  I don’t know that I was the originator of this idea, but here is an email from me to TSC list at the time:  https://lists.hyperledger.org/g/tsc/message/681?p=,,,20,0,0,0::relevance,,RFC+1149,20,2,0,17551967.  This idea got shot down, though—people thought it was best to have a flat project hierarchy, in an approach more like Apache.

 

Of course, we all know what happened.  We approved a bunch of projects that really didn’t become independent at all.  Chris brought up Composer today in the TSC meeting as an example, but perhaps an even more illustrative example is the Fabric Java SDK.  From a purely rules-based perspective, this is still officially a top-level Hyperledger project!  You can see this email where we approved it:  https://lists.hyperledger.org/g/tsc/message/321?p=,,,20,0,0,0::relevance,,Fabric-Java-SDK,20,2,0,17551816.  It doesn’t function as a top-level project at all:  we have neglected to require updates from it at TSC meetings (or any of the other “new” requirements we have made of projects), and the governance, as far as I can tell, is done completely within Fabric.  But we also haven’t done anything official to take away its status as a fully independent, top-level Hyperledger project, so it is sitting in some kind of mixed state where it is officially an independent project but not one in practice at all.

 

And now we have come full circle.  Yet again, we are in a period where people have proposed a lot of new projects (which is definitely a good thing!) and others are worried about project proliferation.  Yet again, I’d like to bring up the topic of project tiers and sub-projects.  I am curious if opinions have changed over the past two or three years as Hyperledger has matured.

 

I would like to get people’s feedback on the following idea:  in the future, in addition to project proposals, we allow for sub-project proposals (and thus, sub-projects).  If you don’t like my naming conventions (looking at you Silona) please feel free to suggest something else.  We define a sub-project to be a project that is exclusively dependent on or forked from a single (higher-level) project. Sub-projects have all of the tools available to them that regular projects do, but could potentially have slightly different governance:  they could do some reporting to the higher-level project, rather than directly to the TSC (although the TSC can step in to manage disputes as necessary), which would decrease the burden on the TSC.  If a sub-project matures to the point where it works with/supports/is used for multiple higher tier projects, then it should be promoted to full project without extensive discussion.  We can also allow the TSC to (with fair warning) demote projects that only support one higher-tier project into sub-projects.

 

The upside of this is that Hyperledger could support more projects this way (even the Fabric-Java-SDK, for instance, could be a sub-project), giving people perhaps more incentive to take ownership and try building new things.  Outsiders could very clearly see the project structure and how things work as well, and we could market sub-projects effectively too if this was desired or needed.  The downside of the hierarchical project structure is that it may decrease cross-project interaction as people might see sub-projects as part of a different project and not something to interoperate with (this was my interpretation of the core of Brian’s argument two and a half years ago).  Over time, I think we have learned that cross-project interaction doesn’t really seem to happen organically or spontaneously—it takes a lot of effort and, at least for Hyperledger, seems to take some central planning by project maintainers.  So I’m not sure this argument turned out to be correct.  

 

What do people think about this?  Is this reasonable?  Should we just continue with the flat project hierarchy?  Is there some other way to gracefully handle project proliferation?  I am curious to hear what people think about this.  I’m substantially less experienced in open source projects than many of the other people here, some of whom have been working on open source for longer than I have been alive, so it’s entirely possible that I am just completely missing the boat, and I welcome critical feedback.

 

If you’ve made it this far, thank you for reading, and sorry again for the wall of text. 

 

Thanks,

Hart

 

 


Perf and Scale Q2 update

mark wagner <mwagner@...>
 


Sorry for the delay. The update is here :

Some stuff we should probably have a discussion on at a TSC call in a week or two.

-mark
--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc


Re: Updated agenda for TSC call May 23, 2019

Christopher Ferris <chris.ferris@...>
 

Regrets, again. (sorry) Need to cover for someone at Congressional Blockchain Caucus Smart Contracts forum tomorrow.

Chris

On May 22, 2019, at 3:05 PM, Middleton, Dan <dan.middleton@...> wrote:

Thanks for putting this up, Dave.

 

How much time do you need for the DID topic?


Ry, same question on Convector, and is there any pre-read for that subject?

 

Thanks,

Dan

 

From: <tsc@...> on behalf of Dave Huseby <dhuseby@...>
Date: Tuesday, May 21, 2019 at 1:19 PM
To: Hyperledger List <tsc@...>
Subject: [Hyperledger TSC] Updated agenda for TSC call May 23, 2019

 

Hi TSC,

 

The agenda for the TSC meeting this Thursday has been updated. Check it out here:

 

 

We've got lots of reports coming in and some excited updates on a potential DCO solution as well as community health and dev certs.

 

Cheers!

Dave

 

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


Re: Updated agenda for TSC call May 23, 2019

Middleton, Dan <dan.middleton@...>
 

Thanks for putting this up, Dave.

 

How much time do you need for the DID topic?


Ry, same question on Convector, and is there any pre-read for that subject?

 

Thanks,

Dan

 

From: <tsc@...> on behalf of Dave Huseby <dhuseby@...>
Date: Tuesday, May 21, 2019 at 1:19 PM
To: Hyperledger List <tsc@...>
Subject: [Hyperledger TSC] Updated agenda for TSC call May 23, 2019

 

Hi TSC,

 

The agenda for the TSC meeting this Thursday has been updated. Check it out here:

 

 

We've got lots of reports coming in and some excited updates on a potential DCO solution as well as community health and dev certs.

 

Cheers!

Dave

 

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


Updated agenda for TSC call May 23, 2019

Dave Huseby <dhuseby@...>
 

Hi TSC,

The agenda for the TSC meeting this Thursday has been updated. Check it out here:


We've got lots of reports coming in and some excited updates on a potential DCO solution as well as community health and dev certs.

Cheers!
Dave

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


Upcoming Event: Hyperledger Technical WG China Quarterly Update Due #tsc-wg-update - Thu, 05/23/2019 #tsc-wg-update #cal-reminder

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

Reminder: Hyperledger Technical WG China Quarterly Update Due #tsc-wg-update

When: Thursday, 23 May 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Technical WG China update to the TSC was due 20 May, 2019, and it will be presented to the TSC on 23 May, 2019. Please review prior to the meeting and bring your questions.


Upcoming Event: Hyperledger Explorer Quarterly Update Due #tsc-project-update - Thu, 05/23/2019 #tsc-project-update #cal-reminder

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

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

When: Thursday, 23 May 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Explorer update to the TSC was due May 20, 2019, and it will be presented to the TSC on May 23, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Re: Hyperledger RocketChat is down

Tim Johnson <tijohnson@...>
 

Ricket Chat is back on-line.

On 5/20/19 8:53 AM, Tim Johnson via Lists.Hyperledger.Org wrote:
We are aware of the outage and are working on getting it back on-line.

Tim





Hyperledger RocketChat is down

Tim Johnson <tijohnson@...>
 

We are aware of the outage and are working on getting it back on-line.

Tim


Gerrit Server Downtime

Tim Johnson <tijohnson@...>
 

The gerrit upgrade was completed last night. You should now be seeing the new WEB page when you access gerrit.

Tim



-------- Forwarded Message --------
Subject: Gerrit Server Downtime
Date: Wed, 15 May 2019 16:47:52 -0700
From: Tim Johnson <tijohnson@...>
To: Hyperledger TSC <tsc@...>


What: Upgrade to Version 2.16.8

When: Sun May 19 23:00

Duration: 1hr

We have already performed this upgrade at several other customers and so
we expect the minimal problems with this upgrade. You will notice the
biggest change, which is a revamped GUI.

I will be sending out another reminder of this downtime on Sunday

Tim


Re: CI/CD update

mark wagner <mwagner@...>
 

I would go a bit further and say its something we should investigate. Note that Tekton has also been referred to as knative pipeline.


Also is anyone tied into the Continuous Delivery Foundation  ?
Seems to have recently formed by the Linux Foundation. Maybe some potential to work with them ?

https://cd.foundation/


-mark



On Wed, May 8, 2019 at 10:41 AM Christopher Ferris <chrisfer@...> wrote:
We should keep an eye on https://github.com/tektoncd 

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris

On May 8, 2019, at 12:26 AM, Dave Huseby <dhuseby@...> wrote:

Hi TSC,

After receiving feedback from many of you that you didn't think the CI/CD committee should be private, the CA team has decided to open it all up. I am keeping the one page with all of the outside CI/CD costs private to protect the confidentiality I promised when gathering expense information from companies currently paying to run Hyperledger CI/CD pipelines.

The CI/CD space can be found here:


You can see all of the ongoing research and ideas as well as the meeting minutes from our meetings. If you would like to participate, I am still looking for people to join the committee to help us work out solutions.

The biggest problem we face now is that many of the CI/CD pipelines for Hyperledger projects use docker-in-docker and docker-compose to first build their CI docker image and test it before running it to build the project code and test that. The current idea of airlifting existing pipelines onto a Hypereldger Kube cluster is blocked by the current docker-in-docker requirement.

Thanks to Mark, we have been thinking about how to get away from docker-in-docker since last October at the Montreal meetup. RedHat has a good solution called Buildah and there are a few others. We could really use help examining the different CI pipelines for the different projects to gauge the level of impact switching from docker-in-docker to something like Buildah would cause.

Kube is not a silver bullet. So the end recommendation from the committee should account for the cost moving all of the projects to a Kube cluster, in terms of estimated work hours and risk due to change.

If you can spare the cycles and know your project's CI pipeline fairly well, we could use your help.

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



--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc


Re: TSC Meeting 2019-05-16 Cancelled

Middleton, Dan <dan.middleton@...>
 

Your monitor probably just had some upside down pixels.  ;)

 

From: Ry Jones <rjones@...>
Date: Thursday, May 16, 2019 at 7:23 AM
To: Baohua Yang <yangbaohua@...>
Cc: Dan Middleton <dan.middleton@...>, "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] TSC Meeting 2019-05-19 Cancelled

 

Yes, the one on the 16th is cancelled

 

On Wed, May 15, 2019 at 9:50 PM Baohua Yang <yangbaohua@...> wrote:

Hi, Dan

I guess you meant 05-16?

 

On Wed, May 15, 2019 at 11:42 PM Middleton, Dan <dan.middleton@...> wrote:

Owing to a number of conference conflicts this week we are cancelling the TSC call.

 

Regards,

Dan Middleton

Hyperledger TSC Chair


 

--

Best wishes!


Baohua Yang


 

--

Ry Jones

Community Architect, Hyperledger


Re: TSC Meeting 2019-05-19 Cancelled

Ry Jones
 

Yes, the one on the 16th is cancelled


On Wed, May 15, 2019 at 9:50 PM Baohua Yang <yangbaohua@...> wrote:
Hi, Dan
I guess you meant 05-16?

On Wed, May 15, 2019 at 11:42 PM Middleton, Dan <dan.middleton@...> wrote:

Owing to a number of conference conflicts this week we are cancelling the TSC call.

 

Regards,

Dan Middleton

Hyperledger TSC Chair



--
Best wishes!

Baohua Yang



--
Ry Jones
Community Architect, Hyperledger


Re: TSC Meeting 2019-05-19 Cancelled

Baohua Yang
 

Hi, Dan
I guess you meant 05-16?

On Wed, May 15, 2019 at 11:42 PM Middleton, Dan <dan.middleton@...> wrote:

Owing to a number of conference conflicts this week we are cancelling the TSC call.

 

Regards,

Dan Middleton

Hyperledger TSC Chair



--
Best wishes!

Baohua Yang


Gerrit Server Downtime

Tim Johnson <tijohnson@...>
 

What: Upgrade to Version 2.16.8

When: Sun May 19 23:00

Duration: 1hr

We have already performed this upgrade at several other customers and so
we expect the minimal problems with this upgrade. You will notice the
biggest change, which is a revamped GUI.

I will be sending out another reminder of this downtime on Sunday

Tim


TSC Meeting 2019-05-19 Cancelled

Middleton, Dan <dan.middleton@...>
 

Owing to a number of conference conflicts this week we are cancelling the TSC call.

 

Regards,

Dan Middleton

Hyperledger TSC Chair


Re: Emergency shutdown of Jenkins servers (Now

Tim Johnson <tijohnson@...>
 

Emergency shutdown complete. Plugs have all been updated. Production &
sandbox both back on-line

On 5/14/19 7:41 AM, Tim Johnson wrote:
Emergency shutdown of Jenkins build servers required known security
issue in Jenkins that is actively being exploited

Once queues have be cleared they will be back on-line with about 10min

Tim

1641 - 1660 of 3898