Date   

Re: fabric node sdk vs java sdk

Ross Tang <tangross@...>
 

I don’t have definite answer, like side by side comparison. But I am working very fine with node sdk, especially when my middle tier application, and front end app are (everything in Typescript). I create a single Typescript monrepo, for every stack/components, including chaincode. It is end-to-end typing, and I am using Jest for unit and integration for web, api gateway, middleware, and chaincode. Also easy with DevOps. 


On 2 Dec 2019, at 4:48 PM, Medha Kamalakar <medha_Kamalakar@...> wrote:

Hello,
 
Are there any recommendations around which fabric sdk should be used(node sdk vs java sdk) for various hyperledger fabric blockchain use cases.
Are there any guidelines for choice of SDK and has any comparative analysis been done for this?(Criteria could be performance, feature list, support available etc..)
 
 
Thanks and Regards,
Medha.
DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.


Re: fabric node sdk vs java sdk

Matthew White
 

Hello - both SDKs have the updated programming model. Both have the same features, and able to support the same Fabric use-cases.
 
It's possibly more important to consider the development environment, skills, and other libraries you want to use - let that be a guide to the choice of development language and pick the SDK to match
 
 
Regards, Matthew.
Matthew B White  IBM Blockchain Solutions Architect
 
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at  calanais.me.uk
 
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN

"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 
 
 
----- Original message -----
From: "Medha Kamalakar" <medha_Kamalakar@...>
Sent by: fabric@...
To: "fabric@..." <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] fabric node sdk vs java sdk
Date: Mon, Dec 2, 2019 8:48 AM
 

Hello,

 

Are there any recommendations around which fabric sdk should be used(node sdk vs java sdk) for various hyperledger fabric blockchain use cases.

Are there any guidelines for choice of SDK and has any comparative analysis been done for this?(Criteria could be performance, feature list, support available etc..)

 

 

Thanks and Regards,

Medha.

DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.
 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


fabric node sdk vs java sdk

Medha Kamalakar <medha_Kamalakar@...>
 

Hello,

 

Are there any recommendations around which fabric sdk should be used(node sdk vs java sdk) for various hyperledger fabric blockchain use cases.

Are there any guidelines for choice of SDK and has any comparative analysis been done for this?(Criteria could be performance, feature list, support available etc..)

 

 

Thanks and Regards,

Medha.

DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.


Query on fabric NodeJS versioning #fabric-sdk-node

shrugupt@...
 

Hi All,

Is there any recommendation for fabric Node JS SDK version to be used for a specific fabric version running on the network peer/orderer/ca nodes. 

For example, if my fabric network is running on vesion 1.4.1 then which version of fabric Node JS SDK is recommended to use? How can get this information on nodeJS SDK compatible version for each fabric version?

Thanks in advance!

Regards,
Shruti Gupta


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

Siddharth Jain
 

we get the error below when trying to create a channel using the peer CLI
2019-11-30 20:53:15.482 UTC [orderer.common.broadcast] ProcessMessage -> WARN 00c [channel: mychannel] Rejecting broadcast of config message from 172.18.0.1:51816 because of error: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied: permission denied
  • we have a 3 org network (plus orderer)
  • we are using NodeOUs
  • our configtx.yaml can be found at https://gist.github.com/siddjain/4cefde4321185c81a663f877fd6b105e
  • we are running the CLI under credentials of an admin user of one of the peer organizations
  • we checked the public cert and it has OU=admin on it. it was generated using cryptogen 1.4.4
how can we fix this? what is the cause?

fwiw, in case it helps, if we try to create the channel using credentials of admin of the orderer org we get a different error

2019-11-30 20:30:53.025 UTC [orderer.common.broadcast] ProcessMessage -> WARN 008 [channel: mychannel] Rejecting broadcast of config message from 172.18.0.1:51808 because of error: error validating channel creation transaction for new channel 'tracktrace', could not succesfully apply update to template configuration: error authorizing update: error validating DeltaSet: policy for [Group]  /Channel/Application not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied


Re: Hyperledger Fabric GitHub Migration

binh nguyen <binh1010010110@...>
 

After 4 years, we're back home where we started. Thanks!


On Mon, Nov 25, 2019 at 9:00 PM David Enyeart <enyeart@...> wrote:

The transition to GitHub for source control management, and Azure Pipelines for CI, is now complete for all Fabric development repositories. The final repository to shift will be fabric-test in early December.

You can open pull requests at https://github.com/hyperledger/fabric/pulls.

We use the standard GitHub fork and branch PR workflow. If you need a refresher on the workflow, please see the instructions at https://hyperledger-fabric.readthedocs.io/en/latest/github/github.html.

Thanks to Brett Logan for making the transition a smooth one!


Dave Enyeart

"Brett T Logan" ---11/21/2019 01:11:31 AM---Hello Contributors,

From: "Brett T Logan" <brett.t.logan@...>
To: fabric@...
Date: 11/21/2019 01:11 AM
Subject: [EXTERNAL] [Hyperledger Fabric] Hyperledger Fabric GitHub Migration
Sent by: fabric@...





Hello Contributors,

The time has finally come. The Hyperledger Fabric maintainers are planning for a migration of the core Fabric repository to GitHub this Friday morning Eastern Standard Time.

We are asking that effective immediately, all contributors stop pushing changes to Gerrit. Instead contributors can open their changes as pull requests using the Hyperledger Fabric repository in Github https://github.com/hyperledger/fabric. We have already configured CI to run against new pull requests using Azure Pipelines. This will allow the maintainers time merge as many Gerrit CR's as they can before the cutover.

Any changes that don't make it in before the Friday cutover will be abandoned and contributors will need to reopen them in GitHub. If you feel it's unlikely your change will make it in by Friday morning, we ask that you move it to GitHub now, and close your CR so maintainers can focus on changes that will get merged in the next day.

We will be publishing updated documentation about best practices, but in the meantime a few reminders about GitHub contributions:
    • Commits should be focused and small
    • Commit messages should include the Jira number on their first line and the body should include meaningful information on the change
    • Your signature must be included in your commit message, you can do this using the "-s" flag when running the "git commit" command
    • When opening a pull request it must come from your fork of the Fabric repository
    • When opening the pull request, your pull request message should include a meaningful title and provide the reasoning around the change, this will help maintainers understand what you are attempting to achieve (we will be publishing an automatic template yet this week, once that happens you should fill out the template accordingly)
With this migration, Hyperledger will have migrated all of its development repositories off of Gerrit and Jenkins. Contributions are welcome to any of the Hyperledger projects through GitHub moving forward. It is our hope that by adopting this industry standard we can lower the barrier of entry for new contributors and attract even more of the community to participate in contributing.

As always, thank you for your contributions!

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







Migration from Gerrit: Help with JQ and Git needed

Ry Jones
 

All,
I have exported all of the git data from Gerrit (except for the fabric-test repo, which is still undergoing development). I have also exported the comments and the like as JSON. I've set up a new org here:


And this is a temporary home of the JSON:

What I need is help gluing the two together, if that's even needed. Take a look here:

Ry
--
Ry Jones
Community Architect, Hyperledger


Re: Proposal : Hyperledger Fabric block archiving

nekia <atsushin@...>
 

Thanks, Manish, Yacov, and Gari.
 
 
I really appreciate for your feedback and insights.
 
