Date   

Re: [Use Case] global trade

Mark Rakhmilevich
 

Don,

    See a couple additional examples of Fabric (Oracle’s platform) in our blog posts on GSBN in maritime shipping and Volvo Cars in electric vehicle battery supply chain.

 

Regards,

    Mark

 

From: Don Li <lichunshen84@...>
Sent: Thursday, December 12, 2019 3:03 PM
To: Brian Behlendorf <bbehlendorf@...>
Cc: fabric <fabric@...>
Subject: Re: [Hyperledger Fabric] [Use Case] global trade

 

Hi Brian,

 

Thank you very much for the thoughtful and informative response.  I'm delighted you expanded it to use case, which makes a lot of sense.  Since business endeavor involves two key parts of business case/motivation and technical implementation I feel it might be more productive to link these two together at some level instead of separating them as two different domains...

And since this is mostly a technical mailing list, for clarity, I'm adding [Use Case] to differentiate the discussion from usual technical discussion, and adding "global trade" to the end to indicate type of use case.  I hope business executives of various persuasion would join in discussion of Hyperledger Fabric use cases.  Or it would be nice if we could have a separate mailing list such as fabric-usecase@...   Just a thought.

 

Best,


Don

(Don) Chunshen Li

Virginia, US

 

On Thu, Dec 12, 2019 at 5:23 PM Brian Behlendorf <bbehlendorf@...> wrote:

Hi Don,

 

There are two SIGs that you may be interested in for answers to this, one for Trade Finance and another for Supply Chain kinds of projects.  These are not as technical as the developer mailing lists, but they do discuss use cases and deployments.

 

I also will note that many of the major trade dinance and supply chain projects out there - from We.Trade to Tradelens to the Food Trust Network, to the Everledger diamond ledger, Circulor's tantalum traceability network, Honeywell with parts for planes, etc - are using Fabric.

 

It's often a challenge to get folks to talk about the internal details of their network publicly, and we're trying to encourage them by putting together case studies on the Hyperledger web site that might be useful for you to peruse.

 

Brian

 

 

On 12/12/19 7:01 AM, Don Li wrote:

Hello,

 

I'm curious to know who (major corporations, global economic entities or even startups) or if any on the list are using Hyperledger Fabric for global trade for efficiency or other benefits?

Just fyi, I studied international trade when in college.

 

Thanks.


Don

(Don) Chunshen Li
Virginia, US

Your Subscription | Contact Group Owner | Unsubscribe [lichunshen84@...]

 

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


Re: changing merge rules

David Enyeart
 

We're live on NACR policy!


Dave Enyeart

"David Enyeart" ---12/13/2019 10:54:52 AM---Done! I'll forward to Hyperledger administrators to make the change to Fabric repo.

From: "David Enyeart" <enyeart@...>
To: Srinivasan Muralidharan <srinivasan.muralidharan99@...>
Cc: Brett T Logan <brett.t.logan@...>, chris.ferris@..., fabric@..., Jason K Yellick <jyellick@...>, Yacov Manevich <YACOVM@...>
Date: 12/13/2019 10:54 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Sent by: fabric@...





Done! I'll forward to Hyperledger administrators to make the change to Fabric repo.

Chris +1
Kostas +1
Gari +1
Yacov +1
Dave +1
Jay +1
Jason +1
Murali +1


Dave Enyeart

Srinivasan Muralidharan ---12/13/2019 10:47:53 AM---+1 ... from gerritt experiment we know its used for valid reasons. As long as we have enough eyes to

From:
Srinivasan Muralidharan <srinivasan.muralidharan99@...>
To:
David Enyeart <enyeart@...>
Cc:
Brett T Logan <brett.t.logan@...>, chris.ferris@..., fabric@..., Jason K Yellick <jyellick@...>, Yacov Manevich <YACOVM@...>
Date:
12/13/2019 10:47 AM
Subject:
[EXTERNAL] Re: [Hyperledger Fabric] changing merge rules




+1 ... from gerritt experiment we know its used for valid reasons. As long as we have enough eyes to validate big/critical changes and don't override comments and change requests, this should be good.

