udaykiran19491/user-stories-from-tawos-for-llm-fine-tuning huggingface dataset:
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "I often see chaincode for transfer of ownership like here [https://github.com/hyperledger/fabric-samples/blob/b99e1b8da2bc4d17f689c152078d96e8f6428a27/chaincode/fabcar/fabcar.go#L178-L194]  However, those samples do not indicate, how to control on-chain, that only the current owner can call this.    As a chaincode developer I want to see an example, how to do on chain access-control, possibly depending on the current world state or history."
Answer: 1144816.0

User story: "If you are not a ChannelWriter you will not be able to invoke chaincode (propose) on an endorser, and therefore identities that are ChannelReaders but not ChannelWriters have no mechanism to call read-only chaincode functions.  Based on the role name, I would expect ChannelReaders should be able to call chaincode read-only functions.    Currently in 1.1 this can be achieved by overriding the Propose ACL to be something different than ChannelWriters.  This work item proposes that ChannelReaders should be able to call chaincode functions that read from ledger using the default configuration.    Option 1: Re-introduce a chaincode Query() function (it was there in 0.6 but not 1.0, removed in --FAB-1055--), which would only require you to be a ChannelReader to call chaincode read-only functions (functions that attempt to write in the context of a Query would immediately return an error). The Query() would also be more streamlined than Invoke() as the peer simulator would not need to generate a RWSet and the ProposalResponse would not include a RWSet.    Option 2: Set the Propose ACL to be ChannelReaders instead of ChannelWriters. If the chaincode simulation has writes, then we could additionally ensure that client is a ChannelWriter."
Answer: 1137491.0

User story: This go chaincode does not, what you would expect  {code:java}  APIstub.PutState("key", []byte("initial Value"))   val, _ := APIstub.GetState("key")   fmt.Println("value from ledger", string(val)){code}  The putState is not applied immediately, but only after the transaction!    !image-2017-11-18-15-06-13-189.png!    Suggested Improvement:   Stub should provide an intermediate layer to keep track of state modifications *within a transaction*. Such that  {code:java}  x = getState(key);  x++   putState(key, x)  y=getState(key){code}  results in y = x+1 not x!
Answer: 1145290.0

User story: "In times, we would want to update the TLS certificate of a server node such as a peer or an orderer.         Reasons could vary starting from the certificate is nearing expiration, or changing root TLS ca to adding a new SAN to the certificate because of some routing rule.    Currently there is no way to do that without a shutdown of the node, and that's too bad.    We should provide a way to update the TLS certificate on the fly.         [~<USER>"
Answer: 8032.0