(Feedback from Manish)
First, the fundamental assumption that you make is that all the block files are same across peers is incorrect. The block files are not guaranteed to contain same number of blocks across peers. This is because a block file is bounded by the file size and not by the  number of blocks. Further, the size of a given block may vary slightly on each peer. Though the header and the data section of a blocks are of same size across peers but this difference in overall size could be caused by the metadata section which contains concenter signatures. ...
Thank you so much for a quite important point. We're now reviewing and analyzing the implementation of fabric around metadata. Let me ask a question to clarify my understanding.
Say for example, block #100 is available on channel 'mychannel' within organization 'org1', does it mean that the metadata of block #100 on peer0.org1 can be different to the metadata of same block(#100) on a different peer(ex. peer1.org1)? If yes, you are right that our assumption is incorrect. That is, our feature will not be able to refer to a block data (from any peer node) which resides on the archive repository. Because locPointer (offset and length of each block within a blockfile) is not available for archived blockfiles on the repository.

 
Second, there are certain kind of queries for which a peer assumes the presence of block files in the current way. This primarily includes history queries, blocks related queries, and txid related queries. These queries may start failing or lead to crashes or unexpected results if you simply delete the files. ...
Third, somewhat similar to the second point above, peer has a feature wherein it rebuilds the statedb and historydb if they are dropped and peer is simply restarted. For this feature as well it relies on the percense of blockfiles.
We have catered for these situations. Each peer node is still able to access all the blockfiles (even if they're archived and discarded) seamlessly via as-is interface. Even after archiving blockfiles, blockchain characteristics are still maintained on the Blockchain network. So rebuilding statedb and accessing historydb are still available under this archiving feature.
Note: Hyperledger Fabric core has been modified to handle query failures when it attempts to access deleted blockfiles.

 
Fourth, I am not sure if gossip is the right communication mechanism that you want to employ for this communication. An archiver client perhaps can simply poll (or register for updates with) the archiver repository.
In early stage in our development, we used a polling mechanism to trigger archiving. But in terms of the efficiency (process and network traffic), we changed the implementation to be event driven.
 
 
Finally, I would like to understand in more details what are the benefits of having a separate repository? Why not simply let the files be there on the anchor peer and purge from other peers? If the answer is compression, then ideally we should explore a choise of writing the data in blockfiles in compressed format.
Good point. We designed this archiving feature to be as simple as possible (that is, minimal code changes to Hyperledger Fabric core). With the repository concept, we're able to access all the blockfiles (even if they're archived and discarded) seamlessly via as-is interface.
 
(Feedbacks from Yacov)
one thing I noticed while skimming the code, is that while you send the ArchivedBlockFileMsg via gossip, you are not ensuring it is eventually propagated to peers successfully.
 
This means that if a peer didn't get the message, it won't archive your file.
 
I suggest that you think of a more robust mechanism, like periodically comparing digests of ranges.
You're right. This kind of logic is lacking from our current implementation. Actually it was in our radar, but we have difficulty to implement this aspect. Thank you for pointing to a reference code for pull-based gossip.
 
(Feedbacks from Gari)
It seems the only thing you really wanted to use the peer for was to propagate information to other peers within the same organization. ...
Yes, that is one of the reasons we integrated archiving features into peer binary. But the most important reason is for handling query failures when it attempts to access deleted blockfiles. And each peer node is still able to access all the blockfiles (even if they're archived and discarded) seamlessly via as-is interface.
 
 
Thanks,
Atsushi
 


Documentation Workgroup: No call Friday, 29 November, next call December 6

Anthony O'Dowd <a_o-dowd@...>
 

Hello All,

Due to our colleagues in the US celebrating Thanksgiving there will not be a call this week! Our next call will be Dec 6.

You can read the summary minutes for last week's call: https://wiki.hyperledger.org/display/fabric/2019+11+22+DWG+Agenda
and catch up via the recordings page: https://wiki.hyperledger.org/display/fabric/Recordings

Particular highlights last week were Pam's walk through of the the new GitHub based contribution process and Joe's outline of the upgrade docs. The former is a must-see if you would like to contribute to Hyperledger Fabric documentation. The latter helps you understand how we've simplified the structure of the tasks required to of upgrade Fabric versions. It will particularly helpful as users start to move to Fabric 2.0 Thanks to Pam and Joe for these

Please feel free to contribute to next week's agenda: https://wiki.hyperledger.org/display/fabric/2019+12+06+DWG+Agenda

Look out for our next meetings on Dec 6!

Best regards,

Anthony, Pam, Joe, Nik

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: Error while migrating from kafka to RAFT

Adhav Pavan
 

Joson,

I just did as per your suggestion, signed config changes (envelop) with orderer MSP admin. 

As I already mentioned in below mail,

"When we create certificates using cryptogen tool, for peer organizations, the user admin certificate has OU as "Admin", but in the case of Orderer Organization, Certificate has OU as "client". When we sign config update block with orderer admin certs, its getting failed as I already mentioned in linked mail(The identity does not contain OU [ADMIN])."

After investigation, I changed crypto-config.yaml as  below

I have changed crypto-config.yaml in the orderer section as below and its working as expected.
 
CA:
      OrganizationalUnit: admin

 

My concern is why croytogen tool is creating a certificate with client OU, only for orderer!

Thank you so much.

Regards,
Pavan Adhav
8390114357


Re: mixing CouchDB and LevelDB

Siddharth Jain
 

thanks. this is helpful.


From: David Enyeart <enyeart@...>
Sent: Wednesday, November 27, 2019 10:51 AM
To: Siddharth Jain <siddjain@...>
Cc: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] mixing CouchDB and LevelDB
 

You can see an explanation and proposal to enforce the database target here:
https://jira.hyperledger.org/browse/FAB-17163


Dave Enyeart

"Siddharth Jain" ---11/27/2019 01:01:52 PM---I read somewhere in the docs that all nodes have to either use LevelDB or CouchDB. I can't find link

From: "Siddharth Jain" <siddjain@...>
To: "fabric@..." <fabric@...>
Date: 11/27/2019 01:01 PM
Subject: [EXTERNAL] [Hyperledger Fabric] mixing CouchDB and LevelDB
Sent by: fabric@...





I read somewhere in the docs that all nodes have to either use LevelDB or CouchDB. I can't find link to where I read this but am wondering why is that so? Since each peer's db is independent, I would have thought each peer can decide for itself what DB it wants to use. Could someone shed some light on this?




Re: mixing CouchDB and LevelDB

David Enyeart
 

You can see an explanation and proposal to enforce the database target here:
https://jira.hyperledger.org/browse/FAB-17163


Dave Enyeart

"Siddharth Jain" ---11/27/2019 01:01:52 PM---I read somewhere in the docs that all nodes have to either use LevelDB or CouchDB. I can't find link

From: "Siddharth Jain" <siddjain@...>
To: "fabric@..." <fabric@...>
Date: 11/27/2019 01:01 PM
Subject: [EXTERNAL] [Hyperledger Fabric] mixing CouchDB and LevelDB
Sent by: fabric@...





I read somewhere in the docs that all nodes have to either use LevelDB or CouchDB. I can't find link to where I read this but am wondering why is that so? Since each peer's db is independent, I would have thought each peer can decide for itself what DB it wants to use. Could someone shed some light on this?




mixing CouchDB and LevelDB

Siddharth Jain
 

I read somewhere in the docs that all nodes have to either use LevelDB or CouchDB. I can't find link to where I read this but am wondering why is that so? Since each peer's db is independent, I would have thought each peer can decide for itself what DB it wants to use. Could someone shed some light on this?


Re: Maintainer nominations

David Enyeart
 

For those of you not attending the Fabric contributor meeting today where this topic was discussed...

- There was general agreement that documentation should not be split from Fabric repository unless there is a very compelling reason to do so.
- The expectation is that all the issues previously identified in this thread could be resolved without splitting out Fabric documentation.
- As a next step, the documentation team took an action to propose a workflow such that documentation content (including translated content) in the main Fabric repository could be delivered without the need for new documentation/translation specific project maintainers.


Dave Enyeart

"Christopher Ferris" ---11/26/2019 12:26:38 PM---I think that it is important not to conflate things. There's a request to add two maintainers who's

From: "Christopher Ferris" <chris.ferris@...>
To: Me <chris.ferris@...>
Cc: Pam Andrejko <pama@...>, fabric@...
Date: 11/26/2019 12:26 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by: fabric@...





I think that it is important not to conflate things. There's a request to add two maintainers who's role will be
to help manage the Fabric documentation. I think that should be handled independent of any discussion of repository disposition.
Let's please address the two PRs for Chris and Joe independent of this broader discussion.

The generated documentation *should be* generated from the source code, and should most certainly NOT be
segregated to another repository. The authored documentation, written by humans has for the most part been
developed by a mostly disjoint set of people than those who author the code. Now, it would certainly
be nice to ensure that the code and the documentation were kept in lock-step, and even managed such that the code and doc
(and tests) were all committed as a unit; but that has almost never been the case, and it is rare to see it in practice.

There's a different skill set in developing good documentation than there is in writing good code. Both types of skills are important
to a successful project, and especially to one as significant as Fabric. I don't see a problem in having the authored content
managed in a separate repository.

Another factor is that we wanted to integrate the i18n translations and associated workflow that us currently managed
as a Hyperledger Lab process to formally incorporate it into the same repository as we manage the english source
for the documentation. We had previously discussed reconsidering that when we had separated the docs from the
core Fabric repo, as Dave had suggested. I do think that we need to revisit all of that now that we are finally over on GH.

Chris


On Tue, Nov 26, 2019 at 9:45 AM Christopher Ferris via Lists.Hyperledger.Org <chris.ferris=gmail.com@...> wrote:
    I agree that these would be two good additions to the docs maintainership. I approve.

    Chris


