Re: Pull requests to connect fabric-api


Brian Behlendorf <bbehlendorf@...>
 

OK, that makes sense. Others on the Fabric list: do you "watch" the Github PR stream, and find it useful?

Brian

On 06/22/2016 07:12 AM, Christopher B Ferris wrote:
We're doing pretty well with GitHub watch on the part of the reviewers. Are we getting others engaged in reviews... depends on their motivation.
When we have Gerrit set up, we can more formally track who is reviewing and that can be a means of getting others established as maintainers which will serve as additional motivation to pay attention.

Watching is project by project, so I don't think it will be an issue until we start to get an order of magnitude more PRs etc. Plus, you can mute threads if you like.

Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----hyperledger-fabric-bounces@... wrote: -----To: hyperledger-fabric@...
From: Brian Behlendorf
Sent by: hyperledger-fabric-bounces@...
Date: 06/22/2016 09:14AM
Subject: Re: [Hyperledger-fabric] Pull requests to connect fabric-api

The only question is one of our collective "radar" - how do we make sure
new PRs get noticed by the community, active discussions on PRs get the
appropriate attention, that sort of thing. "Watching" the whole feed at
Github could be a real firehose. Perhaps the best way is to simply rely
upon individuals to raise issues here for special attention, or when
there's more hands-on-deck needed for issue triage (helping process
unanswered PR's), etc. Presumably this will be the same issue when we
move to Jira.

Brian

On 06/22/2016 05:59 AM, Christopher B Ferris wrote:
Sheehan, I agree that we should probably keep discussion of specific issues and PRs in context of those issues and PR comments. It allows for a bit more flexibility in staying in the loop, because you can opt out of specific threads that don't interest you. When we transition to Jira, we'll have another look at that.

Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----hyperledger-fabric-bounces@... wrote: -----To: hyperledger-fabric@...
From: Sheehan Anderson/Durham/IBM@IBMUS
Sent by: hyperledger-fabric-bounces@...
Date: 06/22/2016 08:43AM
Subject: Re: [Hyperledger-fabric] Pull requests to connect fabric-api

I think Brian's voting suggestion is an excellent idea. Three +1s and no vetoes would be a great solution. I'm all for using this now if others are in agreement.

My preference is for formal communication to take place in the respective pull request or issue in GitHub. I think it organizes things more cleanly than the mailing list and I don't have to look in two places, both the PR and mailing list. The usage of Slack to discuss PRs is an attempt for the submitter or maintainer to raise a flag if something seems to have fallen through the cracks, but I believe a voting process would help to alleviate many of the problems we are seeing today.

-Sheehan

Brian Behlendorf ---06/21/2016 10:08:46 PM---On 06/21/2016 09:01 AM, Christopher B Ferris wrote: > FWIW, there has been continuing technical dis

From: Brian Behlendorf <bbehlendorf@...>
To: hyperledger-fabric@...
Date: 06/21/2016 10:08 PM
Subject: Re: [Hyperledger-fabric] Pull requests to connect fabric-api
Sent by: hyperledger-fabric-bounces@...



On 06/21/2016 09:01 AM, Christopher B Ferris wrote:
FWIW, there has been continuing technical discussion in the context of each PR referenced below.
That's a really good point, Chris - there has been extensive technical conversation around each, which is great to see and where you'd expect them. I guess the key question is what the workflow should be to approve the pull requests.

I respect the Fabric team's desire to do this synchronously on a regular basis (I think 10am ET Wednesdays) on the #fabric-pr-review Slack channel, but I'd like to suggest perhaps we could move to a more asynchronous model, based on some sort of consensus mechanism of our own. Perhaps this is Apache's "three +1s and no vetoes" approach, which basically established a low quorum for making changes but empowered anyone involved to stand up and stop what they thought would be a bad idea. Test coverage, regular performance testing, and other tools can help us feel more confident making significant changes here.

Brian
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402
----- Original message -----
From: Tamas Blummer <tamas@...>
Sent by: hyperledger-fabric-bounces@...
To: hyperledger-fabric <hyperledger-fabric@...>
Cc:
Subject: [Hyperledger-fabric] Pull requests to connect fabric-api
Date: Mon, Jun 20, 2016 11:47 AM
We at DA raised several pull requests for fabric, that implement features useful to connect fabric-api with fabric.
The pull requests are pending and were rebased several times during last weeks.

I introduce them here and provide context, in hope to receive feedback or even a decision on the concepts their implement

1) Optionally generate invoke transaction ID from transaction content: https://github.com/hyperledger/fabric/pull/1721
If UUID is derived from transaction content, then it is already known by the ledger client application, that is able to track it from construction to storage into the ledger. If UUID was assigned by the ledger (as is now) then a client would have to find the transaction in the block chain by comparing its content with content that it sent in. Deriving transaction id from content with a cryptographic hash practically ensures that ID will be unique, no other transaction with any different content will have the same ID. A limit of the approach is that identical invoke would receive same ID, which is however easy to avoid by the creator of the transaction. It is questionable if identical invokes should be processed at all since if they are allowed then trivial transaction replay attack can be executed on the ledger.

2) Do not store failed invoke transactions into the ledger: https://github.com/hyperledger/fabric/pull/1719
Chain code will likely implement checks of a transaction. A transaction that does not pass the checks without error should not be forwarded to consensus on order. Storing invalid transactions turns the ledger into an error log and can hurt performance by a single misbehaving client that pushes junk.

Note that since 2) does not store error into blockchain we need a different mechanism reporting error to transaction originator, which leads us to

3) Add transaction rejection events: https://github.com/hyperledger/fabric/pull/1754
This change adds a new type of events: transaction rejection. These events are sent out to listeners in case the corresponding chain code of a transaction exited with error. A mechanism was needed for the clients to be able to get the results of their transactions without constantly querying them (and without receiving all the completed blocks with all the transactions that had a zero exit status).

We tried to put together the pieces by implementing a noop system chaincode, that is suitable for performance testing

4) Add noop system chain code. https://github.com/hyperledger/fabric/pull/1722
Noop system chain code simply stores invoke transactions without validation. This chaincode is useful for testing. The noop system chaincode is prepared to work with fabric-api



TAMAS BLUMMER
CHIEF LEDGER ARCHITECT
Digital Asset

T: +36 1 883 0300
E: tamas@...
W: digitalasset.com


--
This message, and any attachments, is for the intended recipient(s) only,
may contain information that is privileged, confidential and/or proprietary
and subject to important terms and conditions available at
http://www.digitalasset.com/emaildisclaimer.html. If you are not the
intended recipient, please delete this message.
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

Join fabric@lists.hyperledger.org to automatically receive all group messages.