On Fri, Dec 13, 2019 at 10:41 AM David Enyeart <enyeart@...> wrote:
      Chris asked for a majority to respond with approval. If my counting is correct, we need one more maintainer to respond to finalize...

      Chris +1
      Kostas +1
      Gari +1
      Yacov +1
      Dave +1
      Jay +1
      Jason +1



      Dave Enyeart

      "Brett T Logan" ---12/12/2019 01:24:08 PM---What do we need to do to make this an official vote and relax the rules? It would be nice to have th

      From:
      "Brett T Logan" <brett.t.logan@...>
      To:
      "Jason K Yellick" <jyellick@...>
      Cc:
      chris.ferris@..., "David Enyeart" <enyeart@...>, fabric@..., "Yacov Manevich" <YACOVM@...>
      Date:
      12/12/2019 01:24 PM
      Subject:
      [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
      Sent by:
      fabric@...




      What do we need to do to make this an official vote and relax the rules? It would be nice to have this changed before the holiday's really get going. It's going to be harder than ever over the next month to get two +2's.


      Brett Logan

      Software Engineer, IBM Blockchain

      Phone:
      1-984-242-6890
      E-mail:
      brett.t.logan@...




----- Original message -----
From: "Jason Yellick" <jyellick@...>
Sent by:
fabric@...
To: "Yacov Manevich" <
YACOVM@...>
Cc:
chris.ferris@..., "David Enyeart" <enyeart@...>, fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Date: Wed, Dec 11, 2019 12:06 PM

+1

We had relaxed on Gerrit to allow self+2 on changes which did not merit additionally scrutiny, and this was a big improvement in productivity from my perspective. I think it's time we finally removed the second +2 entirely.

~Jason

----- Original message -----
From: "Yacov" <
yacovm@...>
Sent by:
fabric@...
To: "David Enyeart" <
enyeart@...>
Cc: "Christopher Ferris" <
chris.ferris@...>, fabric <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Date: Wed, Dec 11, 2019 2:28 AM


+1

I see having a more fine grained access control over who can merge changes to sub-components in the code as a natural extension of this policy change.



From:
"David Enyeart" <enyeart@...>
To:
"Christopher Ferris" <chris.ferris@...>
Cc:
fabric <fabric@...>
Date:
12/11/2019 09:11 AM
Subject:
[EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Sent by:
fabric@...



+1

Now that we are on GitHub we do have the option to use CODEOWNERS to further specify a set of reviewers with domain knowledge in certain areas of the code, but I think that could come later if we see a need for it in selective areas.
And agree with Yacov about when in doubt get a second review. We could use PR Assignee field to 'nominate' additional reviewers.


Dave Enyeart


"Christopher Ferris" ---12/10/2019 05:25:20 PM---We've brought this up before, but maybe it deserves to be revisited.

From:
"Christopher Ferris" <chris.ferris@...>
To:
fabric <fabric@...>
Date:
12/10/2019 05:25 PM
Subject:
[EXTERNAL] [Hyperledger Fabric] changing merge rules
Sent by:
fabric@...



We've brought this up before, but maybe it deserves to be revisited.

Originally, we added the 2+2 because there was a perception in the community that IBMers were being less critical of the contributions by other IBMers.

It served its purpose, but it does raise the bar and especially for obvious things that really don't merit the extra effort.

We have the abilities on GH to prevent self review.

Maybe the time has come as we have moved to GH that we think about lowering the bar and making it less burdensome on the maintainers that are doing reviews by allowing them to merge with a single NACR.

When there's a more substantive change, a maintainer can always seek additional eyes by adding reviewers.

I’d like to propose we go with a single NACR across the Fabric repo-scape.

Please respond on this thread if you concur, or have concerns. If we have a majority, we can ask Ry to make the necessary changes to the merge policy.


Chris









--
Thanks,
Murali
"Practice is a means of inviting the perfection desired." - Martha Graham
“We ran and ran. We were exhausted, but we kept running.” - Homare Sawa after winning 2011 Women's Soccer world cup






Re: Orderer Raft Multiple Channels

Nicholas Leonardi
 

Alright here's what's going on:

After I start the orderer of org2 AFTER adding it to the rbpchannel and system-channel from Org1:

2019-12-13 17:18:25.709 UTC [orderer.common.cluster] discoverChannels -> INFO 014 Discovered 2 channels: [rbpchannel ch2channel]
2019-12-13 17:18:25.709 UTC [orderer.common.cluster] channelsToPull -> INFO 015 Evaluating channels to pull: [rbpchannel ch2channel]
2019-12-13 17:18:25.709 UTC [orderer.common.cluster] channelsToPull -> INFO 016 Probing whether I should pull channel rbpchannel

2019-12-13 17:18:25.771 UTC [orderer.common.cluster.replication] pullBlocks -> INFO 02c Got block [2] of size 53 KB from 10.202.46.143:9050
2019-12-13 17:18:25.784 UTC [orderer.common.cluster] channelsToPull -> INFO 02d I need to pull channel rbpchannel
2019-12-13 17:18:25.784 UTC [orderer.common.cluster] channelsToPull -> INFO 02e Probing whether I should pull channel ch2channel

2019-12-13 17:18:25.796 UTC [orderer.common.cluster.replication] HeightsByEndpoints -> INFO 037 Returning the heights of OSNs mapped by endpoints map[]
2019-12-13 17:18:25.796 UTC [orderer.common.cluster] channelsToPull -> INFO 038 I do not belong to channel ch2channel or am forbidden pulling it (forbidden pulling the channel), skipping chain retrieval
2019-12-13 17:18:25.796 UTC [orderer.common.cluster] ReplicateChains -> INFO 039 Found myself in 1 channels out of 2 : {[{rbpchannel 0xc0003247c0}] [{ch2channel 0xc000402ac0}]}

2019-12-13 17:18:25.856 UTC [orderer.common.cluster] PullChannel -> INFO 045 Latest block height for channel rbpchannel is 4

2019-12-13 17:18:25.908 UTC [orderer.common.cluster] appendBlock -> INFO 051 Committed block [1] for channel rbpchannel
2019-12-13 17:18:25.944 UTC [orderer.common.cluster] appendBlock -> INFO 052 Committed block [2] for channel rbpchannel
2019-12-13 17:18:25.955 UTC [orderer.common.cluster] appendBlock -> INFO 053 Committed block [3] for channel rbpchannel
2019-12-13 17:18:25.955 UTC [orderer.common.cluster] PullChannel -> INFO 054 Pulling channel system-channel

2019-12-13 17:18:26.046 UTC [orderer.common.cluster] appendBlock -> INFO 067 Committed block [0] for channel system-channel
2019-12-13 17:18:26.058 UTC [orderer.common.cluster] appendBlock -> INFO 068 Committed block [1] for channel system-channel
2019-12-13 17:18:26.075 UTC [orderer.common.cluster] appendBlock -> INFO 069 Committed block [2] for channel system-channel
2019-12-13 17:18:26.117 UTC [orderer.common.cluster] appendBlock -> INFO 06a Committed block [3] for channel system-channel

2019-12-13 17:18:26.141 UTC [orderer.common.server] TrackChain -> INFO 06f Adding ch2channel to the set of chains to track
2019-12-13 17:18:26.153 UTC [orderer.consensus.etcdraft] HandleChain -> INFO 070 EvictionSuspicion not set, defaulting to 10m0s
2019-12-13 17:18:26.153 UTC [orderer.consensus.etcdraft] createOrReadWAL -> INFO 071 No WAL data found, creating new WAL at path '/var/hyperledger/production/orderer/etcdraft/wal/rbpchannel' channel=rbpchannel node=4
2019-12-13 17:18:26.163 UTC [orderer.consensus.etcdraft] Start -> INFO 072 Starting Raft node channel=rbpchannel node=4
2019-12-13 17:18:26.164 UTC [orderer.common.cluster] Configure -> INFO 073 Entering, channel: rbpchannel, nodes: [ID: 3,

2019-12-13 17:18:26.167 UTC [orderer.consensus.etcdraft] becomeFollower -> INFO 081 4 became follower at term 1 channel=rbpchannel node=4

2019-12-13 17:18:36.160 UTC [orderer.common.cluster] channelsToPull -> INFO 09b Probing whether I should pull channel ch2channel
2019-12-13 17:18:36.172 UTC [cauthdsl] deduplicate -> ERRO 09c Principal deserialization failure (MSP Org1OrdererMSP is unknown) for identity 0
2019-12-13 17:18:36.173 UTC [cauthdsl] deduplicate -> ERRO 09d Principal deserialization failure (MSP Org1OrdererMSP is unknown) for identity 0
2019-12-13 17:18:36.173 UTC [common.deliver] deliverBlocks -> WARN 09e [channel: ch2channel] Client authorization revoked for deliver request from 192.168.80.1:59020: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied: permission denied

019-12-13 17:18:36.183 UTC [orderer.common.cluster.replication] HeightsByEndpoints -> INFO 0a8 Returning the heights of OSNs mapped by endpoints map[]
2019-12-13 17:18:36.183 UTC [orderer.common.cluster] channelsToPull -> INFO 0a9 I do not belong to channel ch2channel or am forbidden pulling it (forbidden pulling the channel), skipping chain retrieval
2019-12-13 17:18:36.183 UTC [orderer.common.cluster] ReplicateChains -> INFO 0aa Found myself in 0 channels out of 1 : {[] [{ch2channel 0xc000abbe00}]}




I have checked with an Invoke and the orderer is working for rbpchannel in org2.

Is it a normal behavior for the new orderer to probe all the channels and not just the one he was added to?
I noticed there's a 10 minute timeout for the ch2channel.



Em quinta-feira, 12 de dezembro de 2019 09:37:12 BRT, Yacov Manevich <yacovm@...> escreveu:


Attach your logs, Raft tells you what/why it's doing



From:        "Nicholas Leonardi via Lists.Hyperledger.Org" <nlzanutim=yahoo.com@...>
To:        Fabric <fabric@...>
Cc:        fabric@...
Date:        12/12/2019 02:30 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Orderer Raft Multiple Channels
Sent by:        fabric@...




Hey guys,

I have an organization with two channels and using Raft.
I have a weird problem that I'm not sure how to solve or if it's solvable.
I create another organization in another machine. Then, I add that organization to the system channel and channel 1.
Then, I fetch the latest config block from the system channel to start the second orderer of the second organization.
It works in the beginning with channel 1 but after some time, it starts trying to pull channel 2 and kicks itself out of channel 1.

Anyone have any idea what I could do or what's going on?

Thanks in advance





Re: Issue CouchDB and Fabric peer connection

Mayank Tiwari
 

Can you pls try adding “GODEBUG=netdns=go” into your docker compose yaml for peers config.


Regards,
Mayank Tiwari.

On Fri, 13 Dec 2019 at 6:10 PM, Niklas Krohn <niklas.krohn@...> wrote:

Hello everyone,

 

I have an issue when trying to get coucdb container and peer container to communicate. I have been stuck with this issue for over two weeks now and not found any help in online forums. Hope someone here can help me solve the issue – and apologize up front if this is a too basic issue I should have spotted myself.

 

I have tried to delete network several times, and re-download everything. But same issue appears related to couchdb.

 

System: Ubuntu 18.04

Docker couchdb image:

  • Hyperledger/fabric-couchdb: latest (created 5 weeks ago, size 261mb)

 

The issue is that peer0 container just exits right after I try the “join channel” command. Then the following error occurs in peer0 container log:

 

ERRO 030 Error calling CouchDB CreateDatabaseIfNotExist() for dbName: allarewelcome_, error: error decoding response body: json: cannot unmarshal string into Go struct field DBInfo.purge_seq of type int

panic: error during commit to txmgr: error decoding response body: json: cannot unmarshal string into Go struct field DBInfo.purge_seq of type int

             panic: runtime error: invalid memory address or nil pointer dereference

[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xcecbb6]

 

If I re-start the peer0 container and enters into container typing “peer channel list” I receive the following error: “Error: Failed sending proposal, got rpc error: code = Unavailable desc = transport is closing”

 

“docker ps -a”:

 

dockerps.png

 

 

Peer0 container log:

 

peerlog1.png

peerlog2.png

 

Peer0 container “printenv”:

 

peer0printenv.png

 

Couchdb container log:

 

apachelog1.png

apachelog2.png

 

 

Docker-compose.yml file:

 

peer0compose.png

 

couchdbcompose.png

 

Best regards

Niklas


Re: problem creating channel: 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies

Nikhil Gupta
 

Hi Anoop,

Seems like there is a problem with your crypto config, and the node OU's are not quite right.


Nik



-----fabric@... wrote: -----
To: fabric@...
From: "Anoop Vijayan"
Sent by: fabric@...
Date: 12/13/2019 06:21AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] problem creating channel: 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies

Hello guys,
  Are there any updates on this?
In my case, I was trying to modify: BatchSize.value.max_message_count

  I tried adding the OU to crypto-config.yaml and ran `./byfn generate`.
This brought, 
```
        Issuer: C = US, ST = California, L = San Francisco, O = example.com, OU = admin, CN = ca.example.com
        Subject: C = US, ST = California, L = San Francisco, OU = admin + OU = client, CN = Admin@...
```
However, when I ran `./byfn up`, the end-to-end script fails with channel creation.
```
Build your first network (BYFN) end-to-end test
 
Channel name : mychannel
+ peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
Creating channel...
+ res=1
+ set +x
2019-12-13 10:48:39.024 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
Error: got unexpected status: FORBIDDEN -- implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied: permission denied
!!!!!!!!!!!!!!! Channel creation failed !!!!!!!!!!!!!!!!
========= ERROR !!! FAILED to execute End-2-End Scenario ===========
 
ERROR !!!! Test failed
```
Orderer logs:
```
2019-12-13 11:16:51.438 UTC [cauthdsl] func2 -> DEBU 44e 0xc0009731a0 identity 0 does not satisfy principal: could not validate identity's OUs: the identity must be a client, a peer, an orderer or an admin identity to be valid, not a combination of them. OUs: [[0xc000a01020 0xc000a01050]], MSP: [OrdererMSP]
2019-12-13 11:16:51.438 UTC [cauthdsl] func2 -> DEBU 44f 0xc0009731a0 principal evaluation fails
```

Anyone can reproduce this problem with `.first-network/byfn.sh`. I have nothing special here :)
Is there a proper procedure for this at all? Or am I looking at a wrong place?

Thanks,
 - Anoop


Re: changing merge rules

David Enyeart
 

Done! I'll forward to Hyperledger administrators to make the change to Fabric repo.

Chris +1
Kostas +1
Gari +1
Yacov +1
Dave +1
Jay +1
Jason +1
Murali +1


Dave Enyeart

Srinivasan Muralidharan ---12/13/2019 10:47:53 AM---+1 ... from gerritt experiment we know its used for valid reasons. As long as we have enough eyes to

From: Srinivasan Muralidharan <srinivasan.muralidharan99@...>
To: David Enyeart <enyeart@...>
Cc: Brett T Logan <brett.t.logan@...>, chris.ferris@..., fabric@..., Jason K Yellick <jyellick@...>, Yacov Manevich <YACOVM@...>
Date: 12/13/2019 10:47 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules





+1 ... from gerritt experiment we know its used for valid reasons. As long as we have enough eyes to validate big/critical changes and don't override comments and change requests, this should be good.

On Fri, Dec 13, 2019 at 10:41 AM David Enyeart <enyeart@...> wrote:
    Chris asked for a majority to respond with approval. If my counting is correct, we need one more maintainer to respond to finalize...

    Chris +1
    Kostas +1
    Gari +1
    Yacov +1
    Dave +1
    Jay +1
    Jason +1



    Dave Enyeart

    "Brett T Logan" ---12/12/2019 01:24:08 PM---What do we need to do to make this an official vote and relax the rules? It would be nice to have th

    From:
    "Brett T Logan" <brett.t.logan@...>
    To:
    "Jason K Yellick" <jyellick@...>
    Cc:
    chris.ferris@..., "David Enyeart" <enyeart@...>, fabric@..., "Yacov Manevich" <YACOVM@...>
    Date:
    12/12/2019 01:24 PM
    Subject:
    [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
    Sent by:
    fabric@...




    What do we need to do to make this an official vote and relax the rules? It would be nice to have this changed before the holiday's really get going. It's going to be harder than ever over the next month to get two +2's.


    Brett Logan

    Software Engineer, IBM Blockchain

    Phone:
    1-984-242-6890
    E-mail:
    brett.t.logan@...




----- Original message -----
From: "Jason Yellick" <jyellick@...>
Sent by:
fabric@...
To: "Yacov Manevich" <
YACOVM@...>
Cc:
chris.ferris@..., "David Enyeart" <enyeart@...>, fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Date: Wed, Dec 11, 2019 12:06 PM


+1

We had relaxed on Gerrit to allow self+2 on changes which did not merit additionally scrutiny, and this was a big improvement in productivity from my perspective. I think it's time we finally removed the second +2 entirely.

~Jason


----- Original message -----
From: "Yacov" <
yacovm@...>
Sent by:
fabric@...
To: "David Enyeart" <
enyeart@...>
Cc: "Christopher Ferris" <
chris.ferris@...>, fabric <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Date: Wed, Dec 11, 2019 2:28 AM


+1

I see having a more fine grained access control over who can merge changes to sub-components in the code as a natural extension of this policy change.



From:
"David Enyeart" <enyeart@...>
To:
"Christopher Ferris" <chris.ferris@...>
Cc:
fabric <fabric@...>
Date:
12/11/2019 09:11 AM
Subject:
[EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Sent by:
fabric@...



+1

Now that we are on GitHub we do have the option to use CODEOWNERS to further specify a set of reviewers with domain knowledge in certain areas of the code, but I think that could come later if we see a need for it in selective areas.
And agree with Yacov about when in doubt get a second review. We could use PR Assignee field to 'nominate' additional reviewers.


Dave Enyeart

"Christopher Ferris" ---12/10/2019 05:25:20 PM---We've brought this up before, but maybe it deserves to be revisited.

From:
"Christopher Ferris" <chris.ferris@...>
To:
fabric <fabric@...>
Date:
12/10/2019 05:25 PM
Subject:
[EXTERNAL] [Hyperledger Fabric] changing merge rules
Sent by:
fabric@...



We've brought this up before, but maybe it deserves to be revisited.

Originally, we added the 2+2 because there was a perception in the community that IBMers were being less critical of the contributions by other IBMers.

It served its purpose, but it does raise the bar and especially for obvious things that really don't merit the extra effort.

We have the abilities on GH to prevent self review.

Maybe the time has come as we have moved to GH that we think about lowering the bar and making it less burdensome on the maintainers that are doing reviews by allowing them to merge with a single NACR.

When there's a more substantive change, a maintainer can always seek additional eyes by adding reviewers.

I’d like to propose we go with a single NACR across the Fabric repo-scape.

Please respond on this thread if you concur, or have concerns. If we have a majority, we can ask Ry to make the necessary changes to the merge policy.


Chris











--
Thanks,
Murali
"Practice is a means of inviting the perfection desired." - Martha Graham
“We ran and ran. We were exhausted, but we kept running.” - Homare Sawa after winning 2011 Women's Soccer world cup



Re: changing merge rules

Srinivasan Muralidharan
 

+1 ... from gerritt experiment we know its used for valid reasons. As long as we have enough eyes to validate big/critical changes and don't override comments and change requests, this should be good.

On Fri, Dec 13, 2019 at 10:41 AM David Enyeart <enyeart@...> wrote:

Chris asked for a majority to respond with approval. If my counting is correct, we need one more maintainer to respond to finalize...

Chris +1
Kostas +1
Gari +1
Yacov +1
Dave +1
Jay +1
Jason +1



Dave Enyeart

"Brett T Logan" ---12/12/2019 01:24:08 PM---What do we need to do to make this an official vote and relax the rules? It would be nice to have th

From: "Brett T Logan" <brett.t.logan@...>
To: "Jason K Yellick" <jyellick@...>
Cc: chris.ferris@..., "David Enyeart" <enyeart@...>, fabric@..., "Yacov Manevich" <YACOVM@...>
Date: 12/12/2019 01:24 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Sent by: fabric@...





What do we need to do to make this an official vote and relax the rules? It would be nice to have this changed before the holiday's really get going. It's going to be harder than ever over the next month to get two +2's.

Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
E-mail: brett.t.logan@...




----- Original message -----
From: "Jason Yellick" <jyellick@...>
Sent by: fabric@...
To: "Yacov Manevich" <YACOVM@...>
Cc: chris.ferris@..., "David Enyeart" <enyeart@...>, fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Date: Wed, Dec 11, 2019 12:06 PM

+1

We had relaxed on Gerrit to allow self+2 on changes which did not merit additionally scrutiny, and this was a big improvement in productivity from my perspective. I think it's time we finally removed the second +2 entirely.

~Jason


----- Original message -----
From: "Yacov" <yacovm@...>
Sent by: fabric@...
To: "David Enyeart" <enyeart@...>
Cc: "Christopher Ferris" <chris.ferris@...>, fabric <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Date: Wed, Dec 11, 2019 2:28 AM

+1

I see having a more fine grained access control over who can merge changes to sub-components in the code as a natural extension of this policy change.



From:
"David Enyeart" <enyeart@...>
To:
"Christopher Ferris" <chris.ferris@...>
Cc:
fabric <fabric@...>
Date:
12/11/2019 09:11 AM
Subject:
[EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Sent by:
fabric@...



+1

Now that we are on GitHub we do have the option to use CODEOWNERS to further specify a set of reviewers with domain knowledge in certain areas of the code, but I think that could come later if we see a need for it in selective areas.
And agree with Yacov about when in doubt get a second review. We could use PR Assignee field to 'nominate' additional reviewers.


Dave Enyeart

"Christopher Ferris" ---12/10/2019 05:25:20 PM---We've brought this up before, but maybe it deserves to be revisited.

From:
"Christopher Ferris" <chris.ferris@...>
To:
fabric <fabric@...>
Date:
12/10/2019 05:25 PM
Subject:
[EXTERNAL] [Hyperledger Fabric] changing merge rules
Sent by:
fabric@...



We've brought this up before, but maybe it deserves to be revisited.


Originally, we added the 2+2 because there was a perception in the community that IBMers were being less critical of the contributions by other IBMers.


It served its purpose, but it does raise the bar and especially for obvious things that really don't merit the extra effort.


We have the abilities on GH to prevent self review.


Maybe the time has come as we have moved to GH that we think about lowering the bar and making it less burdensome on the maintainers that are doing reviews by allowing them to merge with a single NACR.


When there's a more substantive change, a maintainer can always seek additional eyes by adding reviewers.


I’d like to propose we go with a single NACR across the Fabric repo-scape.


Please respond on this thread if you concur, or have concerns. If we have a majority, we can ask Ry to make the necessary changes to the merge policy.


Chris













--
Thanks,
Murali
"Practice is a means of inviting the perfection desired." - Martha Graham
“We ran and ran. We were exhausted, but we kept running.” - Homare Sawa after winning 2011 Women's Soccer world cup


Re: changing merge rules

David Enyeart
 

Chris asked for a majority to respond with approval. If my counting is correct, we need one more maintainer to respond to finalize...

Chris +1
Kostas +1
Gari +1
Yacov +1
Dave +1
Jay +1
Jason +1



Dave Enyeart

"Brett T Logan" ---12/12/2019 01:24:08 PM---What do we need to do to make this an official vote and relax the rules? It would be nice to have th

From: "Brett T Logan" <brett.t.logan@...>
To: "Jason K Yellick" <jyellick@...>
Cc: chris.ferris@..., "David Enyeart" <enyeart@...>, fabric@..., "Yacov Manevich" <YACOVM@...>
Date: 12/12/2019 01:24 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Sent by: fabric@...





What do we need to do to make this an official vote and relax the rules? It would be nice to have this changed before the holiday's really get going. It's going to be harder than ever over the next month to get two +2's.

Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
E-mail: brett.t.logan@...




----- Original message -----
From: "Jason Yellick" <jyellick@...>
Sent by: fabric@...
To: "Yacov Manevich" <YACOVM@...>
Cc: chris.ferris@..., "David Enyeart" <enyeart@...>, fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Date: Wed, Dec 11, 2019 12:06 PM

+1

We had relaxed on Gerrit to allow self+2 on changes which did not merit additionally scrutiny, and this was a big improvement in productivity from my perspective. I think it's time we finally removed the second +2 entirely.

~Jason


----- Original message -----
From: "Yacov" <yacovm@...>
Sent by: fabric@...
To: "David Enyeart" <enyeart@...>
Cc: "Christopher Ferris" <chris.ferris@...>, fabric <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Date: Wed, Dec 11, 2019 2:28 AM

+1

I see having a more fine grained access control over who can merge changes to sub-components in the code as a natural extension of this policy change.



From:
"David Enyeart" <enyeart@...>
To:
"Christopher Ferris" <chris.ferris@...>
Cc:
fabric <fabric@...>
Date:
12/11/2019 09:11 AM
Subject:
[EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Sent by:
fabric@...



+1

Now that we are on GitHub we do have the option to use CODEOWNERS to further specify a set of reviewers with domain knowledge in certain areas of the code, but I think that could come later if we see a need for it in selective areas.
And agree with Yacov about when in doubt get a second review. We could use PR Assignee field to 'nominate' additional reviewers.


Dave Enyeart

"Christopher Ferris" ---12/10/2019 05:25:20 PM---We've brought this up before, but maybe it deserves to be revisited.

From:
"Christopher Ferris" <chris.ferris@...>
To:
fabric <fabric@...>
Date:
12/10/2019 05:25 PM
Subject:
[EXTERNAL] [Hyperledger Fabric] changing merge rules
Sent by:
fabric@...



We've brought this up before, but maybe it deserves to be revisited.


Originally, we added the 2+2 because there was a perception in the community that IBMers were being less critical of the contributions by other IBMers.


It served its purpose, but it does raise the bar and especially for obvious things that really don't merit the extra effort.


We have the abilities on GH to prevent self review.


Maybe the time has come as we have moved to GH that we think about lowering the bar and making it less burdensome on the maintainers that are doing reviews by allowing them to merge with a single NACR.


When there's a more substantive change, a maintainer can always seek additional eyes by adding reviewers.


I’d like to propose we go with a single NACR across the Fabric repo-scape.


Please respond on this thread if you concur, or have concerns. If we have a majority, we can ask Ry to make the necessary changes to the merge policy.


Chris












Re: Issue CouchDB and Fabric peer connection

David Enyeart
 

CouchDB 2.3 introduced an incompatible change that causes this error. Fabric peer was updated to tolerate the change as of v1.4.1. If you search Fabric Jira with that error you'll find the details in https://jira.hyperledger.org/browse/FAB-13196.
Looks like you are on v1.4.0, if you upgrade peer the problem should go away. In general, it is always recommended to move to the latest LTS 3rd digit release, currently v1.4.4.

So that others don't feel the same pain, I've opened a documentation item to make the compatibility clear:
https://jira.hyperledger.org/browse/FAB-17260


Dave Enyeart

"Niklas Krohn" ---12/13/2019 07:32:57 AM---Hello everyone, I have an issue when trying to get coucdb container and peer container to communicat

From: "Niklas Krohn" <niklas.krohn@...>
To: "hyperledger-fabric@..." <hyperledger-fabric@...>
Date: 12/13/2019 07:32 AM
Subject: [EXTERNAL] [Hyperledger Fabric] Issue CouchDB and Fabric peer connection
Sent by: fabric@...





Hello everyone,

I have an issue when trying to get coucdb container and peer container to communicate. I have been stuck with this issue for over two weeks now and not found any help in online forums. Hope someone here can help me solve the issue – and apologize up front if this is a too basic issue I should have spotted myself.

I have tried to delete network several times, and re-download everything. But same issue appears related to couchdb.

System: Ubuntu 18.04
Docker couchdb image:
      • Hyperledger/fabric-couchdb: latest (created 5 weeks ago, size 261mb)

The issue is that peer0 container just exits right after I try the “join channel” command. Then the following error occurs in peer0 container log:

ERRO 030 Error calling CouchDB CreateDatabaseIfNotExist() for dbName: allarewelcome_, error: error decoding response body: json: cannot unmarshal string into Go struct field DBInfo.purge_seq of type int
panic: error during commit to txmgr: error decoding response body: json: cannot unmarshal string into Go struct field DBInfo.purge_seq of type int
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xcecbb6]

If I re-start the peer0 container and enters into container typing “peer channel list” I receive the following error: “Error: Failed sending proposal, got rpc error: code = Unavailable desc = transport is closing”

“docker ps -a”:

dockerps.png


Peer0 container log:

peerlog1.png
peerlog2.png

Peer0 container “printenv”:

peer0printenv.png

Couchdb container log:

apachelog1.png
apachelog2.png


Docker-compose.yml file:

peer0compose.png

couchdbcompose.png

Best regards
Niklas





Issue CouchDB and Fabric peer connection

Niklas Krohn
 

Hello everyone,

 

I have an issue when trying to get coucdb container and peer container to communicate. I have been stuck with this issue for over two weeks now and not found any help in online forums. Hope someone here can help me solve the issue – and apologize up front if this is a too basic issue I should have spotted myself.

 

I have tried to delete network several times, and re-download everything. But same issue appears related to couchdb.

 

System: Ubuntu 18.04

Docker couchdb image:

  • Hyperledger/fabric-couchdb: latest (created 5 weeks ago, size 261mb)

 

The issue is that peer0 container just exits right after I try the “join channel” command. Then the following error occurs in peer0 container log:

 

ERRO 030 Error calling CouchDB CreateDatabaseIfNotExist() for dbName: allarewelcome_, error: error decoding response body: json: cannot unmarshal string into Go struct field DBInfo.purge_seq of type int

panic: error during commit to txmgr: error decoding response body: json: cannot unmarshal string into Go struct field DBInfo.purge_seq of type int

             panic: runtime error: invalid memory address or nil pointer dereference

[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xcecbb6]

 

If I re-start the peer0 container and enters into container typing “peer channel list” I receive the following error: “Error: Failed sending proposal, got rpc error: code = Unavailable desc = transport is closing”

 

“docker ps -a”:

 

dockerps.png

 

 

Peer0 container log:

 

peerlog1.png

peerlog2.png

 

Peer0 container “printenv”:

 

peer0printenv.png

 

Couchdb container log:

 

apachelog1.png

apachelog2.png

 

 

Docker-compose.yml file:

 

peer0compose.png

 

couchdbcompose.png

 

Best regards

Niklas


Re: problem creating channel: 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies

Anoop Vijayan <anoop@...>
 

Hello guys,
  Are there any updates on this?
In my case, I was trying to modify: BatchSize.value.max_message_count

  I tried adding the OU to crypto-config.yaml and ran `./byfn generate`.
This brought, 
```
openssl x509 -in crypto-config/ordererOrganizations/example.com/users/Admin@.../msp/signcerts/Admin@... -text|grep OU
        Issuer: C = US, ST = California, L = San Francisco, O = example.com, OU = admin, CN = ca.example.com
        Subject: C = US, ST = California, L = San Francisco, OU = admin + OU = client, CN = Admin@...
```
However, when I ran `./byfn up`, the end-to-end script fails with channel creation.
```
Build your first network (BYFN) end-to-end test
 
Channel name : mychannel
+ peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
Creating channel...
+ res=1
+ set +x
2019-12-13 10:48:39.024 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
Error: got unexpected status: FORBIDDEN -- implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied: permission denied
!!!!!!!!!!!!!!! Channel creation failed !!!!!!!!!!!!!!!!
========= ERROR !!! FAILED to execute End-2-End Scenario ===========
 
ERROR !!!! Test failed
```
Orderer logs:
```
2019-12-13 11:16:51.438 UTC [cauthdsl] func2 -> DEBU 44e 0xc0009731a0 identity 0 does not satisfy principal: could not validate identity's OUs: the identity must be a client, a peer, an orderer or an admin identity to be valid, not a combination of them. OUs: [[0xc000a01020 0xc000a01050]], MSP: [OrdererMSP]
2019-12-13 11:16:51.438 UTC [cauthdsl] func2 -> DEBU 44f 0xc0009731a0 principal evaluation fails
```

Anyone can reproduce this problem with `.first-network/byfn.sh`. I have nothing special here :)
Is there a proper procedure for this at all? Or am I looking at a wrong place?

Thanks,
 - Anoop


Can't query chaincode on new peer

Suhan Sumeet
 

Hello Team,

I am trying to add a new peer to org and all the steps were successful but only when I try to query chaincode for that peer it fails with 
image.png
The chaincode is installed  successfully on peer and instantiated properly on the existing channel but not able to query and spin up new chaincode container.

Please help


Re: TLS handshake failed when setting up etcdRaft

Howin Ho
 

Here is some more background info and some update to this issue.

Background:
I started out this exercise by following the Fabric CA Operations tutorial (https://hyperledger-fabric-ca.readthedocs.io/en/latest/operations_guide.html) so it is a standard 4 CAs 2 Orgs setup. It worked with SOLO or KAFKA without any problem. The Orderer TLS setup is pretty standard too:

fabric-ca-client register -d --id.name orderer1-org0 --id.secret ordererPW --id.type orderer -u https://0.0.0.0:6052
fabric-ca-client enroll -d -u https://orderer1-org0:ordererPW@0.0.0.0:6052 --enrollment.profile tls --csr.hosts orderer1-org0
 

Update:
When the orderers first started with genesis block, it first complained that "certificate is valid for orderer[X]-org0, not orderer[Y]-org0". So I tried to put all 5 orderers hostname into csr hosts (which I know is probably not supposed to).  It ended up with another complaint that "certificate presented by orderer[X]-org0:7050 doesn't match any authorized certificate" which I have no idea because it was saying that the certificate was valid in the first complaint.


Re: [Use Case] global trade

Don Li <lichunshen84@...>
 

Hi Brian,

Thank you very much for the thoughtful and informative response.  I'm delighted you expanded it to use case, which makes a lot of sense.  Since business endeavor involves two key parts of business case/motivation and technical implementation I feel it might be more productive to link these two together at some level instead of separating them as two different domains...
And since this is mostly a technical mailing list, for clarity, I'm adding [Use Case] to differentiate the discussion from usual technical discussion, and adding "global trade" to the end to indicate type of use case.  I hope business executives of various persuasion would join in discussion of Hyperledger Fabric use cases.  Or it would be nice if we could have a separate mailing list such as fabric-usecase@...   Just a thought.

Best,

Don

(Don) Chunshen Li
Virginia, US

On Thu, Dec 12, 2019 at 5:23 PM Brian Behlendorf <bbehlendorf@...> wrote:
Hi Don,

There are two SIGs that you may be interested in for answers to this, one for Trade Finance and another for Supply Chain kinds of projects.  These are not as technical as the developer mailing lists, but they do discuss use cases and deployments.

I also will note that many of the major trade dinance and supply chain projects out there - from We.Trade to Tradelens to the Food Trust Network, to the Everledger diamond ledger, Circulor's tantalum traceability network, Honeywell with parts for planes, etc - are using Fabric.

It's often a challenge to get folks to talk about the internal details of their network publicly, and we're trying to encourage them by putting together case studies on the Hyperledger web site that might be useful for you to peruse.

Brian


On 12/12/19 7:01 AM, Don Li wrote:
Hello,

I'm curious to know who (major corporations, global economic entities or even startups) or if any on the list are using Hyperledger Fabric for global trade for efficiency or other benefits?
Just fyi, I studied international trade when in college.

Thanks.

Don

(Don) Chunshen Li
Virginia, US

Your Subscription | Contact Group Owner | Unsubscribe [lichunshen84@...]


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


Re: Who are using Fabric for for global trade?

Brian Behlendorf <bbehlendorf@...>
 

Hi Don,

There are two SIGs that you may be interested in for answers to this, one for Trade Finance and another for Supply Chain kinds of projects.  These are not as technical as the developer mailing lists, but they do discuss use cases and deployments.

I also will note that many of the major trade dinance and supply chain projects out there - from We.Trade to Tradelens to the Food Trust Network, to the Everledger diamond ledger, Circulor's tantalum traceability network, Honeywell with parts for planes, etc - are using Fabric.

It's often a challenge to get folks to talk about the internal details of their network publicly, and we're trying to encourage them by putting together case studies on the Hyperledger web site that might be useful for you to peruse.

Brian


On 12/12/19 7:01 AM, Don Li wrote:
Hello,

I'm curious to know who (major corporations, global economic entities or even startups) or if any on the list are using Hyperledger Fabric for global trade for efficiency or other benefits?
Just fyi, I studied international trade when in college.

Thanks.

Don

(Don) Chunshen Li
Virginia, US

Your Subscription | Contact Group Owner | Unsubscribe [lichunshen84@...]


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


Re: Peer instantiation error #fabric #fabric-sdk-node

Baohua Yang
 

ankit,
Seems that's the policy issue, and have you joined the peer into the channel successfully? And what id are you using to do the installation?

Besides, I think this project might be helpful for you: https://github.com/yeasy/docker-compose-files/tree/master/hyperledger_fabric/

On Wed, Dec 11, 2019 at 12:31 AM <ankit.singh@...> wrote:
I am using fabric 1.4 with raft configuration. create channel, join channel, update anchor peers and install chaincode worked fine but facing this issue when trying to instantiate chaincode:

NodeJS logs:
(node:1463) UnhandledPromiseRejectionWarning: Error: Failed to instantiate the chaincode. cause:Error: instantiate proposal resulted in an error :: Error: failed to execute transaction 53450a9bb88694d82ab6c04f201f5016eecaf59140717d5ad2c4b4ba6710d48c: error sending: timeout expired while executing transaction

Blockchain logs:
Peer isn't eligible for channel mychannel : implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied
peer0.org1.example.com    | runtime.goexit
peer0.org1.example.com    | /opt/go/src/runtime/asm_amd64.s:1337



--
Best wishes!

Baohua Yang


Re: stateDatabase field in core.yaml always shows goleveldb

Baohua Yang
 

Hi Suhan

It might be a good idea to add a new feature to allow exporting the runtime configurations using the RESTful API.

Feel free to create a jira issue if needed.

Thanks!


On Thu, Dec 12, 2019 at 3:46 AM Suhan Sumeet <suhan.premilu@...> wrote:
Thanks for the clarification Gari.

But then how can we confirm that a peer is using couchdb as statedb by checking any configuration and not verifying from the server

On Thu, Dec 12, 2019 at 4:34 PM Gari Singh <garis@...> wrote:
Environment variables act as override for the config persisted in core.yaml (or orderer.yaml for the orderer) and are not persisted.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: hyperledger-fabric@...
From: "Suhan Sumeet"
Sent by: fabric@...
Date: 12/12/2019 06:01AM
Subject: [EXTERNAL] [Hyperledger Fabric] stateDatabase field in core.yaml always shows goleveldb

Hello Team,

Am trying to set BYFN network using couchdb and even I can see the records popping into the db serer, but when I check core.yaml of individual peers  the "stateDatabase" field still contains value as goleveldb.
Does not this field should get updated when running the network or value of this field does not matter?




--
Best wishes!

Baohua Yang


Re: changing merge rules

Brett T Logan <brett.t.logan@...>
 

What do we need to do to make this an official vote and relax the rules? It would be nice to have this changed before the holiday's really get going. It's going to be harder than ever over the next month to get two +2's.
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: "Jason Yellick" <jyellick@...>
Sent by: fabric@...
To: "Yacov Manevich" <YACOVM@...>
Cc: chris.ferris@..., "David Enyeart" <enyeart@...>, fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Date: Wed, Dec 11, 2019 12:06 PM
 
+1

We had relaxed on Gerrit to allow self+2 on changes which did not merit additionally scrutiny, and this was a big improvement in productivity from my perspective.  I think it's time we finally removed the second +2 entirely.

~Jason
 
----- Original message -----
From: "Yacov" <yacovm@...>
Sent by: fabric@...
To: "David Enyeart" <enyeart@...>
Cc: "Christopher Ferris" <chris.ferris@...>, fabric <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Date: Wed, Dec 11, 2019 2:28 AM
 
+1

I see having a more fine grained access control over who can merge changes to sub-components in the code as a natural extension of this policy change.



From:        "David Enyeart" <enyeart@...>
To:        "Christopher Ferris" <chris.ferris@...>
Cc:        fabric <fabric@...>
Date:        12/11/2019 09:11 AM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] changing merge rules
Sent by:        fabric@...



+1

Now that we are on GitHub we do have the option to use CODEOWNERS to further specify a set of reviewers with domain knowledge in certain areas of the code, but I think that could come later if we see a need for it in selective areas.
And agree with Yacov about when in doubt get a second review. We could use PR Assignee field to 'nominate' additional reviewers.


Dave Enyeart

"Christopher Ferris" ---12/10/2019 05:25:20 PM---We've brought this up before, but maybe it deserves to be revisited.

From: "Christopher Ferris" <chris.ferris@...>
To: fabric <fabric@...>
Date: 12/10/2019 05:25 PM
Subject: [EXTERNAL] [Hyperledger Fabric] changing merge rules
Sent by: fabric@...



We've brought this up before, but maybe it deserves to be revisited.

Originally, we added the 2+2 because there was a perception in the community that IBMers were being less critical of the contributions by other IBMers.

It served its purpose, but it does raise the bar and especially for obvious things that really don't merit the extra effort.

We have the abilities on GH to prevent self review.

Maybe the time has come as we have moved to GH that we think about lowering the bar and making it less burdensome on the maintainers that are doing reviews by allowing them to merge with a single NACR.

When there's a more substantive change, a maintainer can always seek additional eyes by adding reviewers.

I’d like to propose we go with a single NACR across the Fabric repo-scape.

Please respond on this thread if you concur, or have concerns. If we have a majority, we can ask Ry to make the necessary changes to the merge policy.

Chris

 



 

 
 
 


Re: Broken Links in documentation

Kimheng SOK
 

Hi,

Thank for the open investigate, but don't know when will it resolved.
By the way, I have questions may be someone can answer:

1. Does the Private Data store in the (Transient Data Store, Private State) is encrypted or Not? 
2. Should we encrypted? If Yes Why or If No Why?

Bests,

On Tue, Dec 10, 2019 at 8:15 PM Pam Andrejko <pama@...> wrote:


Thanks for reporting this. I've opened this Jira to investigate and address: https://jira.hyperledger.org/browse/FAB-17234

 

Pam


Who are using Fabric for for global trade?

Don Li <lichunshen84@...>
 

Hello,

I'm curious to know who (major corporations, global economic entities or even startups) or if any on the list are using Hyperledger Fabric for global trade for efficiency or other benefits?
Just fyi, I studied international trade when in college.

Thanks.

Don

(Don) Chunshen Li
Virginia, US

4041 - 4060 of 11422