On Mon, Nov 25, 2019 at 5:26 PM Pam Andrejko <pama@...> wrote:
All,

I would like to nominate two new Documentation maintainers for the Hyperledger Fabric project. They are Chris Gabriel (Hyperchain Labs) and Joe Alewine (IBM).


Chris has been an instrumental member of the Documentation community workgroup for several years now. In addition to being a regular content reviewer and contributor, he is a consumer of Fabric in his own Hyperchain Labs business that he founded. The insights, perspective, and content that he's provided based on his experience have been invaluable to the documentation work group and Fabric community as a whole.

Joe has been providing important Fabric documentation for over two and half years, is recognized as an expert on the ordering service, the Fabric upgrade process and channel capabilities, and was recently recognized as a
Hyperledger significant contributor.

Adding two more Documentation Maintainers will greatly facilitate the addition and approval of Fabric documentation content going forward.

I have opened a separate PR for each nomination:

Chris Gabriel - https://github.com/hyperledger/fabric/pull/317
Joe Alewine -
https://github.com/hyperledger/fabric/pull/316

I'm requesting that existing maintainers review the nominations and indicate whether they agree with a comment in the PR. Other’s are welcome to provide their input.

Warm regards,
Pam Andrejko






Re: Error while migrating from kafka to RAFT

Adhav Pavan
 

Hello Jason,

When we create certificates using cryptogen tool, for peer organizations, the user admin certificate has OU as "Admin", but in the case of Orderer Organization, Certificate has OU as "client". When we sign config update block with orderer admin certs, its getting failed as I already mentioned in linked mail(The identity does not contain OU [ADMIN]).

Is this bug?

I have changed crypto-config.yaml in orderer section as below

CA:
      OrganizationalUnit: admin

After this change its working fine as expected.

Let me know for more information about reproducing the issue.

Thank you. 

Heartfelt Regards,
Pavan Adhav

Blockchain Developer
Cell Phone:
+91-8390114357  E-Mail: adhavpavan@...



On Mon, Nov 25, 2019 at 5:49 PM Adhav Pavan <adhavpavan@...> wrote:
Hello Jason,

Thank you so much for your reply. 

I set the following env variables on CLI.
1) CORE_PEER_LOCALMSPID=OrdererMSP

I am sure that I am signing a configuration update with admin identity, I checked the final envelope, it's having admin user identity of orderer organization.
As per your suggestion, I set the logging level to debug, Getting the orderer container logs as follows.

In log as I mentioned in bold, it seems something wrong here: "2019-11-25 07:58:51.538 UTC [cauthdsl] func2 -> DEBU e16 0xc00027ebc0 identity 0 does not satisfy principal: The identity is not an admin under this MSP [OrdererMSP]: The identity does not contain OU [ADMIN], MSP: [OrdererMSP]"

What does it mean that "The identity does not contain OU".

Please let me know for more information.

Added orderer logs as follow:

2019-11-25 07:58:51.532 UTC [orderer.common.server] Deliver -> DEBU de9 Starting new Deliver handler
2019-11-25 07:58:51.532 UTC [common.deliver] Handle -> DEBU dea Starting new deliver loop for 172.23.0.13:42140
2019-11-25 07:58:51.532 UTC [common.deliver] Handle -> DEBU deb Attempting to read seek info message from 172.23.0.13:42140
2019-11-25 07:58:51.536 UTC [orderer.common.server] Broadcast -> DEBU dec Starting new Broadcast handler
2019-11-25 07:58:51.536 UTC [orderer.common.broadcast] Handle -> DEBU ded Starting new broadcast loop for 172.23.0.13:42142
2019-11-25 07:58:51.536 UTC [orderer.common.broadcast] ProcessMessage -> DEBU dee [channel: mychannel] Broadcast is processing config update message from 172.23.0.13:42142
2019-11-25 07:58:51.536 UTC [orderer.common.msgprocessor] ProcessConfigUpdateMsg -> DEBU def Processing config update message for channel mychannel
2019-11-25 07:58:51.536 UTC [policies] Evaluate -> DEBU df0 == Evaluating *policies.implicitMetaPolicy Policy /Channel/Writers ==
2019-11-25 07:58:51.536 UTC [policies] Evaluate -> DEBU df1 This is an implicit meta policy, it will trigger other policy evaluations, whose failures may be benign
2019-11-25 07:58:51.536 UTC [policies] Evaluate -> DEBU df2 == Evaluating *policies.implicitMetaPolicy Policy /Channel/Orderer/Writers ==
2019-11-25 07:58:51.536 UTC [policies] Evaluate -> DEBU df3 This is an implicit meta policy, it will trigger other policy evaluations, whose failures may be benign
2019-11-25 07:58:51.536 UTC [policies] Evaluate -> DEBU df4 == Evaluating *cauthdsl.policy Policy /Channel/Orderer/OrdererOrg/Writers ==
2019-11-25 07:58:51.536 UTC [cauthdsl] func1 -> DEBU df5 0xc000551ab0 gate 1574668731536839047 evaluation starts
2019-11-25 07:58:51.536 UTC [cauthdsl] func2 -> DEBU df6 0xc000551ab0 signed by 0 principal evaluation starts (used [false])
2019-11-25 07:58:51.536 UTC [cauthdsl] func2 -> DEBU df7 0xc000551ab0 processing identity 0 with bytes of a1f390
2019-11-25 07:58:51.536 UTC [cauthdsl] func2 -> DEBU df8 0xc000551ab0 principal matched by identity 0
2019-11-25 07:58:51.536 UTC [msp.identity] Verify -> DEBU df9 Verify: digest = 00000000  71 64 9c ef 57 44 8f a2  2a 1f cd 9f 8d a3 42 47  |qd..WD..*.....BG|
00000010  40 06 8c 3e 9d 0b 61 7b  c9 dc 76 65 5d a9 7e cd  |@..>..a{..ve].~.|
2019-11-25 07:58:51.536 UTC [msp.identity] Verify -> DEBU dfa Verify: sig = 00000000  30 44 02 20 2d e7 d4 18  43 95 3e cd dd b3 31 a8  |0D. -...C.>...1.|
00000010  48 dd a6 61 51 6e a8 35  79 4a ac 8e c3 be a5 88  |H..aQn.5yJ......|
00000020  43 6d e5 57 02 20 46 de  34 30 b6 75 1b 94 32 04  |Cm.W. F.40.u..2.|
00000030  11 7c 14 09 3c af f1 c0  6a cf 69 e0 3a 2c 67 cd  |.|..<...j.i.:,g.|
00000040  c1 44 e1 40 70 14                                 |.D.@p.|
2019-11-25 07:58:51.537 UTC [cauthdsl] func2 -> DEBU dfb 0xc000551ab0 principal evaluation succeeds for identity 0
2019-11-25 07:58:51.537 UTC [cauthdsl] func1 -> DEBU dfc 0xc000551ab0 gate 1574668731536839047 evaluation succeeds
2019-11-25 07:58:51.537 UTC [policies] Evaluate -> DEBU dfd Signature set satisfies policy /Channel/Orderer/OrdererOrg/Writers
2019-11-25 07:58:51.537 UTC [policies] Evaluate -> DEBU dfe == Done Evaluating *cauthdsl.policy Policy /Channel/Orderer/OrdererOrg/Writers
2019-11-25 07:58:51.537 UTC [policies] Evaluate -> DEBU dff Signature set satisfies policy /Channel/Orderer/Writers
2019-11-25 07:58:51.537 UTC [policies] Evaluate -> DEBU e00 == Done Evaluating *policies.implicitMetaPolicy Policy /Channel/Orderer/Writers
2019-11-25 07:58:51.537 UTC [policies] Evaluate -> DEBU e01 Signature set satisfies policy /Channel/Writers
2019-11-25 07:58:51.537 UTC [policies] Evaluate -> DEBU e02 == Done Evaluating *policies.implicitMetaPolicy Policy /Channel/Writers
2019-11-25 07:58:51.537 UTC [common.configtx] addToMap -> DEBU e03 Adding to config map: [Group]  /Channel
2019-11-25 07:58:51.537 UTC [common.configtx] addToMap -> DEBU e04 Adding to config map: [Group]  /Channel/Orderer
2019-11-25 07:58:51.537 UTC [common.configtx] addToMap -> DEBU e05 Adding to config map: [Group]  /Channel
2019-11-25 07:58:51.537 UTC [common.configtx] addToMap -> DEBU e06 Adding to config map: [Group]  /Channel/Orderer
2019-11-25 07:58:51.537 UTC [common.configtx] addToMap -> DEBU e07 Adding to config map: [Value]  /Channel/Orderer/ConsensusType
2019-11-25 07:58:51.537 UTC [common.configtx] verifyDeltaSet -> DEBU e08 Processing change to key: [Value]  /Channel/Orderer/ConsensusType
2019-11-25 07:58:51.538 UTC [common.configtx] policyForItem -> DEBU e09 Getting policy for item ConsensusType with mod_policy Admins
2019-11-25 07:58:51.538 UTC [policies] Manager -> DEBU e0a Manager Channel looking up path [Orderer]
2019-11-25 07:58:51.538 UTC [policies] Manager -> DEBU e0b Manager Channel has managers Orderer
2019-11-25 07:58:51.538 UTC [policies] Manager -> DEBU e0c Manager Channel has managers Application
2019-11-25 07:58:51.538 UTC [policies] Manager -> DEBU e0d Manager Channel/Orderer looking up path []
2019-11-25 07:58:51.538 UTC [policies] Manager -> DEBU e0e Manager Channel/Orderer has managers OrdererOrg
2019-11-25 07:58:51.538 UTC [policies] Evaluate -> DEBU e0f == Evaluating *policies.implicitMetaPolicy Policy /Channel/Orderer/Admins ==
2019-11-25 07:58:51.538 UTC [policies] Evaluate -> DEBU e10 This is an implicit meta policy, it will trigger other policy evaluations, whose failures may be benign
2019-11-25 07:58:51.538 UTC [policies] Evaluate -> DEBU e11 == Evaluating *cauthdsl.policy Policy /Channel/Orderer/OrdererOrg/Admins ==
2019-11-25 07:58:51.538 UTC [cauthdsl] deduplicate -> WARN e12 De-duplicating identity [OrdererMSPf9d56d03cda533fcbbf7cc1e9b21bea8e2643614c07c45bb8d69159dfb4d733e] at index 1 in signature set
2019-11-25 07:58:51.538 UTC [cauthdsl] func1 -> DEBU e13 0xc00027ebc0 gate 1574668731538228424 evaluation starts
2019-11-25 07:58:51.538 UTC [cauthdsl] func2 -> DEBU e14 0xc00027ebc0 signed by 0 principal evaluation starts (used [false false])
2019-11-25 07:58:51.538 UTC [cauthdsl] func2 -> DEBU e15 0xc00027ebc0 processing identity 0 with bytes of a1f390
2019-11-25 07:58:51.538 UTC [cauthdsl] func2 -> DEBU e16 0xc00027ebc0 identity 0 does not satisfy principal: The identity is not an admin under this MSP [OrdererMSP]: The identity does not contain OU [ADMIN], MSP: [OrdererMSP]
2019-11-25 07:58:51.538 UTC [cauthdsl] func2 -> DEBU e17 0xc00027ebc0 principal evaluation fails
2019-11-25 07:58:51.538 UTC [cauthdsl] func1 -> DEBU e18 0xc00027ebc0 gate 1574668731538228424 evaluation fails
2019-11-25 07:58:51.538 UTC [policies] Evaluate -> DEBU e19 Signature set did not satisfy policy /Channel/Orderer/OrdererOrg/Admins
2019-11-25 07:58:51.538 UTC [policies] Evaluate -> DEBU e1a == Done Evaluating *cauthdsl.policy Policy /Channel/Orderer/OrdererOrg/Admins
2019-11-25 07:58:51.538 UTC [policies] func1 -> DEBU e1b Evaluation Failed: Only 0 policies were satisfied, but needed 1 of [ OrdererOrg/Admins ]
2019-11-25 07:58:51.538 UTC [policies] Evaluate -> DEBU e1c Signature set did not satisfy policy /Channel/Orderer/Admins
2019-11-25 07:58:51.538 UTC [policies] Evaluate -> DEBU e1d == Done Evaluating *policies.implicitMetaPolicy Policy /Channel/Orderer/Admins
2019-11-25 07:58:51.538 UTC [orderer.common.broadcast] ProcessMessage -> WARN e1e [channel: mychannel] Rejecting broadcast of config message from 172.23.0.13:42142 because of error: error applying config update to existing channel 'mychannel': error authorizing update: error validating DeltaSet: policy for [Value]  /Channel/Orderer/ConsensusType not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied



