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 encountered an error when running "npm install" as defined in the "Writing Your First Application" tutorial.  The error indicated that OpenSSL was not installed.  Installing it fixed the error.    The Prerequisites page (https://hyperledger-fabric.readthedocs.io/en/latest/prereqs.html) should include a step to install OpenSSL.    BTW, I installed version 1_0_2.  Version 1.1.0 did not work.  
Answer: 524605.0

User story: "https://stackoverflow.com/questions/45193218/npm-fails-installing-fabric-ca-client"
Answer: 328565.0

User story: "The first-network sample in fabric samples creates user User1 and Admin. I wanted to understand how to use these users from Nodejs application. It creates keystore, signercerts,admincerts and cacerts. How should we use these certs to login to the network to invoke or execute the query. In the wallet folder for fabcar, we have three files but here we have the keystore which is priv key and signercerts is the public key, how should we create the other file (like PeerAdmin in fabcar/cred) or do we need that file for the Nodejs application.    It would be helpful to have documentation on how to get the node SDK to read the cryptogen identity info from disk    [https://chat.hyperledger.org/channel/fabric-documentation?msg=beYSWwxB82yeJgiT6]  [https://fabric-sdk-node.github.io/User.html#setEnrollment__anchor]  [https://fabric-sdk-node.github.io/Client.html#setUserContext__anchor]"
Answer: 1300710.0

User story: "Introduce delay as configurable variable (with a default of 3 seconds) for byfn.sh"
Answer: 21908.0

User story: "This story contains the necessary parts when building the system behave framework."
Answer: 391754.0

User story: "This testing includes both performance and functionality testing."
Answer: 1066216.0

User story: "These tests cover how different chaincodes interact with the fabric network and the different configurations that it may take."
Answer: 80624.0

User story: "While running the very first example fabcar if your path contains spaces, you will get an error because $PWD does not escape spaces."
Answer: 1320857.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 original concept of system chaincode (SCC) was to enable to running  chaincode in process and from that perspective it made sense to use the same generic chaincode interface for both user and system chaincode.    But for 1.0.0, SCC became the answer for writing specific system-level plugins as well - e.g. ESCC, VSCC, etc.    And now we have requirements for writing even more type of system plugins and also additional implementations of the existing SCC (e.g. alternative ESCC and VSCC for sidedb / private data store).    Given that we have specific types of plugins, using the original SCC interface / architecture for plugins no longer makes sense. We need to define explicit interfaces for each type of SCC/plugin and not implement them as generic "chaincode". This will also make it possible in the future to exploit the plugin feature of Go 1.8 and later so that we don't need to statically link these in the future.    We *might* still want to allow running of user chaincode in process (and perhaps we keep the current implementation for that purpose) but we should vet that as part of this item.
Answer: 34787.0

User story: If I pass in a CouchDB query string that specifies either `limit` or `skip`, then the query results are not as I would expect.    It seems that the peer has some code in it that forcibly sets `limit` to a configuration value from `core.yaml`, and forcibly sets `skip` to 0. It does this without checking whether `limit` or `skip` are already specified by the user in the query string.    This is the query string that we send in:  {code:java}  {"selector":{"$class":"systest.queries.SampleAsset","$registryType":"Asset","$registryId":"systest.queries.SampleAsset"},"limit":2}{code}  This is the output of the peer rewriting the query:  {code:java}  [statecouchdb] ApplyQueryWrapper -> DEBU 1f62 Rewritten query with data wrapper: {"limit":10000,"selector":{"$and":[\{"chaincodeid":"systest-queries"},\{"data.$class":"systest.queries.SampleAsset","data.$registryId":"systest.queries.SampleAsset","data.$registryType":"Asset"}]},"skip":0}{code}  This is the offending code:    [https://github.com/hyperledger/fabric/blob/d9c320297bd2a4eff2eb253ce84dc431ef860972/core/ledger/kvledger/txmgmt/statedb/statecouchdb/query_wrapper.go#L101]    IMHO the code should check for existing `limit` or `skip` values before overwriting them ;)
Answer: 339423.0

User story: Running e2e test script under examples/e2e_cli  ./network_setup.sh up $CHANNEL  even after successful run, it may (not always but quite often) still hang at    "instantiateChaincode 2", it is annoying since it doesn't happen every time, even if I add a sleeping period before the line (say "sleep 5")
Answer: 1322061.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: During event registration (block, chaincode, and rejection events), we are only checking whether the event registration message is properly signed by an identity from the same organization as the peer. As a result, one identity can receive block events (including block data which excludes read/write set) from all channels on the peer.     The following properties are required:   1. event consumer should give interested channel name along with the interested events during registration. (like we do for invoking qscc: peer chaincode query -C "" -n qscc -c '\{"Args":["GetTransactionByID","mychannel","txid"]}'    2. event producer should perform channel ACL before accepting the registration request.   3. while sending the events to consumer, need to check channel id and make appropriate decision.
Answer: 344121.0

User story: "Based on user feedback, we need to:   # Make it more obvious that this value needs to be updated   # Show in practice how a list is populated with the YAML syntax"
Answer: 1747.0

User story: "https://chat.hyperledger.org/channel/fabric-documentation?msg=qpfS2pdeK7zc88QoA"
Answer: 204344.0

User story: "When use peer channel create, -o option indictes the target where the orderer service is, and also the entry in the certificates stack. In some sitiuations, the endpoint which should be resolved to IP address may not be necessarily the entry in the certificate stack. Either a new command parameter is needed or respect the env peer.serverhostoverride to make sure that when endpoint IP address does not necessarily match the certificate entry, the peer channel create command will still work."
Answer: 7450.0

User story: "The app UI created for this doc -    [http://fabricstaging.readthedocs.io/en/latest/write_first_app.html]    Need a fabcar app UI in “Writing Your First App” for demonstrating how Fabric apps work. "
Answer: 1310268.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: "Error referenced below was caused by SELinux on CentOS. The error was resolved with the following command:    {{sudo setenforce 0}}    {{Docker was running with: --selinux-enabled}}    {{root 1041 1 0 Jul11 ? 00:00:18 /usr/bin/dockerd-current --add-runtime oci=/usr/libexec/docker/docker-runc-current --default-runtime=oci --containerd /run/containerd.sock --exec-opt native.cgroupdriver=systemd --userland-proxy-path=/usr/libexec/docker/docker-proxy-current --selinux-enabled --log-driver=journald}}    *Recommend adding a note to the docs somewhere for people running CentOS.*    Log for bringing up Dev Mode environment    {{$ docker-compose -f docker-compose-simple.yaml up}}  {{Starting orderer}}  {{Starting peer}}  {{Starting chaincode}}  {{Starting cli}}  {{Attaching to orderer, peer, chaincode, cli}}  {{orderer | 2017-07-12 19:45:21.359 UTC [orderer/main] main -> INFO 001 Starting orderer:}}  {{orderer | Version: 1.0.0}}  {{orderer | Go version: go1.7.5}}  {{orderer | OS/Arch: linux/amd64}}  {{*peer | 2017-07-12 19:45:22.220 UTC [main] main -> ERRO 001 Cannot run peer because error when setting up MSP from directory /etc/hyperledger/msp: err Could not load a valid signer certificate from directory /etc/hyperledger/msp/signcerts, err Could not read directory open /etc/hyperledger/msp/signcerts: permission denied, err /etc/hyperledger/msp/signcerts*}}  {{orderer | 2017-07-12 19:45:21.398 UTC [bccsp_sw] openKeyStore -> DEBU 002 KeyStore opened at [/etc/hyperledger/msp/keystore]...done}}  {{orderer | 2017-07-12 19:45:21.398 UTC [bccsp] initBCCSP -> DEBU 003 Initialize BCCSP [SW]}}  {{orderer | 2017-07-12 19:45:21.399 UTC [msp] getPemMaterialFromDir -> DEBU 004 Reading directory /etc/hyperledger/msp/signcerts}}  {{*orderer | 2017-07-12 19:45:21.399 UTC [orderer/main] initializeLocalMsp -> CRIT 005 Failed to initialize local MSP: Could not load a valid signer certificate from directory /etc/hyperledger/msp/signcerts, err Could not read directory open /etc/hyperledger/msp/signcerts: permission denied, err /etc/hyperledger/msp/signcerts*}}  {{*cli | h: ./[script.sh|http://script.sh/]: Permission denied*}}  {{orderer exited with code 1}}  {{peer exited with code 1}}  {{cli exited with code 126}}"
Answer: 1330516.0

User story: "The Docker compose files for all fabric-samples create the same containers. This makes it impossible for someone to switch back and forth between the examples without first stopping all running processes."
Answer: 1330522.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 {{WriteBlock}} call has traditionally been a synchronous one.  This is because the committers needed to commit before the next batch of messages could be processed.  However, with the improvements in FAB-5258 it should be possible to perform the block generation, signing, and writing to disk all on its own go routine.  Because the consenter pieces are all single threaded, this should have a noticeable effect on the throughput of the system.  Preliminary tests showed a 40% improvement (but note, this is extremely preliminary and used some cheats).    To complete this story, the ChainSupport should be given a committing go routine.  It should handle calls to {{WriteBlock}}, {{CreateNextBlock}} and {{WriteConfigBlock}}.  In general {{WriteBlock}} should return immediately while the committing go routine does its work.  {{CreateNextBlock}} and {{WriteConfigBlock}} should block until the last call to {{WriteBlock}} has completed (as {{CreateNextBlock}} requires the hash of the previous block and {{WriteConfigBlock}} will modify the config sequence."
Answer: 47445.0

User story: "The {{broadcast_timestamp}} sample client is a good way to exercise only the {{Broadcast}} path without involving any of the other components of the fabric.  However, it was developed before MSP support had been integrated into the orderer.    Further, a single client submitting on a single stream is not a realistic stress test of the orderer, so adding multiple go routines to submit would make this stressing far more realistic."
Answer: 43998.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 current orderer works in a two pass message filtering architecture.  The initial pass is done when the client invokes {{Broadcast}} and verifies that the message might be valid once ordered, then sends to the consenter for ordering.  After ordering, the consenter re-runs the verification on the messages as a second pass. This second pass ensures that the message is still valid, even after the other in-flight messages have committed.    The only cause of a message validating at {{Broadcast}} but not validating after ordering is if the channel configuration changes.  For instance, the max message size might be reduced, a certificate might be revoked, etc.    The problem with this architecture is that it implies that in the Kafka case, all messages are processed {{n+1}} times, where {{n}} is the number of OSNs.  In the Solo case, this implies messages are processed {{2}} times (as {{n}} is fixed to {{1}}.  However, in the green path, it should only be necessary to process the message {{1}} time.    The message verification step is the primary CPU bound (as it involves hashing and checking signatures) for the orderer, so improving from {{n+1}} to {{1}} has the potential to double or more the performance of the orderer.    To achieve this change, the orderer common components must be noticeably restructured.  The {{Broadcast}} path needs to include the config sequence at which the message was validated when pushing to consenus.  Then, the consenter needs to track changes in the config sequence number, trigger the second pass revalidation only when needed.  The message validation is currently buried within filters and filters within blockcutter, so this will need to be factored out into its own message processing package.    This is also a good opportunity to fix some of the directory structure which has accumulated considerable cruft during the v1 development.    Will add architectural diagrams."
Answer: 174421.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: Scenario:   * an HLF installation uses orderers that are CFT only. This is either because BFT orderers are not yet available or because the admin of that HLF instance has decided that it is acceptable   * the CFT assumption (which is a security assumption, it basically says "we assume that orderers are honest and will at worst crash") is violated - either because the ordering network is hacked in or because its administrators have become malicious and chosen to misbehave    We are in presence of a malicious ordering network What may happen?   * tx forgery is not possible (because the ordering network alone does not possess signing identities of any application org)   * *A1*: silently dropping txes is possible (e.g. the ordering network receives a tx in broadcast and it never returns it through a deliver)   * *A2*: forking attacks are possible (e.g. peer1 receives txA then txB then txC; peer2 receives txA then txC then txB)    There seems to be an easy enough way in which cross-org gossip may be leveraged to at least detect *A2*. How? If orgs gossip about the pair _(blockheight, hash)_, they will detect inconsistencies (because the hash value will not match).    Is this detection valuable? If an attack has been successfully perpetrated, it may or may not be reversible. Though of course knowing that it took place (as opposed to not knowing) has value, org members may take legal actions... etc.
Answer: 1332415.0

User story: "Today, all of our performance testing for the orderer is being done by spinning up an orderer process, bound to a port, then having external clients direct traffic to the ordering service.    This has been fine to get an overall impression of performance with the ordering code, but it's very time consuming and difficult to gauge the effect of performance improvements and to catch performance regressions.    Completion of this story should require the following:   # Refactor {{main.go}} so that the server can be started without binding to a real address, and instead supply a mock structure to register the gRPC services with.   # Create mock {{Broadcast}} clients which will submit properly signed messages via the {{Broadcast}} API. The number of clients should be arbitrary, and the message sizes should also be configurable, as should the desired channel.   # Create mock {{Deliver}} clients which operate similarly to the {{Broadcast}} ones.   # Create performance tests that leverage 1-3 to cover a variety of scenarios. Some which immediately come to mind:   ** 1 Broadcast and 1 Deliver, each going as fast as possible on a single channel   ** many Broadcast and 1 Deliver on a single channel   ** many Broadcast and many Deliver on a single channel   ** 1 Broadcast and 1 Deliver for each of many channels   ** many Broadcast and many Deliver for each of many channels   ** (a)-(e) each with small, medium, and large messages"
Answer: 22883.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 idea is to expose channel leader in org and channel members using system chain code to outside world. This item suggest to add an API into QSCC in order to enable queries to see who are participants/members in specific channel and also whenever given peer is the leader of the channel within its organization."
Answer: 619578.0

User story: In the past, we made the decision to include the shim both as a convenience to our users (to avoid explicit vendoring) and as a space optimization (why have every chaincode include the same shim lib over and over?).    Fast forward to now: go dependency management leaves much to be desired.  Having the ccenv include the shim can be problematic w.r.t. fragility between the included shim and the chaincode application.  For example, try to write an application which uses the timestamp features of the shim and you will receive errors due to conflicts between the fabric vendored version of the protobuf library and the chaincode application.    Now that we have auto-vendoring, the convenience factor for including the shim is gone.  It only leaves the space optimization consideration.  Considering how fragile go dependency management is, we may want to go the conservative route and simply remove all dependencies from the ccenv and make "peer package" / "chaintool package" provide them via the auto-vendor feature.         If we are going to do this, we should do it before v1.0 is cut so that chaincode apps for 1.0 are properly formed in a non-breaking way going forward.
Answer: 1133834.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 gossip whenever a batch of channel-scoped messages (either leadership, blocks, stateInfo, etc.) is sent to remote peers, a function goes over all existing alive peers and then selects from them a subset of peers.   This is done in *gossipInChan* function:  {code}    // Select the peers to send the messages to    // For leadership messages we will select all peers that pass routing factory - e.g. all peers in channel and org    membership := g.disc.GetMembership()    allPeersInCh := filter.SelectPeers(len(membership), membership, chanRoutingFactory(gc))    peers2Send := filter.SelectPeers(g.conf.PropagatePeerNum, membership, chanRoutingFactory(gc))    // Send the messages to the remote peers    for _, msg := range messagesOfChannel {     if msg.IsLeadershipMsg() {      g.comm.Send(msg, allPeersInCh...)     } else {      g.comm.Send(msg, peers2Send...)     }  }  {code}    In case of leadership messages, the subset is taken from the entire membership set without *an upper bound* (we gossip leadership messages to all peers in the channel), and in case of non-leadership messages the subset is taken with *an upper bound* equal to the propogation fanout (configurable).    Finding peers that are eligible to receive any channel-related data involves cryptographical computations and is non-negligible (measured ~ 25ms in a network of 8 peers)    The 2 possibilities (leadership and non-leadership) are calculated even though each method invocation of *gossipInChan* receives only 1 type of message.  Therefore, it would be beneficial performance wise to just calculate the option that is relevant to that method invocation and not calculate both options each time."
Answer: 569.0

User story: "In gossip there are send and receive buffers that are allocated for each connection.  When the throughput of messages is too high and the send buffer overflows, the connection to the peer is closed and the peer is removed from the membership.    From performance evaluations I did - I conclude that:  *  Increasing the send buffer size would benefit to withstand intense bursts of messages, even when the receive buffer stays the same.  *  Not closing the connection to the peer (and not removing it from the membership) that its corresponding send buffer overflowed helps the throughput by giving the runtime an opportunity to recover in spite of an intensive burst."
Answer: 483.0

User story: "After the merge of -------FAB-4626--- ([FAB4904])-- the client.config emitted by examples/cluster s incomplete for the needs of a well functioning client.    Based on  -----FAB-4626----- a few interpretations of the appropriate output are possible. Towards providing a robust example suitable for a non development environment, the proposal is to:    *Emit a ca certificate and TLS certificate block.*    Towards this effort, unlike the e2e test suite, example clusters ought to use *a set of certs for fabric interaction* and *a separate set of certs, with separate root, for TLS*."
Answer: 1346294.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: "While it is implied that you should install the prereqs and clone the fabric source, you really should not need to do this for building chaincode.  We can eliminate the need for libtool by adding the documenting the use of the  {noformat}  --tags nopkcs11{noformat}  build option.  We should also document the users can do a  {noformat}  go get{noformat} to get the shim package"
Answer: 10871.0

User story: "We would like to support in Hyperledger private data that is visible to some peers but not others, and moreover support transactions that are based on such private data. We propose below a modest change to the current architecture that opens the door  to a wide range of advanced applications, including multi-party computation and other cryptographic solutions.    Design:    Design Document    [Supporting private data in Hyperledger|http://docs.google.com/document/d/16SYkK_wxReCeAEXbgobP6B8vW-VTGNQ_qRmJemS_jTI/edit?usp=sharing]          "
Answer: 1121520.0

User story: when using kafka consensus mode, we can not create channel due to time out problem when we try the Fabric example e2e_cli.    reproduce steps:   # change ordererType from solo to kafka in configtx.yaml of Faric example e2e_cli (fabric/examples/e2e_cli)   # start up test environment by docker-compose   # execute script.sh under scripts folder   # The script always failed to create channel due to time out or service unavailable message    After I dig into the source code of orderer, I found that there's a problem in function retryProcess::try.    in this function, we must wait for tickInterval.C before executing target function, this lead to useless time waiting for the first try. It shall try first and wait a while for next retry.       {code:java}  // the bug is located in fabric source code file: fabric/orderer/kafka/retry.go  func (rp *retryProcess) try(interval, total time.Duration) error {      // ... some code removed      tickInterval := time.NewTicker(interval)      tickTotal := time.NewTicker(total)      defer tickTotal.Stop()      defer tickInterval.Stop()      logger.Debugf("[channel: %s] Retrying every %s for a total of %s", rp.channel.topic(), interval.String(), total.String())        for {          select {          case <-rp.exit:              exitErr := fmt.Errorf("[channel: %s] process asked to exit", rp.channel.topic())              logger.Warning(exitErr.Error()) // Log it at the warning level              return exitErr          case <-tickTotal.C:              return err          case <-tickInterval.C:              logger.Debugf("[channel: %s] "+rp.msg, rp.channel.topic())              if err = rp.fn(); err == nil {                  logger.Debugf("[channel: %s] Error is nil, breaking the retry loop", rp.channel.topic())                  return err              }          }      }  }    {code}        
Answer: 13749.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: "Currently the cryptogen tools can only support to generate all the crypto files from the specific crypto-config.yaml which contains all the pre-defined Orgs, Orderers, Peers and Users.    If we want to dynamically add a new orderer/peer/user in a blockchain network, we need to generate the crypto files firstly.    So the cryptogen tools should support to generate crypto files for a new orderer/peer/user and the certificate signed by existing root certificate."
Answer: 1348715.0

User story: "Continuously modify the environment to meet the development and testing requirements. [~<USER>    reference:    1.Images: [https://hub.docker.com/r/yeasy/]    2.docker-compose: [https://github.com/yeasy/docker-compose-files/tree/master/hyperledger/1.0]    Now we can start a network with 1-ca,1-orderer, 1-peer and 1-cli.    Done:   # add a script to docker-compose-file, enable network start with `create` and `join` done   # change docker-compose-file name to docker-compose-1-peer.yaml"
Answer: 40404.0

User story: "The peer currently allows a hard-coded set of components to override the log level set via CORE_LOGGING_LEVEL or CORE_LOGGING_PEER. This functionality should be improved to allow any component to be specified (whether in core.yaml or via an environment variable) and override its log level."
Answer: 705806.0

User story: "Adding salt to private data is required to avoid dictionary attacks."
Answer: 1215491.0

User story: "Add chaincode policy to allow non-key queries in transactions, even if phantom validation cannot be performed due to private data not available (no access or missing)."
Answer: 1349844.0

User story: "Add chaincode policy to halt rather than proceed with missing private data."
Answer: 1349846.0

User story: "design doc - [https://docs.google.com/document/d/1ORt3HFE13gnq204lXNp6i1BpMLMm-RAKVts8cH50kK4/edit?usp=sharing]"
Answer: 461262.0

User story: "Stories:    As an organization that has recently been added to a collection via a chaincode upgrade, I would like to automatically receive the prior private data for the collection, so that I can query and endorse future transactions.    As an organization that has access to a collection but couldn't retrieve private data when it was initially committed time, I would like to automatically receive the prior private data for the collection, so that I can query and endorse future transactions.         High - level design doc - https://docs.google.com/document/d/16OzAAc-JoxSUDHVva3AYuj_MzslAtoXOGcbjSIwUqUg/edit"
Answer: 758387.0

User story: "Need to purge from transient store any orphaned private write sets for transactions that never got submitted for ordering/commit.    Since these records are stored by tx id rather than by collection, the block-to-live policy should not be at collection level, rather it should be at the peer level (core.yaml)."
Answer: 156075.0

User story: "Need to specify a block-to-live policy in the collection configuration for private data."
Answer: 443866.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: "Private data may be missing for a variety of reasons:    1) Peer may not have access to private data    2) Peer did not previously have access to private data    3) Peer had access to private data, but couldn't find private data at validation time.      This feature will check for missing private data at endorsement time and return error accordingly.    Also, since not all peers will have data to support validation of non-key queries, invalidate transactions that performed non-key queries."
Answer: 124065.0

User story: "The goal of this task is to extend state transfer capabilities to enable it to replicated private data of transactions, which is distributed out of the ordering service scope."
Answer: 100715.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: As an end user I should be able to see all the default configurations for the corresponding components in one place. And it should be easy for me to find those files, including from doc page and BYFN instructions. And the set of yaml files should contain ALL the default values, and be put in a directory location named "config_defaults" or something like that.    It is not clear if the fabric/sampleconfig /*.yaml files are the default values, and they do not set default values for all the possible configuration variables. Apparently, someone needs to refer the source code to gain a complete understanding of all the default settings.   * *peer/gossip/ledger/endorser* etc., related configurations needs to be captured in _*core.yaml*_   * *Orderer/Kafka* related default configurations in orderer.yaml (or what ever is the right file)   * *configtx.yaml* _*-* channel config related configurations_     
Answer: 1111583.0

User story: After "make html", all the html files will be generated in in docs/build/html.So if we want to have a web server, we should copy all files in docs/build/html, not source/build/html.
Answer: 1040.0

User story: "SDK clients always log transaction id before sending requests to peers and orderers. This makes it ideal to search and grep through logs to follow the request flow.  When the orderer receives a request it would be ideal to have it as early on in the flow of work to log the transaction id."
Answer: 63217.0

User story: "In gossip when a peer obtains an AliveMessage from a peer it hasn't received its certificate yet - it complains in the log in WARNING that it has received a message from some peer it can't verify its identity.    This is actually a common scenario where a peer is restarted and its in-meory certificate store is now empty, but the other peers contact the peer and send it alive messages which he can't verify until it syncs its certificates with them.    This startles users and I think we should reduce the logging severity from WARN to DEBUG."
Answer: 4470.0

User story: When a peer is in a partition or is dead for a long enough time, gossip prints:  {code}  Haven't heard from", id, "for", elapsedNonAliveTime  {code}    The problem is that the *id* is a string of a hash and its printed in gibberish.  It's not something humans can read, and we need to cast the string back to *[]byte* so it would be human readable.
Answer: 4483.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: "We've had lots of discussion and debate on branching strategy in chat and on the mailing list. Time to make a decision and move forward is fast approaching.    The general consensus seems to be on a 2 branch strategy where we have the following branches:    master    release    We would use master for development, and release for the stable releases. The release branch would be made the DEFAULT branch on GH so that people cloning or forking the Fabric repositories would always be getting the latest stable release as the default, as opposed to people pulling from HEAD which would generally be somewhat unstable. This should yield a better end-user experience for people that want to build from source.    Of course, they can always change the branch and access master and the development HEAD if they so choose, but there's some effort involved.     People working on Fabric repos would still be pulling the default master branch from Gerrit, and there would be no change to people pushing CRs by maintaining the master branch for development.    We would FF merge master into release when the time comes to cut a release.    Any fixes to release branch will need to be managed on both branches.    So, the point of this JIRA is to have a means of recording consensus. Please vote if you agree to adopt this strategy or leave a comment if you are opposed with the reasons for your opposition."
Answer: 374503.0

User story: The doc "msp-identity-validation-rules.rst" misses title. The doc looks like  {code:java}  For more information on the validity of identities in the current MSP implementation we refer the reader to the identity validation rules <no title>.{code}
Answer: 21186.0

User story: "I'd like to provide platform specific installers for Fabric tools/binaries in time for 1.0.    MacOSX == homebrew    Windows == choclatey or innosetup    linux == apt"
Answer: 396080.0

User story: "The orderer checks the Writers policy for each incoming transaction, in general, this requires recursing through multiple policies, to attempt to find one which is satisfied.  This is done in a serial way and is likely slowing us down.  It would be a relatively trivial fix to parallelize this process."
Answer: 1372754.0

User story: "The orderer has a 'JSON' ledger as an option for block storage.  This ledger is meant to be a debugging tool, so it prints the block contents as JSON so that the user may inspect the ledger easily with cat, etc.    However, the JSON marshaling is done via the simple jsonpb marshaler, which simply converts the byte fields to base64, rather than displaying the marshaled message in a readable form.    The protolator framework was created to solve just this problem, and could be utilized by the JSON ledger to make the debugging output much more useful."
Answer: 1382504.0

User story: "Similarly to the REST server component FAB-4107 , a CLI component to access the proto translation and config updates must be created."
Answer: 415774.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: I am working around to figure out that Fabric v0.6 is really not allowed data modification illegally. Beside I want to modify data in "sst" format directly. I want to use some other such as create instance of database then retrieve all data -> Modified them -> put them back and star the peer normally. but when I try to create instance of Rocksdb, I got this error    !Snip20170518_1.png!  Based on this tutorial: [http://pyrocksdb.readthedocs.io/en/v0.4/tutorial/index.html]    If it's a new database then it's fine. while it come to database of blockchain, I got this few error.      
Answer: 19407.0

User story: "We really need to have a simpler presentation and we could use a sample app.    I'd like to see the binaries installable via the likes of homebrew (OS X), NuGet (Windows) and apt (linux).    If we don't have that, then ideally we present a less complicated structure for the tarball.    The yamls and scripts should be at the top, and binaries should be under bin/ It might be worthwhile including a simple installer if we don't have native installer support.    It would also be good to simplify the prose in getting_started.rst - right now, it is overly complex in its presentation (IMO).          "
Answer: 43512.0

User story: "As a tester, I would like to know a quick way to start up a fabric blockchain network, so I can test it with existing tools or with my own tool. I may wish to write and/or test my own chaincode, and need to quickly spin up a network. Or, I may wish to add tests to the fabric repository, including how to add my own project's chaincode framework.    Tools and readme files are being written inside fabric/test/ directory structure; let's provide in the [http://hyperledger-fabric.readthedocs.io/en/latest/testing.html] a list of the things that can be done easily, along with links to those directories readme files."
Answer: 1390901.0

User story: "[http://hyperledger-fabric.readthedocs.io/en/latest/getting_started.html]    page needs an overivew introduction. I suggest categories for readers to identify themselves in their own use-case, including users (testers, who may only want a working network to test) and users (chaincode developers who do not need to know all the details about creating a fabric network):   * Are you looking to become a Fabric Developer?   * Are you looking to use Fabric, to develop and test your own chaincode?   * Are you looking to test Fabric?    Provide links to other appropriate readme files, or to sections further below in this page."
Answer: 43728.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: "we really need to improve the getting started experience. We had a bootstrap for v0.6 and we need to have one for v1.0*.         basically, you would add to GS doc the following instruction:    To download and install the various Fabric artifacts needed to get started, execute the following command from a terminal shell:    % curl -sS [https://raw.githubusercontent.com/hyperledger/fabric/master/examples/e2e_cli/bootstrap.sh] | bash    This will download our end-2-end example and the docker images needed to run it.    NOTE: we could add checks for Docker and other prerequisites, but with the docs providing that info, that can wait.     "
Answer: 137.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: "[https://hyperledger-fabric.readthedocs.io/en/latest/Setup/logging-control.html] provides a good overview of logging and environment variable controls for the fabric peer cli and CC containers    Extending the coverage of this page to include the other components under their own header (h1 project, h2 component, etc) will increase coverage, notably improving new user onboarding experience and the comprehensiveness of this RTD logging section.    This change should provide the necessary information for a user to adjust the logging levels of at least:   # Each officially supported fabric SDK   # Fabric ca client    # Fabric ca server   # Orderer    Additionally, the existing peer and CC coverage, as well as the above mentioned list, should be expanded to include the container level controls for logging in the commonly supported files (.yamls come to mind).    As this logging page appears to return as a high result for many search engines when searching 'hyperledger fabric logging' it is appropriate for this to provide a comprehensive overview including the above.                    "
Answer: 1410772.0

User story: "Currently, the sample clients for the orderer are working without MSP signer and TLS features. This improvement would provide a new sample client with these two features.    The original client deliver_stdout assumes no TLS dial option and the payload was not signed with any certificate. A new client extended deliver_stdout was created to include     1. TLS dial option which requires the user to specify the CA file for TLS;    2. MSP signing the payload which requires the user to specify msp directory which contains folder signcerts, keystores, admincerts and cacerts.    Code implementation can be found: [https://gerrit.hyperledger.org/r/#/c/9625/]      "
Answer: 123291.0

User story: "Need understanding surrounding the authorizations for creating and updating chains and their configurations. This includes understanding how each component in the process will validate the ACL authorizations for the chain creation and update requests."
Answer: 1411163.0

User story: "Need understanding of how to manage authorizations around who can deploy, instantiate and update chaincode to various chains. This includes chaincode signing and how the signing is validated by each of the components during each process."
Answer: 1411171.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: "8 performance benchmark tests for testing concurrency and obtaining Transactions Per Second (TPS)    performance tool: PTE    network configuration: 1 channel, 2 org, 2 peer with TLS enabled    chaincode: sample_cc    transactions: each thread sends 1000 transactions to the anchor peer in org 1         Repeat the following testcases when using 4 threads, and when using 8 threads:   # 4 threads X 1000 invokes, basic solo network   # 4 threads X 1000 queries, basic solo network   # 4 threads X 1000 invokes, svt kafka network   # 4 threads X 1000 queries, svt kafka network   # 8 threads X 1000 invokes, basic solo network   # 8 threads X 1000 queries, basic solo network   # 8 threads X 1000 invokes, svt kafka network   # 8 threads X 1000 queries, svt kafka network         svt network, kafka: [https://github.com/<USER>fabric-docker-compose-svt/blob/master/docker-compose-e2e.yaml]    basic network, solo: [https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/docker-compose-e2e.yaml]         Expected results:    Automated test will pass if all transactions are processed successfully,    The overall TPS (Transactions Per Second) will be calculated."
Answer: 1156806.0

User story: "This story covers creating a shell script for running the Auction App in the Daily/Weekly Test Suite"
Answer: 21137.0

User story: "Auction App created  by IT People Corporation was initially developed in Fabric V0.6.     This story covers migration of chaincode from V0.6  to V1.0.     "
Answer: 22954.0

User story: "Similar to what the peer does. This will allow for easier debugging."
Answer: 423302.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: Because ChaincodeStubInterface is the central point of contact for chaincode developers, it's of utmost importance to fully specify the behavior that should be expected of the methods defined by that interface.  In particular, specifying conditions on the method arguments, and fully specifying what the return values mean and what the error conditions are.    Some methods' comments provide almost no information that isn't already conveyed by the method name itself.  For example: GetState, PutState, DelState.  In particular for these three, it's not clear what the behavior will be in the corner cases, such as if the key is not found, or if it's already present, or in what circumstances an error will be returned.  Having these all specified by the comments will facilitate chaincode developers in writing code that correctly handles all corner cases.    Some methods' comments don't provide enough in-source context for how they would be used – example usecases, etc – for example: CreateCompositeKey, SplitCompositeKey.  What is a "composite key", and where do I use it?    Returning specific types from functions is a great way to self-document code, because if the return type is specific enough (e.g. GetQueryResult returning StateQueryIteratorInterface, which has its own documentation and specific example usages; or GetHistoryForKey returning HistoryQueryIteratorInterface, which is a similar concept but is fortunately represented by a distinct type), then less needs to be explicitly written in the documentation.    Contrast this with GetBinding which returns the "transaction binding" as a generic ([]byte, error) value, which does not give any clear place to look for what format it is or how to use it.  Googling `hyperledger "transaction binding"` turned up the interfaces.go source code and the Protocol Spec doc which references code that's out of date.  At the very least, there needs to be comments to the effect of "returns the transaction binding as a byte array in XYZ format, which can be used in functions A, B, and C to do operations P and Q (or whatever a transaction binding is used for)".    Generally to write good documentation it's necessary to have an accurate theory of mind for the reader – who are they, what context are they operating in, how much can they be expected to know, etc.  I would suggest that the target audience for interfaces.go should be non-expert programmers, familiar with golang, who have little DB or cryptographic knowledge/experience.  Then, give links to facilitate them to learn more about relevant topics with "for more, see X" links in the comments.    Example code is also great, though for something as important as ChaincodeStubInterface, one can't and shouldn't be expected to deduce all corner cases from example code.
Answer: 1412533.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: "We would like to have a mechanism for developing post 1.0 features. E.g., creating a new branch.    Some of the proposed items:   * Private Channel Data (FAB-1151). Proposal announcement by <USER>(SecureKey Technologies): [https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-May/000949.html]    (please add to the list)."
Answer: 253735.0

User story: "In the gossip tests there is a waitgroup counter that is used for the last test (that checks that goroutines ended) to be able to run only when all the other tests have finished.    Currently the waitgroup counter is initialized to the number of tests that can be stuck, but should really be:  * Exported into a constant  * Initialized to the total number of tests    "
Answer: 141006.0

User story: "The golang shim UT coverage is around 17%. While the shim is excercised through chaincode UT, we need to add lightweight, targeted UT coverage to the shim layer.    This would entail a bit of refactoring to accomodate mock objects  * stream to mock chaincode to peer communication  * CC support to mock peer side chaincode support to hold chaincode streams (some tests would involve multiple chaincodes for example)    The mock stream object would encapsulate responses to ChaincodeMessages received. The UTs will be driven through driving targeted request responses though the mockstream    "
Answer: 26262.0

User story: "In order to support hyperledger in a production environment, especially when hosting many networks for other users, we need a way to easily tell if a peer is healthy.  Simply checking if the process is running isn't enough, and looking at the logs is great for debugging a single network, but doesn't scale when trying to support many networks in a production environment.    A simple, low impact, CLI or grpc call that verified that returned status indicating whether or not a peer was healthy, or a simple check we could do on a network we were hosting for other users (so didn't require us to submit transactions) would suffice."
Answer: 795435.0

User story: "We need a way to export metrics of gossip (amount of messages in memory, amount of messages discarded due to comm buffer overflows, blocks that are disseminated, etc.)"
Answer: 796380.0

User story: "LOC coverage is under 50%"
Answer: 5694.0

User story: "Current unit test coverage is very low for the events package. This item will be used to add test cases to more thoroughly test the package. "
Answer: 15774.0

User story: "Currently, the cryptogen's APIs are not able to generate intermediate CA certificates and revocation lists. These two features are useful in general, and in particular to generate MSP configurations to test bad paths.    I have already submitted a change-set at https://gerrit.hyperledger.org/r/#/c/9275/. It modifies the CA struct to add additional methods to cover the needs described above.  "
Answer: 1419093.0