User story: I was encouraged by the hyperledger-fabric mailing list to make a CR to update the docs with a "Build on Centos" section.
Answer: 192567.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: Given I am a fabric client    And I am a member of channel "A"    When a transaction is broadcasted in channel "A"    Then I wish to be notified of the transaction in channel "A"         When I request blocks from a fabric component    Then I should be able to use a common interface              Acknowledgement:        originator: [~<USER>
Answer: 1146642.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: In the endorser, whenever an error is returned from the simulation, the peer returns:  {code:java}          if res.Status >= shim.ERROR {              endorserLogger.Errorf("simulateProposal() resulted in chaincode response status %d for txid: %s", res.Status, txid)              var cceventBytes []byte              if ccevent != nil {                  cceventBytes, err = putils.GetBytesChaincodeEvent(ccevent)                  if err != nil {                      return nil, errors.Wrap(err, "failed to marshal event bytes")                  }              }              pResp, err := putils.CreateProposalResponseFailure(prop.Header, prop.Payload, res, simulationResult, cceventBytes, hdrExt.ChaincodeId, hdrExt.PayloadVisibility)              if err != nil {                  return &pb.ProposalResponse{Response: &pb.Response{Status: 500, Message: err.Error()}}, err              }                return pResp, &chaincodeError{res.Status, res.Message}          }{code}       However, in the client side in go, nil is always returned in the response:  {code:java}  func (c *endorserClient) ProcessProposal(ctx context.Context, in *SignedProposal, opts ...grpc.CallOption) (*ProposalResponse, error) {      out := new(ProposalResponse)      err := grpc.Invoke(ctx, "/protos.Endorser/ProcessProposal", in, out, c.cc, opts...)      if err != nil {          return nil, err      }      return out, nil  }{code}       I assume that in [java SDK|https://github.com/hyperledger/fabric-sdk-java/blob/13337b64716141995e49f3f0b81e6356fc05a06a/src/main/java/org/hyperledger/fabric/sdk/EndorserClient.java#L89-L102] it's similar and an [exception|https://grpc.io/grpc-java/javadoc/io/grpc/StatusRuntimeException.html] is simply thrown, and although exceptions are serializable, it can't be that you can send an exception down the wire because gRPC is platform independent in java it's impossible to classify the exception according to its cause (chaincode or gRPC failure)    *My first question is - how does a client SDK handle the reasons of the proposal failure?*   * The way to recover from a communication error is inherently different than other failures such as access control error, or invalid parameter failures.   * Unless I'm wrong - there is no good way for the SDK to distinguish between communication errors to other erros, due to the fact that the cause of the errror / exception is returned as a string and cannot be classified using type inference or some switch on a number, etc.         *My second question is - given the above fact is true - should we fix this? and if so, how?* I guess we can always return the response with nil as the error but that might (?) break compatibility with existing client code (is this true?)              [~<USER>    [~<USER>    [~<USER>    [~<USER>    [~<USER>    [~<EMAIL>]     
Answer: 1147627.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: The following error message is received when there is a certificate that has been tagged as a CA certificate. While one should be able to use "A CA certificate cannot be used directly by this MSP", the error is clearer if it were to say "A CA-tagged certificate cannot be used directly by this MSP"    It would also help to know exactly what certificate the complaint is about, since there are potentially multiple certificates on the system.     {code}  2017-11-16 16:42:57.709 UTC [orderer/multichain] newLedgerResources -> CRIT 078 Error creating configtx manager and handlers: Setting up the MSP manager failed, err admin 0 is invalid, validation error Could not obtain certification chain, err A CA certificate cannot be used directly by this MSP  panic: Error creating configtx manager and handlers: Setting up the MSP manager failed, err admin 0 is invalid, validation error Could not obtain certification chain, err A CA certificate cannot be used directly by this MSP  {code}
Answer: 19635.0

User story: "update existing GoAST scan job to skip vendor, build, gotools and bddtests directories from the list of the go packages. Also, the output should display in HTML format on the jenkins console."
Answer: 110593.0

User story: "In the existing CI jobs, unit-test jobs triggers when a user submits a change to .rst or .md files also. This is not required as the changes are not effecting unit-tests."
Answer: 246735.0

User story: "Cryptogen requires a few modifications to allow the following:  - generation of certificates with customised OUs  - generation of MSP configuration file (config.yaml)    The aim of this JIRA item is to add the above features to cryptogen."
Answer: 123141.0

User story: "BYFN does not include any Fabric CAs, unless you use the docker-compose-e2e.yaml file.    However that file does not have the CLI container so does not work with byfn.sh.    Add similar options to byfn.sh as per CouchDB to additionally start Fabric CAs."
Answer: 358082.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "[build] - add `fabric-ca` make target in fabric-ca makefile. This is useful to just build fabric-ca docker image to use in fabric-sdk-node and fabric-chaincode-node repositories. These repositories are not using other fabric-ca docker images like (tools, orderer, peer and fvt).     though the above images are not required we build fabric-ca images using `make docker` command and this builds all the docker images instead only fabric-ca docker image.    Add a target to build *fabric-ca docker image* in fabric-ca makefile     "
Answer: 990.0

User story: "[BUILD] - build specific images which are mentioned in the docker-compose file or required in the tests. This actually saves lot of time in the build process. ex; fabric-sdk-node we only use     ca, fabric-orderer, fabric-peer and couchdb and CI script has to build only these images not the `make docker` and build all the unnecessary images."
Answer: 1681.0

User story: "[Build] - cache all the default software versions in nexus repository and later update the dockerfile's to download these images from nexus. Will share the list of the cached versions.    Will push these cached versions and pull these from the nexus repository. This should result  great improvement in build time in jenkins."
Answer: 1144834.0

User story: "Logs for successful fabric-verify-x86_64 jobs are between 60 and 120 kilobytes. Logs for successful fabric-verify-s390x jobs are between 18 and 24 megabytes. This means the log retention for -s390x is much shorter than it should be. Please reduce the size of these logs."
Answer: 960293.0

User story: "In some cases, clients will be deployed without TLS certificates and will connect to the peer when the peer uses TLS.    In this kind of scenario, the peer would send a certificate request to the client, and it will not send anything back - and then the discovery service would reject the peer's connection.    In order to ensure the clients will be able to use the discovery service in spite of lack of TLS certificate, we can just have them auto-generate one and self-sign it.   Then, the peer would obtain the certificate (but not verify it!) and a mutual TLS handshake will take place, which would allow the client to authenticate to the peer.    Note - for Service Discovery, this is required even when peer is not setup for mutual TLS, that is, even when the peer has clientAuthRequired=false."
Answer: 330035.0

User story: "There have been some recent changes in the fabric-test repository. The README.md file is now updated accordingly to avoid confusion.These changes must be done together with the Makefile changes with FAB-6907"
Answer: 45873.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The deliver service, which currently resides solely on the orderer, should be made available on the peer as well. This service can be used for events on a channel level. It will allow for access control as well as requesting information about previously committed blocks (or ones that may have been missed during a network outage/disconnection), two things currently not possible with the eventhub (and ACL of which has been accounted for by the WIP FAB-5695 that this JIRA will hopefully replace).     This will involve   * moving the fabric/orderer/common/deliver package to fabric/common/deliver and reworking it to be compatible with both the peer and orderer   * exposing the deliver service on the peer    This is doubly useful, in preparation for the addition of BFT ordering, and generally decreasing the trust the client places in the ordering service.  When connecting directly to the orderer to receive blocks, unless the client reimplements the peer functions of checking the hash chain, looking up the block validation policy, and checking the block validation policy against the orderer signatures, then the client is relying on the honesty of the OSN it connects to to return good blocks.  By adding the {{Deliver}} API to the peer, clients may use existing code invoked against the orderer, but exploit the trusted relationship between a client and its org's peers.         Acknowledgement:        originator: [~<USER>"
Answer: 93759.0

User story: "As the make clean is not working, a change must be made to the Makefile in the fabric-test to change the target from clean-all to clean. This would enable the 'make clean' to work.   * rename clean-all to clean   * -remove steps to clone other repositories; instead, update targets to build images and binaries inside submodules fabric-test/fabric/ and fabric-test/fabric-ca/- (This part is being done with another JIRA task FAB-6922)    For the Readme changes, see: [https://gerrit.hyperledger.org/r/#/c/15265/], for the steps being modified to use this fabric-test/Makefile.    For the Makefile changes, see:  "
Answer: 9138.0

User story: "Although we have an implied list of supported OS/platforms it is not documented anywhere. There actually are two lists we should have: the list of target OSes (i.e., images we support) and the list of OSes on which development is supported.    We currently produce images for: Win64, MacOS, Linux x86_64, Linux ppc64le, and Linux s390x    We currently support development on MacOS, and Linux, plus Vagrant over Windows (and Mac?) to a degree.    It would make sense to agree on the actual lists and document them."
Answer: 1162377.0

User story: "There are test-suites in our organization which uses Peer CLI for verification and with the Endorsement Policy to be set with mulitple organizations, the option to Peer CLI to provide multiple endorsers would be very useful."
Answer: 368700.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The endorser code currently uses many static methods which make testing the endorser very difficult. This change set introduces a Support interface for the endorser so that dependencies can be injected (and mocked in testing)."
Answer: 1162908.0

User story: "The grpclog package has a new logger which appears to handle verbosity levels.  Currently, the common/flogging package implements a custom grpc logger based on the older implementation.  It's worth exploring if there are any benefits to moving to the new grpclog#LoggerV2"
Answer: 402920.0

User story: "Private channel data requires a new capability to make sure that this new feature is introduced without creating forks."
Answer: 72351.0

User story: "Right now in Fabric samples project , there is a first-network application which gives the network setup , but it has fixed no of peers,  I thought there should be a sample application which will help the developers to concentrate on working with hyperledger fabric framework without worrying about setting up the whole network. It will ask you about the number of organisations , no of peers in each organisations ,domain name and channel name and setup the whole network accordingly."
Answer: 1169795.0

User story: "In the context of FAB-5131, we need a way to allow the chaincode to access some private information of the peer running that chaincode.     This FAB proposes to allow the chaincode to access a specific section of the peer's local configuration (core.yaml) to retrieve global values sharable by all chaincodes running on that peer, and values that should be available only to a specific chaincode.    In order to achieve this goal, the *ChaincodeStubInterface* interface will enhanced by adding methods to retrieve the local configuration. As per [Supporting private data in Hyperledger|http://docs.google.com/document/d/16SYkK_wxReCeAEXbgobP6B8vW-VTGNQ_qRmJemS_jTI/edit?usp=sharing]    {code:java}      // GetLocalConf returns the byte array value specified by      // the `key` from the peer local configuration for the chaincode      GetLocalConf(key string) ([]byte, error)  {code}    The invocation of that method will trigger a call to the peer to retrieve the value corresponding to the requested key.    These values will be stored under the *chaincode* section of core.yaml. Here is an example:    {code:java}  chaincode:      localConf:          K1: V1          K2: V2          ...  {code}    [~<USER>,[~<USER>,[~<USER>,[~<USER>,[~<USER>,[~<USER>,[~<USER>,[~<USER>,[~<USER> please have your say :)"
Answer: 1171424.0

User story: "As a Fabric network manager, I want to know the performance of my Fabric queries if CouchDB is chosen as the state database."
Answer: 369408.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "```  // ChannelRestrictionsValue returns the config definition for the orderer channel restrictions.  // It is a value for the /Channel/Orderer group.  func KafkaBrokersValue(brokers []string) *StandardConfigValue {   return &StandardConfigValue{    key: KafkaBrokersKey,    value: &ab.KafkaBrokers{     Brokers: brokers,    },   }``  }"
Answer: 7381.0

User story: "Fabric-samples/fabric-ca has some errors,the readme file has some error in description."
Answer: 1173115.0

User story: We've come across an interesting problem. Someone created a RTD site for the now defunct [https://github.com/openblockchain/peer|https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openblockchain_peer&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p5YcGuYCbPwJa_8uLf1O6Cpr19ou4eNaHS8SxvpKMIM&m=WTVd_EzLfVBKdOAzAQUDIRTBkBK5oe5hoCYQilvnm_k&s=GqdS2GuBEXrtiqcQBUKaDa-FNsrGcgiskhKJ_nIoZ74&e=] project (which is no longer a thing) but that org now redirects to [github.com/hyperledger-archives/fabric|https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_hyperledger-2Darchives_fabric&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p5YcGuYCbPwJa_8uLf1O6Cpr19ou4eNaHS8SxvpKMIM&m=WTVd_EzLfVBKdOAzAQUDIRTBkBK5oe5hoCYQilvnm_k&s=mphonm8VXNZHYMR72QtLyVOaevtYresfVpKLcE9NRKI&e=] and so the RTD build picks up the old archive of fabric and publishes what looks like the Fabric docs (sigh) complete will all kinds of bad, misleading and dated information.     While we can try to remove the redirect, the fact is that the RTD site will still stand and confuse people [https://openblockchain.readthedocs.io/en/latest/|https://urldefense.proofpoint.com/v2/url?u=https-3A__openblockchain.readthedocs.io_en_latest_&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p5YcGuYCbPwJa_8uLf1O6Cpr19ou4eNaHS8SxvpKMIM&m=WTVd_EzLfVBKdOAzAQUDIRTBkBK5oe5hoCYQilvnm_k&s=4U8byumSRRcExl4b3Pq8NCIhbkMoThjSHCinl087y9k&e=]     What I would like to do is make a pull request against the hyperledger-archives/fabric repo to update the "home page" of the docs [https://github.com/hyperledger-archives/fabric/blob/master/docs/index.md|https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_hyperledger-2Darchives_fabric_blob_master_docs_index.md&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p5YcGuYCbPwJa_8uLf1O6Cpr19ou4eNaHS8SxvpKMIM&m=WTVd_EzLfVBKdOAzAQUDIRTBkBK5oe5hoCYQilvnm_k&s=7ylmdcqmE3LiwYJZCM6g7rBwBJHKHfmGL7cfxdFjx6w&e=] to say that these docs are DEFUNCT, built from an (OLD) archive of the Hyperledger Fabric repository and to redirect to the current stable release [http://hyperledger-fabric.readthedocs.io/en/stable/index.html|https://urldefense.proofpoint.com/v2/url?u=http-3A__hyperledger-2Dfabric.readthedocs.io_en_stable_index.html&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p5YcGuYCbPwJa_8uLf1O6Cpr19ou4eNaHS8SxvpKMIM&m=WTVd_EzLfVBKdOAzAQUDIRTBkBK5oe5hoCYQilvnm_k&s=DrYZ5ll2gFWZU0KgnflDY_nKfOBqvbBcgd1cc7HMPZY&e=]
Answer: 220265.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Updated the README to describe adding a signed-off-by hook automatically to all commits to the repository. This hook removes the risk of missing the -s flag in a git commit command thus needing to amend commits."
Answer: 922074.0

User story: "events/consumer/consumer.go，repeated code,should be removed.    Line 82 to Line90"
Answer: 24.0

User story: "The method is needed in the interface for anyone who need this information until Service Discovery (https://jira.hyperledger.org/browse/FAB-5451) is merged."
Answer: 419.0

User story: "Add instructions to fabric-test readme which install and configure git review. This is so they are  in one place for new users.    https://github.com/hyperledger/fabric-test"
Answer: 222.0

User story: "There are various UTs that excercise different aspects of TLS on chaincode but that actually does peer-chaincode communication over TLS. These new UTs would be in chaincode_support_test.go using the mock infrastructure used there.  "
Answer: 1179613.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: Bootstrapping a HF network involves a considerable effort and the task is prone to error, people asking for collaboration regarding this task are frequently seen in the HF chat.    While the e2e sample is a great starting point, it relies on a fixed network configuration i.e. fixed amount of organizations, peers, etc. Changing the configuration might be hard to accomplish for a developer who is not yet familiar with HF.    On the other hand, we already count with a tool that simplifies the creation of required credentials just by providing a simple configuration file. But it does not provide support for the configuration of docker files.    We’ve implemented this utility to simplify our daily work in a research project where we test the changes introduced to the Fabric against different HF networks (different organizations and peers, ordering service implementations and db providers). As we found this tool really useful we would like to share with the open community.    This utility is useful when getting started with HF and for bootstrapping development/testing HF networks based on customized HF images. A simple configuration file looks like the following one:       DOCKER_NS: hyperledger       ARCH: x86_64       VERSION: 1.0.2        network:                "samplenet"       domain:                 "samplenet.com"        ordererType:            "solo"        db:           provider:   "goleveldb"        ordererNodes:           1       peerOrganizations:      1       peersPerOrganization:   2       usersPerOrganization:   1        logLevel:               "debug"       tlsEnabled:             true       chaincodesPath:    "./sample-chaincodes"         *Build configuration files (credentials also generated)*:    netcomposer -config samplenet.yaml   *Start the network*:    docker-compose -f ./samplenet/docker-compose.yaml up -d    All containers are up and running, no need to deal with certificates nor docker configuration files. CLI peer is also ready to install, instantiate and invoke chaincodes.    Note: Required crypto material is generated by cryptogen tool.         Current source code: [https://github.com/ibm-silvergate/netcomposer]     
Answer: 1179891.0

User story: "Changes made to the protocols can have impact on the shims. As the node.js shim is built outside of the main fabric build, changes can occur which could break the shim and require changes.   This happened recently where a change was made to the GetState protocol but the shim wasn't updated and there was no indication that there was now a break in the shim.    As the shim publishes an unstable version to NPM which reflects changes to it, there is also the scenario where if a .proto file required by the shim is changed, a new unstable NPM module would need to be published as the build. The proto files are not part of the shim code base but rather pull them from the fabric code base.  Maybe the fabric-chaincode-node build could be kicked off whenever a change to the .proto files are detected ?"
Answer: 925452.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Unless I am missing something, Gossip layer right now just expose interfaces only send one message in one send round. Shall we consider introduce features sending multiple messages in one send round?    In my mind, define a new type of gossip message 'messageSet'  which contains a slice of messages, may not need interface change. [~<USER> [~<USER>"
Answer: 548.0

User story: "The GRPCServer.SetClientRootCAs() function currently eliminates duplicate root certificates by using a map with a key based on the RawSubject.   While it should not be the case that we should end up with duplicate subjects nor should it be the case that the root certificate for an org should differ across channels, it is possible for this to happen.  So we need a better way to uniquely key root certificates.      SubjectKeyIdentifier should be unique across root certificates.  It's not a mandatory field so we'll need to maintain two maps but if SKI exists we won't add it to the RawSubject map."
Answer: 944486.0

User story: "Hyperledger Fabric allows inter-changeable components such as transaction endorsement and validation checks by extracting out this functionality into system chaincodes. Users can provide custom system chaincodes to implement application specific behaviour.    Due to limitations in the Go language at the time of implementation, system chaincodes were statically compiled into the peer. Users must change fabric source code and recompile the peer to include custom system chaincode. This design can be improved by using Go plugins available since 1.8.    We propose to allow loading system chaincodes as plugins. Once loaded, they will behave like regular system chaincodes compiled into the peer."
Answer: 169977.0

User story: "The fabric peer and orderer runtimes actually support mutual TLS via the use of the common grpcServer component, however there is currently now way to configure either of them to require/enforce mutual TLS.    While not strictly required for Fabric networks, mutual TLS adds an extra layer of protection for publicly exposed endpoints"
Answer: 290713.0

User story: "After cloning     https://github.com/hyperledger/fabric-test    When running github.com/fabric-test/feature/scripts/install_behave.sh    govendor is required but not installed. The script installs  apt packages and python modules  so im not sure where to add this command.     go get -u github.com/kardianos/govendor      "
Answer: 15412.0

User story: Fabric CLI allows using combination of ANDs and ORs only to specify endorsement policy. This limitation requires specifying verbose endorsement policies for simple things like "And 3 out of 4 organization's members should sign". This affects the performance, as well as usability.
Answer: 1188189.0

User story: "We see the same questions coming up in #fabric-orderer time and time again. Let us document these in a FAQ document that we'll be pointing folks to, next time one of these questions come up."
Answer: 175962.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: LSCC upgrade is subjected to custom validation performed by ValidateLSCCInvocation. In particular the following is the piece of code executed during validation of the LSCC upgrade.       {code:java}  case lscc.UPGRADE:     /**************************************************************/     /* security check 1 - cc in the LCCC table of instantiated cc */     /**************************************************************/     if !ccExistsOnLedger {        return fmt.Errorf("Upgrading non-existent chaincode %s", cdsArgs.ChaincodeSpec.ChaincodeId.Name)     }       /*****************************************************/     /* security check 2 - check the instantiation policy */     /*****************************************************/     pol := cdLedger.InstantiationPolicy     if pol == nil {        return fmt.Errorf("No installation policy was specified")     }     // FIXME: could we actually pull the cds package from the     // file system to verify whether the policy that is specified     // here is the same as the one on disk?     // PROS: we prevent attacks where the policy is replaced     // CONS: this would be a point of non-determinism     err = vscc.checkInstantiationPolicy(chid, env, pol, payl)     if err != nil {        return err     }       /**********************************************************/     /* security check 3 - existing cc's version was different */     /**********************************************************/     if cdLedger.Version == cdsArgs.ChaincodeSpec.ChaincodeId.Version {        return fmt.Errorf("Existing version of the cc on the ledger (%s) should be different from the upgraded one", cdsArgs.ChaincodeSpec.ChaincodeId.Version)     }  }    {code}  In particular, what is checked is if the chaincode requested to be upgraded has already been instantiated in the channel based on the current ledger state, and that the instantiation policy of the chaincode to be upgraded is satisfied by this transaction's creator. Additional checks exist to ensure that the write set included in the LSCC upgrade transaction are consistent with the ledger state and the proposal header and payload.    The checks here need to be enhanced upon proper capabilities flag for 1.1 is switched on so as to ensure that:    - name of the chaincode does not change during the upgrade    - instantiation policy of the chaincode does not change or — if this is not the case — that the instantiation policy of the upgraded chaincode is satisfied by its invokers.    - write set caused by init invocation (i.e., having the namespace of the instantiated chaincode) would need to satisfy the endorsement policy of the instantiated chaincode (ADDRESSED BY LIFECYCLE ENHANCEMENTS INTENDED FOR 1.2).    The latter is to take place for deploy and upgrade.
Answer: 212937.0

User story: "The CouchDB benchmarks currently use binary values only.  This change will provide the option for benchmarking CouchDB with JSON values."
Answer: 939723.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The default MSP implementation can be found in mspimpl.go. The file is gigantic and it is getting complex to modify it. In order to simply the picture, mspimpl.go will be split in multiple files:  - mspimplsetup.go to handle the setup related functions  - mspimplvalidate.go to handle the validation related functions"
Answer: 2890.0

User story: "The MSP version to be instantiated needs to follow the application capabilities flag."
Answer: 20990.0

User story: "Microservices architecture is a better software development style that enables flexibility in deployment and management of the applications. Basically this style decomposes the software into a suite of independently deployable (micro) services.    We want to apply this style to chaincode development.    The current chaincode runtime model loads a chaincode per container to ensure complete isolation of chaincode address space. This certainly provides security protection between chaincodes such that one chaincode can't negatively interfere with or bring down the others. However, this model comes with a cost of system resource to accommodate containers, which encourages monolithic chaincodes.     We want to improve the chaincode model such that we would have an option to load chaincode into an existing container, especially with VM-based chaincodes like Java or Nodejs. It would encourage decomposing chaincode into microservices, where each may be independently deployed and managed. We also need the chaincode life-cycle to be feather light such that microservices chaincodes can easily come and go as use-cases require short-live chaincodes.    I'd like to open up for discussion and comment on this thought, especially the following folks who have intimate knowledge in this area: [~<USER> [~<USER> [~<USER> [~<USER> [~<USER> [~<USER>     "
Answer: 1192689.0

User story: "As reported by @<USER>at https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=utGqv7wbkrC2gd3ax:    Endorsement against the same chaincode from the same peer is parallel.    However, the endorsement and commitment may block each other by acquiring the same read lock.    NewLockBasedTxSimulator acquires a read lock: txmgr.commitRWLock.RLock()    Commit tries to acquire a write lock on the same object: txmgr.commitRWLock.Lock()."
Answer: 1193166.0

User story: "update version reference to 1.0.3 in release test suite.  In some of the scripts in test/regression/release folder are still referring 1.0.1 version."
Answer: 163878.0

User story: "The ldflags are currently hard-coded for static CC build. This prevents user chaincodes to use extensions (e.g. PKCS11) which requires dynamic linking. Static linking will still be the default.    NOTE: Using the dynamic build flag requires a custom image. Currently, hyperledger/fabric-baseos image does not include the C libraries required by the peer and orderer for dynamic linking"
Answer: 19778.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: The following sample was created by [~<USER> and [~<USER>    [https://www.ibm.com/developerworks/cloud/library/cl-deploy-sample-application-ibm-blockchain-platform/index.html]     This sample shows how to use the fabcar sample with TLS         We should incorporate the changes in this sample into the fabric project, as they are of general use to users. Specifically, we need   # Documentation Updates   # New Commands   # New "fabcar with TLS" sample, including documentation on how to do this.         Details for these 3 areas.    The Documentation updates are    * Create a new section in the docs for "Writing Applications".  This can use some of the general material in the fabcar sample ([http://fabricstaging.readthedocs.io/en/latest/write_first_app.html)]   * Create a new subsection on "Using TLS with your applications"         The new command should   * Enroll a user to a Fabric CA, modelled on the enrollUser.js command in the external sample.         The new sample should   * incorporate all the the sample fabcar updates into a new sample called fabcar_tls   * The underlying network for this sample should be TLS enabled.   * There should be a new section in the Sample Applications section on how to use this new "fabcar_tls" sample.     
Answer: 1197292.0

User story: "add define system channel name field in the fabric orderer config file"
Answer: 1198881.0

User story: "Currently, the validator behaves very poorly when it comes to unmarshalling: the same field is unmarshalled multiple times in the same code path leading to code that is inefficient and hard to maintain.     This JIRA tracks the work required to unmarshal once all the struct out of a block and then pass around to all validating functions a reference to a struct with appropriate getters."
Answer: 1198914.0

User story: "In its current shape, the validator code has very long functions, makes many calls to static functions, may do a lot of useless marshalling and is generally hard to test.    This epic tracks the work necessary to have a modular and testable validator."
Answer: 947995.0

User story: "It would be nice for the components of Fabric to include the release version in configuration files, as well as a change log for configuration files.    These additions would make management of config files much easier, as well as give administrators insight into what files need updating after each release."
Answer: 1199930.0

User story: "Currently, the local block files number is limited to 1 M.    000,000~999,999    After discussion with Jonathan, we need to extend to support more than 1 M block files, while keep compatible with old versions.    000,000~999,999    10,000,000~...     "
Answer: 7919.0

User story: "in the orderer config,it use the broadcastDir and deliverDir to log the serivce trace,but it set to empty string default,"
Answer: 1200699.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: Fabric promises to enforce txid uniqueness, but the control put in place to honor that is broken:       {noformat}   for tIdx, d := range block.Data.Data {    if d != nil {     if env, err := utils.GetEnvelopeFromBlock(d); err != nil {      logger.Warningf("Error getting tx from block(%s)", err)      txsfltr.SetFlag(tIdx, peer.TxValidationCode_INVALID_OTHER_REASON)     } else if env != nil {                                     ....       // Check duplicate transactions       txID := chdr.TxId       if _, err := v.support.Ledger().GetTransactionByID(txID); err == nil {        logger.Error("Duplicate transaction found, ", txID, ", skipping")        txsfltr.SetFlag(tIdx, peer.TxValidationCode_DUPLICATE_TXID)        continue       }                                     ....  {noformat}         The validator code only checks for duplicate txids with respect to those already committed in the ledger and not those that are in the same block, so a block may contain >1 tx with the same id, and they would all be accepted as valid.         The validator code should be changed to also take into consideration txid duplicates within the tx.
Answer: 72287.0

User story: "when the orderer starts,it need the genesis block for the configuration,it defines the config information about the fabric,so i think it's a good advice to provide more convenience way to see the config.i think that using the web to reconfig channel config is a good method."
Answer: 1203226.0

User story: "The networkDown funtion in network_setup.sh does not shutdown CouchDB docker compose file.    function networkDown () \{   docker-compose -f $COMPOSE_FILE down    #When network_setup.sh up with CouchDB option, we need to run the following line.    {color:#ff0000}#docker-compose -f $COMPOSE_FILE_COUCH down{color}    #Cleanup the chaincode containers   clearContainers    #Cleanup images   removeUnwantedImages     # remove orderer block and other channel configuration transactions and certs    rm -rf channel-artifacts/*.block channel-artifacts/*.tx crypto-config   }"
Answer: 305484.0

User story: "The deliver service has a backoff and retry policy that makes the deliver service reconnect to the orderer upon a connection failure, until a threshold has been reached.    The total time of reconnections is currently hardcoded by [reConnectTotalTimeThreshold|https://github.com/hyperledger/fabric/blob/release/core/deliverservice/deliveryclient.go#L32] and is set to 5 minutes which is too low for some use cases where the ordering service in unavailable for a long duration of time.    We perhaps need to make it configurable in core.yaml "
Answer: 24692.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The {{sampleconfig/core.yaml}} file defaults to disabling leader election and instead setting the peer to be a leader.    This is the wrong default, because enabling leader election fixes a number of potential errors, including peers permanently disconnecting from the ordering service during network partitions, and joining a channel with a genesis block which does not contain the peer's org definition."
Answer: 38540.0

User story: "After UT and doc is written, we can assign this to someone to determine what (if any) system tests should be done."
Answer: 403760.0

User story: There should be a way for user to easily get customized BCCSP instance without explicit effort, however, below are examples BCCSP got initialized with "nil" option    common/tools/configtxgen/main.go  common/tools/cryptogen/csp/csp.go  common/tools/cryptogen/msp/generator.go  core/chaincode/shim/chaincode.go  core/common/ccprovider/cdspackage.go   core/common/ccprovider/sigcdspackage.go    This work item will add implementations to extract user options and add no impact to existing project
Answer: 412172.0

User story: "We need to improve Network Launcher to change the following parameters.   After the improvement, we will be able to launch Fabric network for various test cases.    - CouchDB: launch couchdb container for each peer  - batch time out: change batch time out  - batch size: change batch size in a block  - logging level: change logging level of peer  "
Answer: 27417.0

User story: "Refer to [https://wiki.hyperledger.org/projects/fabric/proposedv1_1] and the New Feature JIRA blocking this.     Ability to distinguish types of MSP identities, e.g. peer vs client vs orderer. This information can be utilized for access policies throughout the system."
Answer: 955318.0

User story: "Refer to [https://wiki.hyperledger.org/projects/fabric/proposedv1_1] and the New Feature JIRA blocking this. This is a tech preview feature. This may require using build flag or run-time flag.    Finer grained access control on channel functions rather than organization scoped access. For example, specify which identities or group of identities can invoke chaincode, retrieve blocks, retrieve transactions, etc."
Answer: 955323.0

User story: "Refer to [https://wiki.hyperledger.org/projects/fabric/proposedv1_1] and the New Feature JIRA blocking this. This is a tech preview feature. This may require using build flag or run-time flag.    Private channel data. Ability to keep data on a channel private. This data will never be sent to the ordering service with the transaction. The private data is shared with a subset of peers, governed by policies, via the gossip protocol. E.G. all channel participants may need to be aware of a trade, but keep the trade price private among the trade participants."
Answer: 958222.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Refer to https://wiki.hyperledger.org/projects/fabric/proposedv1_1 and the New Feature JIRA blocking this. This is for a tech preview feature.    Note: this capability (using build flags) is one way of controlling what goes into a load. Another is using run-time flags, to allow network admin to turn features on/off, typically after all nodes are upgraded. (If any nodes are not upgraded, then they would stop participating in the network.) Some tech-preview features might use that instead of (or in addition to) build flags. I am not sure if there is much system testing we can do exclusively for FAB-6020. It is probably just a matter of running feature tests for a specific feature(s) to ensure they fail when it is not built into the load when its build flag is off (and automated tests complete successfully for other features), and that the feature tests pass when it is included and fully functional when the build flag is enabled.    Not sure yet which features would be guarded by build flags, but it is likely some are the tech-preview features that are listed in the wiki (see link, above)."
Answer: 955330.0

User story: "Refer to [https://wiki.hyperledger.org/projects/fabric/proposedv1_1] and the New Feature JIRA blocking this.    If a user wishes to use an external CA for generating and signing the certificates, it would be useful to leverage the fabric-ca-client and BCCSP to generate a certificate signing request for the keys generated by the BCCSP and write the CSR to a file without any interaction with the fabric-ca-server. This would allow the user to then send the CSR file to an external CA."
Answer: 155202.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Refer to [https://wiki.hyperledger.org/projects/fabric/proposedv1_1] and the New Feature JIRA blocking this.    Ability to trigger events on a per channel basis rather than global peer basis. The (current) eventhub was designed to be an integration point for outside systems to receive data from a fabric peer, regardless of channel. The intent of the (new) channel service is to address this usage while also providing the ability to set access control. The eventhub refactor would be for the future (to combine the services to use single improved infrastructure).       ----  Interface tests utilize the sample deliver client to connect to a Peer Deliver API and receive block events on a channel level.    Peers are referred to by PO<org#><peer#>. eg. PO11    Network Topology:   * e2e_cli example with TLS disabled: 2 org, 2 peers per org joined to channel1   * modification: additional channel2 with PO11 joined, cc installed and instantiated    Execution:   # Deploy e2e_cli network, execute cli script and pause prior to invoking.   # Using sample deliver client [https://github.com/hyperledger/fabric/blob/master/orderer/sample_clients/deliver_stdout/client.go]   connect multiple sample deliver clients and retrieve all blocks and listen forever. Note that each of these clients should receive the genesis block for the channels they are connected to:   ## PO11 on channel1 (DC1-1-1)   ## PO11 on channel2 (DC1-1-2)   ## PO21 on channel1 (DC2-1-1)   # Execute normal cli scripts with modifications for *channel2*.   # Connect new deliver client to PO11 channel1 and retrieve all blocks for channel1 and listen forever.   ## compare results with DC1-1-1 in step 2   # Invoke a new transaction on channel1.   # After a few minutes, connect new deliver client to PO12 channel1 and retrieve latest block for channel1 and listen forever.   ## compare results with DC1-1-1 in step 2   # connect new deliver client to PO21 channel1 and retrieve block 2 and disconnect.   ## compare results with DC1-1-1 in step 2   # Invoke new transaction on channel2.   ## check output of DC1-1-2 and confirm that new block is received.   # connect sample deliver client to PO12 *channel2* and confirm that *no blocks can be retrieved*.   # Join PO12 to *channel2*, rerun step 9 and confirm that all historic blocks are retrieved.     Test passes if:   * All block events received by the deliver clients are as anticipated.   * All block events on channel1 are printed by DC1-1-1 DC2-1-1.   * All block events on channel2 are printed by DC1-1-2.   * All block events on channel1 are retrievable by all peers.   * All block events on channel2 are retrievable only by PO11 and PO12 (after PO12 has joined channel2)."
Answer: 955395.0