Thank you so much for your help.

Heartfelt Regards,
Pavan Adhav

Blockchain Developer
Cell Phone:
+91-8390114357  E-Mail: adhavpavan@...



On Thu, Nov 21, 2019 at 9:11 PM Jason K Yellick <jyellick@...> wrote:
Are you certain you're using the MSP of an admin user from your orderer org (not an orderer process MSP)?  That error is quite explicit, it says you tried to modify /Channel/Orderer/ConsensusType, but, your update did not satisfy the modification policy (/Channel/Orderer/Admins). The update failed because /Channel/Orderer/Admins requires that the /Channel/Orderer/OrdererOrg/Admins policy be satisfied, but it was not.

This is BYFN so all of these policies should be at their default values, so a single orderer admin signature should suffice.  You can always set `FABRIC_LOGGING_SPEC=info:msp=debug:cauthdsl=debug:policy=debug` for some more detail in the orderer logs about exactly why the evaluation failure is failing, but it is almost definitely one of:

1) You specified the wrong MSPID in your env for the sign/send
2) You specified the wrong MSP path in your env for te sign/send

~Jason
 
----- Original message -----
From: Adhav Pavan <adhavpavan@...>
To: Jason K Yellick <jyellick@...>
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Error while migrating from kafka to RAFT
Date: Thu, Nov 21, 2019 1:44 AM
 
Hello Jason,
 
Than you so much for the quick reply.
 
As you suggested, I signed the config block with OrdererMSP and sent an update request to the orderer but no luck, getting same error message.
 

Heartfelt Regards,
Pavan Adhav

Blockchain Developer
Cell Phone:
+91-8390114357  E-Mail: adhavpavan@...
 

 
On Thu, Nov 21, 2019 at 11:29 AM Jason K Yellick <jyellick@...> wrote:
You need to sign and submit with the OrdererMSP admin identity to change consensus type parameters, not the application/peer org admins.

Thanks,
~Jason
 
----- Original message -----
From: "Adhav Pavan" <adhavpavan@...>
Sent by: fabric@...
To: fabric@...
Cc: saurabh@...
Subject: [EXTERNAL] [Hyperledger Fabric] Error while migrating from kafka to RAFT
Date: Wed, Nov 20, 2019 11:48 PM
 
Hello Team,
 
I am migrating from kafka to raft, When I have changed state from "NORMAL" to "STATE_MAINTENANCE"  and created the final expected envelope as per the procedure.
 
Note: We are using BYFN script
 
My CLI pointed to Org1MSP, I signed config update transaction, later I changed CLI pointing to Org2MSP and signed, finally submitted the new channel config update to the orderer.
After submission, getting a following error message.
 
Error on CLI: "Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'mychannel': error authorizing update: error validating DeltaSet: policy for [Value]  /Channel/Orderer/ConsensusType not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied"
 
Orderer log: "[channel: mychannel] Rejecting broadcast of config message from 172.21.0.13:51078 because of error: error applying config update to existing channel 'mychannel': error authorizing update: error validating DeltaSet: policy for [Value]  /Channel/Orderer/ConsensusType not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied"
 
Please let me know if I am doing something wrong.
 
Thanks in advance.
 

Heartfelt Regards,
Pavan Adhav

Blockchain Developer
Cell Phone:
+91-8390114357  E-Mail: adhavpavan@...
 

 
 


Re: Maintainer nominations

Zhenhua Zhao <zhao.zhenhua@...>
 

I’m glad to see doc is being a hot topic. Technical Working Group China(TWGC) has been working more than a year translating  fabric doc into Chinese. There are more than 10 active volunteers who translate doc, we have tried different methods to collaborate with others, like using personal repo’s, hyperledger lab repo, or on personal local machine, and professional translating platform(I shared how to support multi-language docs on a fabric playback meeting). 


I’d like share my options with you.

1. Documentation is quit different with code.  Documentation has its owner format/structure, like .md, .rst, and a single topic may have .md files, .png files. The best way to write & review doc is with a WYSIWYG tool, like MS Word. Github is not a ideal tool for it.
2. With supporting i18n,  a professional translating platform is required. Translating process is topic by topic, translating, reviewing then submit, it makes doc has different release rhythm, so using separated repos is better. 
3. Writing/Reviewing documentation requires different skills with coding, especially for translating,  doc maintainers are indeed needed. 


Rich Zhao



On Nov 27, 2019, at 1:08 AM, Yacov <yacovm@...> wrote:

I have no clue in AZP, perhaps Brett can shed some light here, but - can't you just put in our scripts something that does a git show --name-only and returns immediately in case there are only changes to markdown or RST files?



From:        David Enyeart/Durham/IBM
To:        "Gari Singh" <garis@...>
Cc:        fabric@..., "Matthew Sykes" <matthew.sykes@...>, "Yacov Manevich" <YACOVM@...>
Date:        11/26/2019 06:02 PM
Subject:        Re: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations



Ok, we're getting closer. CODEOWNERS does indeed buy us some options.

I think that would take us down to two remaining concerns with docs in Fabric repo. Anybody have ideas on solving these?

1) Doc translation - we could have a CODEOWNER per translation directory, but it still requires the translation CODEOWNER to be a Fabric maintainer, not something we'd want.

2) With the transition to Azure Pipelines, there is not (yet) an easy way to suppress CI for doc-only PRs.


Dave Enyeart




From:        "Gari Singh" <garis@...>
To:        "Yacov Manevich" <YACOVM@...>
Cc:        "Matthew Sykes" <matthew.sykes@...>, fabric@...
Date:        11/26/2019 09:52 AM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by:        fabric@...




I too believe that the documentation belongs with the code.
I also do not believe that every person who contributes should become a maintainer ... especially when they do not have a history of actually doing reviews.
Likely some of the current maintainers should be retired as well given they do not do a lot of reviews.

But I think people are actually missing the point that Matt is making.  From the conversations I have seen, people believe that we do not merge changes to documentation fast enough.  So the solution is to move them out to another repository and likely change the approval requirements to NACR (single approver).  So we are making this change to avoid dealing with the fundamental issue:  the heavyweight process we have for approving changes to the fabric repo.

There are alternative solutions:

Now let's say that we believe there are certain domains in the fabric codebase which we believe require review from a subset of "experts" on that code.  This is easily handled by using CODEOWNERS and assigning a subset of maintainers to specific pieces of the code.  We can NACR in general but will not be able to merge changes to certain parts of the code without a review from some on the CODEOWNERS list.




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

-----fabric@... wrote: -----
To: "Matthew Sykes" <matthew.sykes@...>
From: "Yacov" 
Sent by: fabric@...
Date: 11/26/2019 09:41AM
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations

The SDK documentation and CA is only documentation about APIs, it's not documentation about concepts, ideas, and tutorials. 

I don't think that extracting the fabric documentation files out of the fabric repository would harm contribution - why would it ? 

You can just link to the document repository from the readme.md of the Fabric repository and everyone would find it just as they find the files inside the docs repository. 

> The repositories were not separated because they had different maintainer pools
In the past, the fabric-CA and fabric-node-SDK repositories inherited the maintainers of the fabric core, and that was a bad thing, because the only people that could merge code were those in the intersection of understanding the code in the corresponding repositories, and that were also fabric core maintainers.
As time went by, they were given their own maintainers and then progress was quicker. 




From:        "Matthew Sykes" <matthew.sykes@...>
To:        fabric@...
Date:        11/26/2019 04:29 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by:        fabric@...



For the record, I am not in favor of extracting the documentation. I strongly feel that the doc and the code should live together where feasible. My perspective is that lowering the barriers to contribute is far better than segmenting the ecosystem into a number of fiefdoms.

If we want doc changes to only require a single doc review, we should state that's the desired process and put a technology plan in place to make that happen.

With that, a few comments to Dave's note:

> As Fabric has grown the sets of maintainers has naturally diverged across the fabric-* repos. The core Fabric maintainers are naturally different from the Fabric CA maintainers, the Java SDK maintainers, the Node.js SDK maintainers, etc. 

The repositories were not separated because they had different maintainer pools; they were separated because, in most cases, they use fundamentally different implementation and CI processes. I'll also note that each of these contain their own documentation tree. (There's a docs folder in CA and API documentation is part of the code in node and Java.) Are you proposing we split all of these out as well?

> It has been challenging to get a majority of core Fabric maintainers to weigh in on decisions, since only about half of the maintainers are active day-to-day. This becomes more of an issue with the recent introduction of the fabric-rfcs process, which requires a majority of Fabric maintainers to agree before taking on new enhancements.

This is a problem of our own making. We have far too much process in place to make rapid forward movement. It's our choice to require a "majority" of maintainers and "2 mandatory reviews" to integrate things.

On Tue, Nov 26, 2019 at 7:11 AM David Enyeart <enyeart@...> wrote:
The intent of my proposal was exactly as Yacov says - doc maintainers would be comprised of the core Fabric maintainers in addition to heavy doc contributors/reviewers.

I do understand Brian's point, and we have been hesitant to split fabric code and fabric docs repos/maintainers up until now for the reasons Brian mentions. However in my opinion the time has come to split them for the following reasons:

As Fabric has grown the sets of maintainers has naturally diverged across the fabric-* repos. The core Fabric maintainers are naturally different from the Fabric CA maintainers, the Java SDK maintainers, the Node.js SDK maintainers, etc. We've had good results with different maintainers for each of these repos.

It has been challenging to get a majority of core Fabric maintainers to weigh in on decisions, since only about half of the maintainers are active day-to-day. This becomes more of an issue with the recent introduction of the fabric-rfcs process, which requires a majority of Fabric maintainers to agree before taking on new enhancements.

With the transition to Azure Pipelines, there is not (yet) an easy way to suppress CI for doc-only PRs.

With the transition to GitHub, we would like different branch protection rules for Fabric code and Fabric docs.


Dave Enyeart

"Yacov" ---11/26/2019 01:49:37 AM---I think the best solution for these 2 seemingly conflicting ideas is: All maintainers of code reposi

From: "Yacov" <yacovm@...>
To: "Brian Behlendorf" <bbehlendorf@...>
Cc: fabric@...
Date: 11/26/2019 01:49 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by: fabric@...



I think the best solution for these 2 seemingly conflicting ideas is:All maintainers of code repositories 
should be ableto merge documentation contributionsMaintainers of the documentation 
should not be able to merge code contributions.


From: "Brian Behlendorf" <bbehlendorf@...>
To: fabric@...
Date: 11/26/2019 07:36 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by: fabric@...



On 11/25/19 6:09 PM, David Enyeart wrote:
I'd suggest that we identify the top documentation contributors and reviewers to seed the fabric docs repository maintainer list in the coming weeks (including Chris and Joe), rather than pulling the trigger in the Fabric repository this week.Are there separate maintainer pools for different fabric-* repos? 
If so, I can understand the argument, coming from a world where the precautionary principle would apply, and where prior version control systems (and even earlier versions of git) allowed for a dangerous degree of repository damage if someone made the wrong set of changes. I also of course get the point for different maintainers for different Hyperledger projects, e.g. Fabric vs Sawtooth. 
But for the same project, which is arguably the same "community" of contributors and representatives of end-users, you may want to consider a single pool of maintainers across all fabric-* repos. The easy case is to argue for the ability for anyone who's a maintainer on the main code repos to also be able to merge in changes into docs-related repos. The harder case is for people who come in as solid contributors to docs, but aren't (yet!) code contributors. There, I'd still argue for it - the boundary between docs and code is rarely so hard, as changes to error messages/logging or admin/user interfaces often are driven by a docs-level view of what would be easier to explain. And, I've seen great core developers on projects come in first through a docs-related role. Also, just for simplicity: I'll counter your precautionary principle with an Occam's Razor, which makes understanding the project easier for newcomers. I bet reversing any mistaken merges is a lower cost than the value of contributions you might not otherwise see. 
Up to you all, 
Brian 
-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf








-- 
Matthew Sykes
matthew.sykes@...

















Re: Maintainer nominations

Christopher Ferris
 

I think that it is important not to conflate things. There's a request to add two maintainers who's role will be
to help manage the Fabric documentation. I think that should be handled independent of any discussion of repository disposition.
Let's please address the two PRs for Chris and Joe independent of this broader discussion.

The generated documentation *should be* generated from the source code, and should most certainly NOT be
segregated to another repository. The authored documentation, written by humans has for the most part been
developed by a mostly disjoint set of people than those who author the code. Now, it would certainly
be nice to ensure that the code and the documentation were kept in lock-step, and even managed such that the code and doc
(and tests) were all committed as a unit; but that has almost never been the case, and it is rare to see it in practice.

There's a different skill set in developing good documentation than there is in writing good code. Both types of skills are important
to a successful project, and especially to one as significant as Fabric. I don't see a problem in having the authored content
managed in a separate repository.

Another factor is that we wanted to integrate the i18n translations and associated workflow that us currently managed
as a Hyperledger Lab process to formally incorporate it into the same repository as we manage the english source
for the documentation. We had previously discussed reconsidering that when we had separated the docs from the
core Fabric repo, as Dave had suggested. I do think that we need to revisit all of that now that we are finally over on GH.

Chris


On Tue, Nov 26, 2019 at 9:45 AM Christopher Ferris via Lists.Hyperledger.Org <chris.ferris=gmail.com@...> wrote:

I agree that these would be two good additions to the docs maintainership. I approve.

Chris

On Mon, Nov 25, 2019 at 5:26 PM Pam Andrejko <pama@...> wrote:

All,

I would like to nominate two new Documentation maintainers for the Hyperledger Fabric project. They are Chris Gabriel (Hyperchain Labs) and Joe Alewine (IBM).

Chris has been an instrumental member of the Documentation community workgroup for several years now. In addition to being a regular content reviewer and contributor, he is a consumer of Fabric in his own Hyperchain Labs business that he founded. The insights, perspective, and content that he's provided based on his experience have been invaluable to the documentation work group and Fabric community as a whole.

Joe has been providing important Fabric documentation for over two and half years, is recognized as an expert on the ordering service, the Fabric upgrade process and channel capabilities, and was recently recognized as a Hyperledger significant contributor.

Adding two more Documentation Maintainers will greatly facilitate the addition and approval of Fabric documentation content going forward.

I have opened a separate PR for each nomination:

Chris Gabriel - https://github.com/hyperledger/fabric/pull/317
Joe Alewine - https://github.com/hyperledger/fabric/pull/316

I'm requesting that existing maintainers review the nominations and indicate whether they agree with a comment in the PR. Other’s are welcome to provide their input.

Warm regards,
Pam Andrejko


Re: Maintainer nominations

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

We could gate the DocBuild, UT and IT behind the success of VerifyBuild like we do today, and can set variables (BuildDoc and RunTests) as true or false and make them the conditions on which the DocBuild and UT and IT run, i.e. https://docs.microsoft.com/en-us/azure/devops/pipelines/process/expressions?view=azure-devops#dependencies (This is in .NET for Windows syntax, it wouldn't look exactly like this, but you get the idea)
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: "Yacov" <yacovm@...>
Sent by: fabric@...
To: "David Enyeart" <enyeart@...>
Cc: "Gari Singh" <garis@...>, fabric@..., "Matthew Sykes" <matthew.sykes@...>, "Brett T Logan" <Brett.T.Logan@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Date: Tue, Nov 26, 2019 12:08 PM
 
I have no clue in AZP, perhaps Brett can shed some light here, but - can't you just put in our scripts something that does a git show --name-only and returns immediately in case there are only changes to markdown or RST files?



From:        David Enyeart/Durham/IBM
To:        "Gari Singh" <garis@...>
Cc:        fabric@..., "Matthew Sykes" <matthew.sykes@...>, "Yacov Manevich" <YACOVM@...>
Date:        11/26/2019 06:02 PM
Subject:        Re: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations


Ok, we're getting closer. CODEOWNERS does indeed buy us some options.

I think that would take us down to two remaining concerns with docs in Fabric repo. Anybody have ideas on solving these?

1) Doc translation - we could have a CODEOWNER per translation directory, but it still requires the translation CODEOWNER to be a Fabric maintainer, not something we'd want.

2) With the transition to Azure Pipelines, there is not (yet) an easy way to suppress CI for doc-only PRs.


Dave Enyeart




From:        "Gari Singh" <garis@...>
To:        "Yacov Manevich" <YACOVM@...>
Cc:        "Matthew Sykes" <matthew.sykes@...>, fabric@...
Date:        11/26/2019 09:52 AM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by:        fabric@...



I too believe that the documentation belongs with the code.
I also do not believe that every person who contributes should become a maintainer ... especially when they do not have a history of actually doing reviews.
Likely some of the current maintainers should be retired as well given they do not do a lot of reviews.

But I think people are actually missing the point that Matt is making.  From the conversations I have seen, people believe that we do not merge changes to documentation fast enough.  So the solution is to move them out to another repository and likely change the approval requirements to NACR (single approver).  So we are making this change to avoid dealing with the fundamental issue:  the heavyweight process we have for approving changes to the fabric repo.

There are alternative solutions:

Now let's say that we believe there are certain domains in the fabric codebase which we believe require review from a subset of "experts" on that code.  This is easily handled by using CODEOWNERS and assigning a subset of maintainers to specific pieces of the code.  We can NACR in general but will not be able to merge changes to certain parts of the code without a review from some on the CODEOWNERS list.




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

-----fabric@... wrote: -----
To: "Matthew Sykes" <matthew.sykes@...>
From: "Yacov"
Sent by: fabric@...
Date: 11/26/2019 09:41AM
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations

The SDK documentation and CA is only documentation about APIs, it's not documentation about concepts, ideas, and tutorials.

I don't think that extracting the fabric documentation files out of the fabric repository would harm contribution - why would it ?

You can just link to the document repository from the readme.md of the Fabric repository and everyone would find it just as they find the files inside the docs repository.

> The repositories were not separated because they had different maintainer pools
In the past, the fabric-CA and fabric-node-SDK repositories inherited the maintainers of the fabric core, and that was a bad thing, because the only people that could merge code were those in the intersection of understanding the code in the corresponding repositories, and that were also fabric core maintainers.
As time went by, they were given their own maintainers and then progress was quicker.




From:        "Matthew Sykes" <matthew.sykes@...>
To:        fabric@...
Date:        11/26/2019 04:29 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by:        fabric@...



For the record, I am not in favor of extracting the documentation. I strongly feel that the doc and the code should live together where feasible. My perspective is that lowering the barriers to contribute is far better than segmenting the ecosystem into a number of fiefdoms.

If we want doc changes to only require a single doc review, we should state that's the desired process and put a technology plan in place to make that happen.

With that, a few comments to Dave's note:

> As Fabric has grown the sets of maintainers has naturally diverged across the fabric-* repos. The core Fabric maintainers are naturally different from the Fabric CA maintainers, the Java SDK maintainers, the Node.js SDK maintainers, etc.

The repositories were not separated because they had different maintainer pools; they were separated because, in most cases, they use fundamentally different implementation and CI processes. I'll also note that each of these contain their own documentation tree. (There's a docs folder in CA and API documentation is part of the code in node and Java.) Are you proposing we split all of these out as well?

> It has been challenging to get a majority of core Fabric maintainers to weigh in on decisions, since only about half of the maintainers are active day-to-day. This becomes more of an issue with the recent introduction of the fabric-rfcs process, which requires a majority of Fabric maintainers to agree before taking on new enhancements.

This is a problem of our own making. We have far too much process in place to make rapid forward movement. It's our choice to require a "majority" of maintainers and "2 mandatory reviews" to integrate things.

On Tue, Nov 26, 2019 at 7:11 AM David Enyeart <enyeart@...> wrote:
The intent of my proposal was exactly as Yacov says - doc maintainers would be comprised of the core Fabric maintainers in addition to heavy doc contributors/reviewers.

I do understand Brian's point, and we have been hesitant to split fabric code and fabric docs repos/maintainers up until now for the reasons Brian mentions. However in my opinion the time has come to split them for the following reasons:

As Fabric has grown the sets of maintainers has naturally diverged across the fabric-* repos. The core Fabric maintainers are naturally different from the Fabric CA maintainers, the Java SDK maintainers, the Node.js SDK maintainers, etc. We've had good results with different maintainers for each of these repos.

It has been challenging to get a majority of core Fabric maintainers to weigh in on decisions, since only about half of the maintainers are active day-to-day. This becomes more of an issue with the recent introduction of the fabric-rfcs process, which requires a majority of Fabric maintainers to agree before taking on new enhancements.

With the transition to Azure Pipelines, there is not (yet) an easy way to suppress CI for doc-only PRs.

With the transition to GitHub, we would like different branch protection rules for Fabric code and Fabric docs.


Dave Enyeart

"Yacov" ---11/26/2019 01:49:37 AM---I think the best solution for these 2 seemingly conflicting ideas is: All maintainers of code reposi

From: "Yacov" <yacovm@...>
To: "Brian Behlendorf" <bbehlendorf@...>
Cc: fabric@...
Date: 11/26/2019 01:49 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by: fabric@...



I think the best solution for these 2 seemingly conflicting ideas is:All maintainers of code repositories
should be ableto merge documentation contributionsMaintainers of the documentation
should not be able to merge code contributions.


From: "Brian Behlendorf" <bbehlendorf@...>
To: fabric@...
Date: 11/26/2019 07:36 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by: fabric@...



On 11/25/19 6:09 PM, David Enyeart wrote:
I'd suggest that we identify the top documentation contributors and reviewers to seed the fabric docs repository maintainer list in the coming weeks (including Chris and Joe), rather than pulling the trigger in the Fabric repository this week.Are there separate maintainer pools for different fabric-* repos?
If so, I can understand the argument, coming from a world where the precautionary principle would apply, and where prior version control systems (and even earlier versions of git) allowed for a dangerous degree of repository damage if someone made the wrong set of changes. I also of course get the point for different maintainers for different Hyperledger projects, e.g. Fabric vs Sawtooth.
But for the same project, which is arguably the same "community" of contributors and representatives of end-users, you may want to consider a single pool of maintainers across all fabric-* repos. The easy case is to argue for the ability for anyone who's a maintainer on the main code repos to also be able to merge in changes into docs-related repos. The harder case is for people who come in as solid contributors to docs, but aren't (yet!) code contributors. There, I'd still argue for it - the boundary between docs and code is rarely so hard, as changes to error messages/logging or admin/user interfaces often are driven by a docs-level view of what would be easier to explain. And, I've seen great core developers on projects come in first through a docs-related role. Also, just for simplicity: I'll counter your precautionary principle with an Occam's Razor, which makes understanding the project easier for newcomers. I bet reversing any mistaken merges is a lower cost than the value of contributions you might not otherwise see.
Up to you all,
Brian
--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf








--
Matthew Sykes
matthew.sykes@...















 
 


Re: Maintainer nominations

Yacov
 

I have no clue in AZP, perhaps Brett can shed some light here, but - can't you just put in our scripts something that does a git show --name-only and returns immediately in case there are only changes to markdown or RST files?



From:        David Enyeart/Durham/IBM
To:        "Gari Singh" <garis@...>
Cc:        fabric@..., "Matthew Sykes" <matthew.sykes@...>, "Yacov Manevich" <YACOVM@...>
Date:        11/26/2019 06:02 PM
Subject:        Re: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations



Ok, we're getting closer. CODEOWNERS does indeed buy us some options.

I think that would take us down to two remaining concerns with docs in Fabric repo. Anybody have ideas on solving these?

1) Doc translation - we could have a CODEOWNER per translation directory, but it still requires the translation CODEOWNER to be a Fabric maintainer, not something we'd want.

2) With the transition to Azure Pipelines, there is not (yet) an easy way to suppress CI for doc-only PRs.


Dave Enyeart




From:        "Gari Singh" <garis@...>
To:        "Yacov Manevich" <YACOVM@...>
Cc:        "Matthew Sykes" <matthew.sykes@...>, fabric@...
Date:        11/26/2019 09:52 AM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by:        fabric@...




I too believe that the documentation belongs with the code.
I also do not believe that every person who contributes should become a maintainer ... especially when they do not have a history of actually doing reviews.
Likely some of the current maintainers should be retired as well given they do not do a lot of reviews.

But I think people are actually missing the point that Matt is making.  From the conversations I have seen, people believe that we do not merge changes to documentation fast enough.  So the solution is to move them out to another repository and likely change the approval requirements to NACR (single approver).  So we are making this change to avoid dealing with the fundamental issue:  the heavyweight process we have for approving changes to the fabric repo.

There are alternative solutions:

Now let's say that we believe there are certain domains in the fabric codebase which we believe require review from a subset of "experts" on that code.  This is easily handled by using CODEOWNERS and assigning a subset of maintainers to specific pieces of the code.  We can NACR in general but will not be able to merge changes to certain parts of the code without a review from some on the CODEOWNERS list.




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

-----fabric@... wrote: -----
To: "Matthew Sykes" <matthew.sykes@...>
From: "Yacov"
Sent by: fabric@...
Date: 11/26/2019 09:41AM
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations

The SDK documentation and CA is only documentation about APIs, it's not documentation about concepts, ideas, and tutorials.

I don't think that extracting the fabric documentation files out of the fabric repository would harm contribution - why would it ?

You can just link to the document repository from the readme.md of the Fabric repository and everyone would find it just as they find the files inside the docs repository.

> The repositories were not separated because they had different maintainer pools
In the past, the fabric-CA and fabric-node-SDK repositories inherited the maintainers of the fabric core, and that was a bad thing, because the only people that could merge code were those in the intersection of understanding the code in the corresponding repositories, and that were also fabric core maintainers.
As time went by, they were given their own maintainers and then progress was quicker.




From:        "Matthew Sykes" <matthew.sykes@...>
To:        fabric@...
Date:        11/26/2019 04:29 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by:        fabric@...



For the record, I am not in favor of extracting the documentation. I strongly feel that the doc and the code should live together where feasible. My perspective is that lowering the barriers to contribute is far better than segmenting the ecosystem into a number of fiefdoms.

If we want doc changes to only require a single doc review, we should state that's the desired process and put a technology plan in place to make that happen.

With that, a few comments to Dave's note:

> As Fabric has grown the sets of maintainers has naturally diverged across the fabric-* repos. The core Fabric maintainers are naturally different from the Fabric CA maintainers, the Java SDK maintainers, the Node.js SDK maintainers, etc.

The repositories were not separated because they had different maintainer pools; they were separated because, in most cases, they use fundamentally different implementation and CI processes. I'll also note that each of these contain their own documentation tree. (There's a docs folder in CA and API documentation is part of the code in node and Java.) Are you proposing we split all of these out as well?

> It has been challenging to get a majority of core Fabric maintainers to weigh in on decisions, since only about half of the maintainers are active day-to-day. This becomes more of an issue with the recent introduction of the fabric-rfcs process, which requires a majority of Fabric maintainers to agree before taking on new enhancements.

This is a problem of our own making. We have far too much process in place to make rapid forward movement. It's our choice to require a "majority" of maintainers and "2 mandatory reviews" to integrate things.


On Tue, Nov 26, 2019 at 7:11 AM David Enyeart <enyeart@...> wrote:
The intent of my proposal was exactly as Yacov says - doc maintainers would be comprised of the core Fabric maintainers in addition to heavy doc contributors/reviewers.

I do understand Brian's point, and we have been hesitant to split fabric code and fabric docs repos/maintainers up until now for the reasons Brian mentions. However in my opinion the time has come to split them for the following reasons:

As Fabric has grown the sets of maintainers has naturally diverged across the fabric-* repos. The core Fabric maintainers are naturally different from the Fabric CA maintainers, the Java SDK maintainers, the Node.js SDK maintainers, etc. We've had good results with different maintainers for each of these repos.

It has been challenging to get a majority of core Fabric maintainers to weigh in on decisions, since only about half of the maintainers are active day-to-day. This becomes more of an issue with the recent introduction of the fabric-rfcs process, which requires a majority of Fabric maintainers to agree before taking on new enhancements.

With the transition to Azure Pipelines, there is not (yet) an easy way to suppress CI for doc-only PRs.

With the transition to GitHub, we would like different branch protection rules for Fabric code and Fabric docs.


Dave Enyeart

"Yacov" ---11/26/2019 01:49:37 AM---I think the best solution for these 2 seemingly conflicting ideas is: All maintainers of code reposi

From: "Yacov" <yacovm@...>
To: "Brian Behlendorf" <bbehlendorf@...>
Cc: fabric@...
Date: 11/26/2019 01:49 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by: fabric@...



I think the best solution for these 2 seemingly conflicting ideas is:All maintainers of code repositories
should be ableto merge documentation contributionsMaintainers of the documentation
should not be able to merge code contributions.


From: "Brian Behlendorf" <bbehlendorf@...>
To: fabric@...
Date: 11/26/2019 07:36 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by: fabric@...



On 11/25/19 6:09 PM, David Enyeart wrote:
I'd suggest that we identify the top documentation contributors and reviewers to seed the fabric docs repository maintainer list in the coming weeks (including Chris and Joe), rather than pulling the trigger in the Fabric repository this week.Are there separate maintainer pools for different fabric-* repos?
If so, I can understand the argument, coming from a world where the precautionary principle would apply, and where prior version control systems (and even earlier versions of git) allowed for a dangerous degree of repository damage if someone made the wrong set of changes. I also of course get the point for different maintainers for different Hyperledger projects, e.g. Fabric vs Sawtooth.
But for the same project, which is arguably the same "community" of contributors and representatives of end-users, you may want to consider a single pool of maintainers across all fabric-* repos. The easy case is to argue for the ability for anyone who's a maintainer on the main code repos to also be able to merge in changes into docs-related repos. The harder case is for people who come in as solid contributors to docs, but aren't (yet!) code contributors. There, I'd still argue for it - the boundary between docs and code is rarely so hard, as changes to error messages/logging or admin/user interfaces often are driven by a docs-level view of what would be easier to explain. And, I've seen great core developers on projects come in first through a docs-related role. Also, just for simplicity: I'll counter your precautionary principle with an Occam's Razor, which makes understanding the project easier for newcomers. I bet reversing any mistaken merges is a lower cost than the value of contributions you might not otherwise see.
Up to you all,
Brian
--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf








--
Matthew Sykes
matthew.sykes@...
















Re: Maintainer nominations

David Enyeart
 

Ok, we're getting closer. CODEOWNERS does indeed buy us some options.

I think that would take us down to two remaining concerns with docs in Fabric repo. Anybody have ideas on solving these?

1) Doc translation - we could have a CODEOWNER per translation directory, but it still requires the translation CODEOWNER to be a Fabric maintainer, not something we'd want.

2) With the transition to Azure Pipelines, there is not (yet) an easy way to suppress CI for doc-only PRs.


Dave Enyeart

"Gari Singh" ---11/26/2019 09:52:57 AM---I too believe that the documentation belongs with the code. I also do not believe that every person

From: "Gari Singh" <garis@...>
To: "Yacov Manevich" <YACOVM@...>
Cc: "Matthew Sykes" <matthew.sykes@...>, fabric@...
Date: 11/26/2019 09:52 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by: fabric@...





I too believe that the documentation belongs with the code.
I also do not believe that every person who contributes should become a maintainer ... especially when they do not have a history of actually doing reviews.
Likely some of the current maintainers should be retired as well given they do not do a lot of reviews.

But I think people are actually missing the point that Matt is making.  From the conversations I have seen, people believe that we do not merge changes to documentation fast enough.  So the solution is to move them out to another repository and likely change the approval requirements to NACR (single approver).  So we are making this change to avoid dealing with the fundamental issue:  the heavyweight process we have for approving changes to the fabric repo.

There are alternative solutions:

Now let's say that we believe there are certain domains in the fabric codebase which we believe require review from a subset of "experts" on that code.  This is easily handled by using CODEOWNERS and assigning a subset of maintainers to specific pieces of the code.  We can NACR in general but will not be able to merge changes to certain parts of the code without a review from some on the CODEOWNERS list.




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

-----fabric@... wrote: -----
To: "Matthew Sykes" <matthew.sykes@...>
From: "Yacov"
Sent by: fabric@...
Date: 11/26/2019 09:41AM
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations

The SDK documentation and CA is only documentation about APIs, it's not documentation about concepts, ideas, and tutorials.

I don't think that extracting the fabric documentation files out of the fabric repository would harm contribution - why would it ?

You can just link to the document repository from the readme.md of the Fabric repository and everyone would find it just as they find the files inside the docs repository.

> The repositories were not separated because they had different maintainer pools
In the past, the fabric-CA and fabric-node-SDK repositories inherited the maintainers of the fabric core, and that was a bad thing, because the only people that could merge code were those in the intersection of understanding the code in the corresponding repositories, and that were also fabric core maintainers.
As time went by, they were given their own maintainers and then progress was quicker.




From:        "Matthew Sykes" <matthew.sykes@...>
To:        fabric@...
Date:        11/26/2019 04:29 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by:        fabric@...



For the record, I am not in favor of extracting the documentation. I strongly feel that the doc and the code should live together where feasible. My perspective is that lowering the barriers to contribute is far better than segmenting the ecosystem into a number of fiefdoms.

If we want doc changes to only require a single doc review, we should state that's the desired process and put a technology plan in place to make that happen.

With that, a few comments to Dave's note:

> As Fabric has grown the sets of maintainers has naturally diverged across the fabric-* repos. The core Fabric maintainers are naturally different from the Fabric CA maintainers, the Java SDK maintainers, the Node.js SDK maintainers, etc.

The repositories were not separated because they had different maintainer pools; they were separated because, in most cases, they use fundamentally different implementation and CI processes. I'll also note that each of these contain their own documentation tree. (There's a docs folder in CA and API documentation is part of the code in node and Java.) Are you proposing we split all of these out as well?

> It has been challenging to get a majority of core Fabric maintainers to weigh in on decisions, since only about half of the maintainers are active day-to-day. This becomes more of an issue with the recent introduction of the fabric-rfcs process, which requires a majority of Fabric maintainers to agree before taking on new enhancements.

This is a problem of our own making. We have far too much process in place to make rapid forward movement. It's our choice to require a "majority" of maintainers and "2 mandatory reviews" to integrate things.


On Tue, Nov 26, 2019 at 7:11 AM David Enyeart <enyeart@...> wrote:
The intent of my proposal was exactly as Yacov says - doc maintainers would be comprised of the core Fabric maintainers in addition to heavy doc contributors/reviewers.

I do understand Brian's point, and we have been hesitant to split fabric code and fabric docs repos/maintainers up until now for the reasons Brian mentions. However in my opinion the time has come to split them for the following reasons:

As Fabric has grown the sets of maintainers has naturally diverged across the fabric-* repos. The core Fabric maintainers are naturally different from the Fabric CA maintainers, the Java SDK maintainers, the Node.js SDK maintainers, etc. We've had good results with different maintainers for each of these repos.

It has been challenging to get a majority of core Fabric maintainers to weigh in on decisions, since only about half of the maintainers are active day-to-day. This becomes more of an issue with the recent introduction of the fabric-rfcs process, which requires a majority of Fabric maintainers to agree before taking on new enhancements.

With the transition to Azure Pipelines, there is not (yet) an easy way to suppress CI for doc-only PRs.

With the transition to GitHub, we would like different branch protection rules for Fabric code and Fabric docs.


Dave Enyeart

"Yacov" ---11/26/2019 01:49:37 AM---I think the best solution for these 2 seemingly conflicting ideas is: All maintainers of code reposi

From: "Yacov" <yacovm@...>
To: "Brian Behlendorf" <bbehlendorf@...>
Cc: fabric@...
Date: 11/26/2019 01:49 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by: fabric@...



I think the best solution for these 2 seemingly conflicting ideas is:All maintainers of code repositories
should be ableto merge documentation contributionsMaintainers of the documentation
should not be able to merge code contributions.


From: "Brian Behlendorf" <bbehlendorf@...>
To: fabric@...
Date: 11/26/2019 07:36 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by: fabric@...



On 11/25/19 6:09 PM, David Enyeart wrote:
I'd suggest that we identify the top documentation contributors and reviewers to seed the fabric docs repository maintainer list in the coming weeks (including Chris and Joe), rather than pulling the trigger in the Fabric repository this week.Are there separate maintainer pools for different fabric-* repos?
If so, I can understand the argument, coming from a world where the precautionary principle would apply, and where prior version control systems (and even earlier versions of git) allowed for a dangerous degree of repository damage if someone made the wrong set of changes. I also of course get the point for different maintainers for different Hyperledger projects, e.g. Fabric vs Sawtooth.
But for the same project, which is arguably the same "community" of contributors and representatives of end-users, you may want to consider a single pool of maintainers across all fabric-* repos. The easy case is to argue for the ability for anyone who's a maintainer on the main code repos to also be able to merge in changes into docs-related repos. The harder case is for people who come in as solid contributors to docs, but aren't (yet!) code contributors. There, I'd still argue for it - the boundary between docs and code is rarely so hard, as changes to error messages/logging or admin/user interfaces often are driven by a docs-level view of what would be easier to explain. And, I've seen great core developers on projects come in first through a docs-related role. Also, just for simplicity: I'll counter your precautionary principle with an Occam's Razor, which makes understanding the project easier for newcomers. I bet reversing any mistaken merges is a lower cost than the value of contributions you might not otherwise see.
Up to you all,
Brian
--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf








--
Matthew Sykes
matthew.sykes@...














4261 - 4280 of 11527