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: "When you query CouchDB directly, the response has very useful information, for instance see: http://docs.couchdb.org/en/master/api/database/find.html?highlight=query. There you will see that along with the data, you get execution time and total number of results returned. At the moment, the chaincode API does not provide any of this information back to the developer. It would be great if some of this information that CouchDB already provides in the response is made available to the developer through the chaincode API."
Answer: 672506.0

User story: "More control over the configuration of the collocated CouchDB instance - It is true that currently developers can use rich queries in the chaincode to query the collocated CouchDB instance. Developers can package JSON index files with their chaincode to define indexes. However, what about defining views? CouchDB supports further control via the specification of a design document (http://guide.couchdb.org/draft/design.html). If Fabric exposed some of this functionally to developers, developers could create views to collate data together and create even better queries, for instance joins with views (https://docs.couchdb.org/en/2.2.0/ddocs/views/joins.html)."
Answer: 672509.0

User story: "* We need more samples for a beginner.         BYFN is a very good sample.     I upgraded BYFN into Multi-Channel Network Sample, so that they understand Fabric more easily.         In Multi-Channel Network, I removed eyfn( org3-artifacts ).    While I make this sample, I think I understand a bit more about Fabric.    I wish other beginners are too through this sample.        * Multi Channel Network (MCN)   ** This is Multi-Channel Network based on BYFN.   * There are 4 Orgs( org1, org2, org3, org4 )   ** Each org has one peer except org3 has two peers( peer0.org3 and peer1.org3 ).   * There are 2 Private Channels.  Each channel consists of org's peers like bellow.   ** Channel1( peer0.org1, peer0.org2, peer0.org3 )   ** Channel2( peer1.org3, peer0.org4 )              ps: This is my first contribution. If I make a mistake, please let me know.         Thank you."
Answer: 15794.0

User story: "There are intermittent timeout errors in the behave system tests that result in one of the following error messages.  for the chaincode containers:  {code}The expected chaincode container aa4eccfccc3b11e89fa4fa163e71fb71-peer0.org1.example.com-mycc1-0 is not running{code}    or for the kafka containers:  {code}The kafka containers are not ready in the allotted time (300 seconds){code}    https://jenkins.hyperledger.org/view/fabric-test/job/fabric-test-daily-behave-master-x86_64/50/consoleFull"
Answer: 420908.0

User story: "Post-1.3 release, we can reinstate the jsdoc production of the jsdocs . "
Answer: 674534.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: "Hyperledger Fabric v1.2    Currently, developers can fire off one and only one chaincode event within the context of a single transaction. This is very limiting; instead, developers run into use cases where firing off multiple chaincode events is needed.    The current API for firing off chaincode events looks like this:   ChaincodeStub.SetEvent()    Instead, it would be great if the API was improved to something along the following lines:    ChaincodeStub.AddEvent()   ChaincodeStub.GetEvents()"
Answer: 675900.0

User story: "When the {{pprof}} network endpoint is exposed, a {{GET}} request to {{/pprof/goroutine?debug=2}} will capture all of the currently running go routines. When {{pprof}} is not enabled, this information is harder to come by.    In an effort to improve the situation, a signal handler should be implemented in each of the fabric servers that will use {{runtime/pprof/#Lookup}} to get the {{goroutines}} profile and log it with {{runtime/pprof/#Profile.WriteTo}} to a properly configured logging with debug level 2. This will capture the go routines into the logs without terminating the process.  "
Answer: 54532.0

User story: "Since gRPC is our invocation protocol of choice, we need to surface metrics  that are consistent with the RED monitoring philosophy:    - Request **R**ate  - Request **E**rrors  - Request **D**uration    These metrics are generally required by any monitoring solution and should be  surfaced consistently across all gRPC services.  "
Answer: 71843.0

User story: "Fabric's API is primarily surfaced as gRPC services. Logging the completion of a request with the appropriate context can serve as an access log for gRPC. When detailed debug is required, message based logging for streaming APIs may be helpful."
Answer: 29163.0

User story: "Application developers often forget to appropriately reuse or release resources. In the case of fabric, if an application does not reuse gRPC connections, we are subject to some side effects. In particular, performance will suffer because the client needs to establish a new connection to the server and another TLS handshake occurs. Second, client side ephemeral ports can become exhausted. Third, the server can experience pressure on memory and  file descriptor resources.    By surfacing information about the number of active connections, operators can observe unbounded growth in connections and use that to determine an appropriate course of action.    The start and end of a connection can currently be determined by implementing the `grpc.StatsHandler` interface and configuring it as a `grpc.DialOption` or `grpc.ServerOption`."
Answer: 71906.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 go runtime provides hooks for monitoring that need to be wired into the metrics subsystem of choice.    Memory: https://golang.org/pkg/runtime/#ReadMemStats  Go routines: https://golang.org/pkg/runtime/#NumGoroutine    Surfacing these metrics as gauges will provide some basic insight into the process characteristics. As the data can only be retrieved from polling, collection will need to be associated with a ticker.  "
Answer: 85411.0

User story: To prevent dragging bunch of unnecessary complexity, the healthcheck should be implemented as a basic http or https endpoint at /healthz. When the peer is healthy, it will return with a status of `HTTP 200/OK` and JSON payload of '{"status": "OK"}'. If the peer is responsive to the status check, but unhealthy, it will return with a staus of `HTTP 503/Service Unavailable` and a JSON message that indicates which subsystem has failed the health check.
Answer: 85438.0

User story: To prevent dragging bunch of unnecessary complexity, the healthcheck should be implemented as a basic http or https endpoint at /healthz. When the peer is healthy, it will return with a status of `HTTP 200/OK` and JSON payload of '    {"status": "OK"}    '. If the peer is responsive to the status check, but unhealthy, it will return with a status of `HTTP 503/Service Unavailable` and a JSON message that indicates which subsystem has failed the health check.
Answer: 133873.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 of a combination of how we've built our configuration on top of viper and how we rely on package level initialization for logging, we have a situation where setting up a log level is not as simple as it should be. To remove the confusion, we need three things:    - A mechanism to configure a single logging spec that is honored before any log    records are written  - A mechanism for operators to retrieve the active logging spec  - A mechanism for operators specify a new logging spec    In concrete terms, this means we need to use remove the logging levels from our configuration system in favor of an environment variable or a flag. If we decide we need both an environment variable and a flag, the flag will take precedence.    The logging spec will be similar to the existing model used by the admin service. That said, unlike the current spec, it will not be applied incrementally to what's running and will completely override, as atomically as is feasible, the enabled loggers.    Logger names are composed of one or more dot (period) separated names. This is to be consistent with the conventions implied by zap named loggers.    The log spec is a single string that consists of colon separated tokens. Each token declares a logger name prefix and a optional log level. When the logger name prefix ends with a period, it indicates that the log level should only apply to the logger with the exact name when the trailing period is dropped. When the logger name pattern is omitted, it specifies the default log level. In cases where multiple entries reference the same name pattern or multiple  instances of a default are provided, the last specification takes precedence.    When prefixes are evaluated against logger names, the longest match from the spec will be used.    Examples:  - `info` enables all loggers at the _info_ level  - `a=debug` enables loggers with names like `a`, `a.b`, or `a.b.c` at the _debug_ level; all other loggers will log at the _info_ level  - `a.=debug:warn` enables the logger named `a` at the _debug_ level; all other loggers will be at the _warn_ level  - `a.b=debug:a.b.c.=warn` enables loggers with names that start with `a.b` at the _debug_ level except for the one named `a.b.c` which will log at the _warn_ level. All other loggers will log at the _info_ level.  - `info:warn` enables all loggers at the warn level  - `broken` is rejected as an error and the logging configuration is unchanged. If a bad spec is provided as the process is starting, the process will execute with the default log specification of `info`.  "
Answer: 89183.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: "parameter {{chainid string}} in [this method|https://github.com/hyperledger/fabric/blob/release-1.3/core/peer/configtx_processor.go#L56] is not used, therefore should be deleted.    context: this parameter was introduced in commit [67746c|https://github.com/hyperledger/fabric/commit/67746c369b06119e9389f3ea2ef947d811a0b656#diff-adf25123dd66b461d35eaa72bf2a18ef] and later unused in [3d83ff|https://github.com/hyperledger/fabric/commit/3d83ff0853130dc01fe9d7fef27329ecb6f8d991#diff-adf25123dd66b461d35eaa72bf2a18ef]    although, if we want [peerNameSpace|https://github.com/hyperledger/fabric/blob/release-1.3/core/peer/configtx_processor.go#L20] to use {{chainid}} instead of empty string, we need to keep this parameter. see FAB-12337"
Answer: 4474.0

User story: "Currently node chaincode has hardcoded grpc options which cannot be overridden. Someone who architects and builds a Hyperledger Fabric solution should be able to define the grpcOptions that chaincode should use when communicating with a Peer as the hardcoded defaults may not be appropriate to the architected infrastructure.     This might be something that can be defined in the core.yaml of a peer to define the required grpc connectivity options that a chaincode container should use. This may also be useful for non-node chaincode containers to honour as well.    This originated from Node chaincode, but is equally applicable to Java and Go chaincodes as well."
Answer: 526920.0

User story: "[peerNameSpace|https://github.com/hyperledger/fabric/blob/release-1.3/core/peer/configtx_processor.go#L20] should be {{chainid}} instead of empty string."
Answer: 5475.0

User story: "simulator.SetState(peerNamespace, key, serializedConfig) -> simulator.SetState(chainid, key, serializedConfig)"
Answer: 5730.0

User story: "specifiec to specified"
Answer: 679635.0

User story: "Updates to samples for commercial paper application and smart contract as a result of enhancements"
Answer: 60927.0

User story: "Add tutorial for commercial paper"
Answer: 61531.0

User story: "Before executing test scenarios, existing containers should be removed."
Answer: 283.0

User story: The peer provides an admin interface to control the logging level of the assorted peer components without restarting the peer.    However, to set logging levels in the orderer, the orderer must be restarted.  Frequently in production the ability to set log levels in the orderer without having to restart the process (potentially creating application outages) is desirable.    Management of the orderer logging settings should be administrated just like with the peer, where the local MSP's admin certificates are the only users authorized to modify the orderer log levels.    For this story to be accepted, we should be able to start the orderer at one log level, then as the orderer admin user specify a new set of logging levels (such as "info:orderer/consensus/kafka/=debug") and see the updated logging levels reflected in the log output.
Answer: 82135.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: "*Acceptance*: A simulated client submits a token transaction with atomic swap content. Committing peers that receive this transaction make this transaction go through the token transaction validation and commit path that for now marks the transaction as invalid and does not impact the ledger. "
Answer: 674271.0

User story: "*Acceptance*: A simulated client submits to the prover service an atomic swap proof request. The prover peer retrieves the proof request and rejects if the request is malformed, i.e.,    * it is not signed by a writer of the channel   * it does not preserve the structure designated to atomic swap requests    The prover peer should return to the simulated client a pre-cooked TokenTransaction with atomic swap content."
Answer: 687675.0

User story: "There is a need to more easily locate specific log messages and know what potential actions to take based on the messages. Log messages should include a message code so that they can be uniquely identified. This will facilitate problem investigation and will make it easier to identify symptoms of certain types of problems that are often indicated by a certain set of log messages.         Following are suggestions for organizing message codes.   * Identify all Hyperledger Fabric logical components and subcomponents and create a message code prefix for each logical component (or a grouping of smaller related subcomponents). This message code prefix could be a unique string of a short sequence of letters with a name that relates to the component.   * For each component, define groups of the possible types of messages and reserve ranges of message codes for each type of message. For example, messages in one area could be assigned a range of 1-999 and messages in another area could be assigned a range of 1,000-1,999, etc. A reason for creating ranges is to allow for future addition of message codes.   * Include within the code whether the message is informational, warning, error, etc. Current messages are prefixed with this information, but if a message code approach is adopted, then this information could be included within the message code.         For example, a message code could look something like ENDORSER00123I. This has the component (ENDORSER), a message code of 00123, and a suffix of `I` for an informational message.         A current message looks like this:    {{2018-08-23 07:05:42.789 UTC [kvledger] CommitWithPvtData -> INFO 115 [0m Channel [channel1]: Committed block [39236] with 1 transaction(s)}}         With a message code included, it would look something like this:    {{2018-08-23 07:05:42.789 UTC [kvledger] CommitWithPvtData -> KVLEDGER00115I [Channel [channel1]: Committed block [39236] with 1 transaction(s)}}"
Answer: 688724.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 system behave tests perform a "npm install" every time the Node SDK is used. Time can be saved and consistency ensured by performing an "npm install" once at the beginning of the test suite, then whenever the Node SDK is used, the node_modules directory is already in place.     Care must also be taken to ensure that the node_modules directory is not deleted at the end of each test run.    Performing this change will shave minutes off of the smoke and daily test runs.
Answer: 106804.0

User story: Currently there is {{chainExists}} method which was introduced in early versions    {code}  func (v *TxValidator) chainExists(chain string) bool {   // TODO: implement this function!   return true  }  {code}    which stubbed to always return {{true}} and this is actually fine as validator always intialized in context of committer which is bounded to one channel which is existing. Function aimed to be used during validation, while reading block header to ensure we are working with existing channel:    {code}    channel := chdr.ChannelId    logger.Debugf("Transaction is for channel %s", channel)      if !v.chainExists(channel) {     logger.Errorf("Dropping transaction for non-existent channel %s", channel)     results <- &blockValidationResult{      tIdx:           tIdx,      validationCode: peer.TxValidationCode_TARGET_CHAIN_NOT_FOUND,     }     return    }    {code}    In FAB-12030 as part of serviceability enhancement, txvalidator struct was extended with {{ChainID}} field    {code}  type TxValidator struct {   ChainID string   Support Support   Vscc    vsccValidator  }  {code}     As a consequence now we can just leverage this information while unpacking block header to check validator is operating on correct channel, i.e. basically following code could be cleaned up and refactored from:    {code}    channel := chdr.ChannelId    logger.Debugf("Transaction is for channel %s", channel)      if !v.chainExists(channel) {     logger.Errorf("Dropping transaction for non-existent channel %s", channel)     results <- &blockValidationResult{      tIdx:           tIdx,      validationCode: peer.TxValidationCode_TARGET_CHAIN_NOT_FOUND,     }     return    }  {code}    into    {code}    channel := chdr.ChannelId    logger.Debugf("Transaction is for channel %s", channel)      if v.ChainID != channel {     logger.Errorf("Dropping transaction for non-expected channel %s", channel)     results <- &blockValidationResult{      tIdx:           tIdx,      validationCode: peer.TxValidationCode_TARGET_CHAIN_NOT_FOUND,     }     return    }    {code}    eliminating the need of implementing {{chainExists}} function.
Answer: 329247.0

User story: "Adjust the namespace/function to be separate by a :  rather than by an additional .         SDK changing in     https://jira.hyperledger.org/browse/FABN-940"
Answer: 482578.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: "This is where we ensure that the {{etcd/raft Chain}} maintains its own optimistic chain of blocks to be consented upon to pipeline the creation of (normal) blocks. Remember that ordering a Raft config message or a config block is a blocking operation -- no other blocks can ordered until these messages have been replicated by the cluster. Normal blocks can be ordered in a pipelined manner. See notes in C.II.5."
Answer: 105131.0

User story: I'm trying the following sample Fabric application from IBM on my Ubuntu 18.04 VM    [https://github.com/IBM/SecuringArt-using-Blockchain-DigitalCertificates]  it bombed out at the chaincode "instantiate" stage,     The "instantiate" of chaincode is being called via curl like below:  {quote}curl -s -X POST \    [http://localhost:4000/channels/mychannel/chaincodes] \    -H "authorization: Bearer $ORG1_TOKEN" \    -H "content-type: application/json" \    -d "{          \"chaincodeName\":\"mycc\",          \"chaincodeVersion\":\"v0\",          \"chaincodeType\": \"$LANGUAGE\",          \"args\":[\"a\",\"100\",\"b\",\"200\"]{quote}     The "docker logs -f [orderer.example.com|http://orderer.example.com/]" indicated the following:  "  0xc420d30440 identity 0 does not satisfy principal: the identity is a  member of a different MSP (expected Org1MSP, got Org2MSP)  2018-09-27 13:54:19.528 UTC [cauthdsl] func2 -> DEBU 402 0xc420d30440  principal evaluation fails  "   What caused this problem and how to fix it?     Thanks.         
Answer: 63149.0

User story: All of the JavaScript samples in the fabric-samples repository are under a "node" directory. This is problematic for two reasons:    1) JavaScript is the name of the programming language, and Node.js is the runtime for JavaScript chaincode. Developers will be looking for a sample that uses the programming language of their choice, so "javascript" is the more appropriate name for this sample.    2) Work has been done (and is still going on) to deliver first class support for TypeScript chaincode. TypeScript is a language that must be transpiled (compiled) down into JavaScript, and then it can be run on the same Node.js runtime as JavaScript chaincode. The directory name "node" is therefore vague, as it could apply to JavaScript or TypeScript chaincode.    This user story will rename all of the "node" sample directories to "javascript", to reflect the programming language that is used and also open the door for TypeScript samples to be delivered under a "typescript" directory in future user stories.
Answer: 443699.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: "This paragraph in the network topic is not correct:  {code:java}  It’s also worth noting that S5 can have different implementations on peer nodes P1 and P2 – so long as they implement the same smart contract interface. It means that in principle, S5 could be implemented in GOLANG on peer node P1, and JavaScript on peer node P2!{code}  Chaincodes must have the exact same fingerprint (hash) on each peer as the instantiated chaincode on the channel, otherwise invoke will fail with {color:#333333}error: chaincode fingerprint mismatch{color}.    https://hyperledger-fabric.readthedocs.io/en/latest/network/network.html#network-completed"
Answer: 92.0

User story: "Some Fabric samples contain outdated configuration keys that have no effect whatsoever, [even such that were introduced in v1.0-alpha|https://github.com/hyperledger/fabric-samples/blob/release-1.2/balance-transfer/artifacts/base.yaml#L21] and never got to v1.0 GA.    As a result, users that read these samples are mislead and sometimes even share with other users these configuration parameters which no longer exist, or have changed.    Ideally - all configuration of samples would be inspired by the [e2e_cli|https://github.com/hyperledger/fabric/tree/release-1.3/examples/e2e_cli] in the fabric core repository."
Answer: 696268.0

User story: "*TLDR* - Make all fabric samples that use SDK, use service discovery and *remove static configuration of peers/chaincodes/orderers from connection profile*.    Since v1.2 - Fabric peers can tell the SDK information regarding the existing peers in the channel, or which peers should be used to endorse a given chaincode.    Despite the fact that the node SDK can leverage this ability, the fabric samples aren't configured to take advantage of this, [and all peers are configured statically in the channel, and the chaincodes are also configured statically|https://github.com/hyperledger/fabric-samples/blob/release-1.2/balance-transfer/artifacts/network-config.yaml#L49-L94].    This leads to miseducation and misinformation as this isn't the optimal way of configuring the network.    Therefore we should:    * Completely remove all configuration of chaincodes from the network profile configuration of all samples that use SDKs.  * Completely remove all configuration of peers and orderers by channels from the network profile configuration of all samples that use SDKs.  * Configure the network profile of all samples that use SDKs to use *a single peer* and rely on service discovery.  "
Answer: 696274.0

User story: "Currently, not all fabric samples have anchor peer configuration.  As a result - users are unable to use private data (unless they endorse on all the peers and don't require acknowledgement from peers) and can't take advantage of service discovery.    We should add to all fabric samples, anchor peers configuration at the setup startup."
Answer: 31020.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: "After FAB-11928 moved the cid package down to the shim, the original code still exists at fabric/core/chaincode/lib/cid.  To make developers use the latest cid package, we need to remove the old duplicated code.  We also need to improve the documentation. The import path should be the new location.  https://github.com/hyperledger/fabric/tree/master/core/chaincode/shim/ext/cid#using-the-client-identity-chaincode-library  "
Answer: 198986.0

User story: "     In Current chaincode invoke progress, the user who invoke the chaincode  must sign for pb.Proposal then send it to endorsor peers. After the peers return ProposalResponse, the user need make signature again to send the Payload to orderer node.        I don't think this is good practise. I think we can just make one time signature to make the chaincode invoke request.  "
Answer: 705926.0

User story: "Currently, Fabric allows private data to be purged from the write set cache using a fixed value (BlockToLive). This is insufficient for use cases that need to be compliant with GDPR, where data must be deleted upon a subject's request."
Answer: 79000.0

User story: "# In a block event, producer sends only the content of actual block. With sideDB and private data, the actual block would contain only the hashes of key and value. As a result, if anyone wants to export the data out of blockchain using block event, they need to either query it or depend on the GetPrivateDataByRange() API.   # In the normal case, if we invoke a transaction and write something to the ledger, all the peers can listen to block event and get the read-write set so they know what got updated; however, in the sidedb case, even the peers that have access to the private collection cannot get anything from the block event. So in this case, if a collection includes \{A,B,C} peers and A submits transaction through nodejs API, how can B and C know what data is updated? As B and C’s client can no longer find this information out by listening to block events.     To solve the above two problems, we can make the peer send the pvtdata along with the block event for the collection members only. When a client registers for event, it can mention whether it is interested in receiving the pvtdata. If the interest is specified, the peer would perform the ACL (to check whether the client is the member of the collection) and accept the registration.     Note that we can allow use to configure this option via core.yaml. If a particular deployment does not want to export private data at all, it can be disabled via core.yaml"
Answer: 547105.0

User story: "Currently fabric only allows private data to be deleted based on block height (BlockToLive). This is insufficient for use cases that need to address GDPR, specifying when data needs to be purged in real time.    Also, BlockToLive is prone to DoS attacks by adversaries that submit transactions with the goal of creating sufficient number of blocks to quickly exceed the BlockToLive of their victims."
Answer: 707599.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: When debugging performance problems, it's very important to be able to get more granular times on when a peer is processing a block.    Currently, the only logging at the INFO level is when the peer commits a block.  To get more detail, we have to turn on debug logs which results in a TON of logs and makes debugging difficult.  My understanding is the states are at a high level:        * block arrival via gossip (and orderer if the peer is pulling directly from orderer?)   * when it starts to get processed   * when validation is complete   * when commit is complete to chain   * when commit is complete to statedb    And currently all that is logged is when commit is complete to chain.    Can we get a bit more detail at the INFO level.  Here's a couple of specific proposals:    1 - At info level, log the first time the block shows up at the peer via any method and whenever the peer is done with it.  Given that you are currently logging when the commit is complete to chain, that may be sufficient for an end state and you can just add block arrival.    2 - Keep a single info message per block to avoid overwhelming the info logs, but add more granularity to that log line.  Something like:   "Block 298: arrived at x (time), started processing y, completed validation z, committed to to chain, aa, committed to statedb bb"  Obviously this could get long, so you could limit the granularity down to arrival and commit to chain, or some smaller list.         I'm not filing this as a bug, but if it's an easy change, please port it back to 1.1.x and 1.2.x as many customers are still on these versions and are starting to debug performance issues.          
Answer: 101015.0

User story: "Enable prover peer grpc service.    Bind the setup of the prover peer functionality and of the grpc server to peer setup."
Answer: 166970.0

User story: "Implementation of prover peer signer using peer's local MSP (signing identity)."
Answer: 86781.0

User story: "A topic to describe the commercial paper application and data architecture"
Answer: 119652.0

User story: "This story adds a new capability (V1_4_FABTOKEN_EXPERIMENTAL) for token transaction."
Answer: 65375.0

User story: "The function to create composite keys is only available when an instance of the chanincode stub is available. However, there might be cases where computing a composite key is required while no instance of the chaincode stub is available. The function should be exported to make it possible to reuse this logic elsewhere."
Answer: 10125.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 ledger is increasingly being used in the validation/commit code path. The current known users of the ledger facility are  # the validator when it retrieves the LSCC entry to obtain the chaincode endorsement policy  # the state-based validator when it retrieves state-level metadata  # the MVCC checks that need to retrieve existing keys    In case of error, the user of the ledger facility must be able to distinguish between a non-deterministic error (e.g. an I/O error) and a deterministic one (e.g. the error returned in case GetPrivateData was invoked on a non-existent collection). This is necessary to ensure that the validator/committer path decides whether to simply mark the transaction as invalid in case of a deterministic error, or to halt processing on the channel in case of a non-deterministic one."
Answer: 714798.0

User story: "This item refers to the extension of BCCSP calls or the building of a separate BCCSP that would accommodate ZK-proofs/signature computation needs.     This would subsequently be used by Identity mixer and Token components to offer modularity at the level of underlying cryptographic primitives.     In this way substituting a software version of these operations with a hardware supported one would be possible, without modifying the ZK operations' consumers."
Answer: 716346.0

User story: "In order to use the Fabric metrics components (https://jira.hyperledger.org/browse/FAB-3389), each peer/orderer needs to include its unique peer/orderer name in the metric names it is reporting (e.g., channel0.peer0.org0.example.com.blockheight). Otherwise, metrics reported by different peers cannot be distinguished by the metrics server such as statsd. [~<USER> [~<USER>"
Answer: 125297.0

User story: "Due to the lack of existent samples that makes use of Fabric-SDK-Go, our goal is to provide an example that also includes a REST API to allow the integration of external applications.    The highlights of that sample will be:   * chaincodes in both Node.js and Go;   * a REST API developed in Go;   * a Web application as a front-end."
Answer: 717701.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 want to remove mspMap and related code defined in msp/mgmt/mgmt.go.    As stated in the comment referenced below, these were a temporary solution, and we can now replace them with the latest channel management code.    [https://github.com/hyperledger/fabric/blob/e188e533f88e0ba3009ac6870d824735efc720e2/msp/mgmt/mgmt.go#L49-L56]  {quote}// FIXME: AS SOON AS THE CHAIN MANAGEMENT CODE IS COMPLETE,   // THESE MAPS AND HELPSER FUNCTIONS SHOULD DISAPPEAR BECAUSE   // OWNERSHIP OF PER-CHAIN MSP MANAGERS WILL BE HANDLED BY IT;   // HOWEVER IN THE INTERIM, THESE HELPER FUNCTIONS ARE REQUIRED    var m sync.Mutex   var localMsp msp.MSP   var mspMap map[string]msp.MSPManager = make(map[string]msp.MSPManager)  {quote}  As I reported in FAB-11321 and FAB-11843, I improved the performance of my workload from 2,500 TPS up to 4,000 TPS by removing the mutex lock for mspMap.    I opened this issue based on [~<USER>'s advice.    [https://gerrit.hyperledger.org/r/c/26055/3/msp/mgmt/mgmt.go#52]"
Answer: 717915.0

User story: " # Cluster size (per channel): statically computed from consenter set   # Is_leader(per channel): if the current node is the raft leader (0 or 1)   # Leader changes (per channel): number of leader changes seen on this node   # Proposal failures (per channel): if {{Propose}} or {{ProposeConfChange}} fails, this is inc’ed   # Block number of latest committed block (per channel)   # Block number of latest snapshot (per channel)"
Answer: 229076.0

User story: "Committer/Ledger metrics of interest (including labels for grouping/filtering):    Block Height (Gauge)   - by channel    Block validation time (H)   - by channel    State validation time (H)   - by channel    Block storage commit time (H)   - by channel    State DB commit time (H)   - by channel    State DB Write lock time (H) - lower priority - think more about how this will be used   - by channel    State DB Write lock wait time (H) - lower priority - think more about how this will be used   - by channel    Transaction commit count (C)   - by channel   - by transaction type   - by chaincode   - by valid/invalidation code   - by num private data collections   - by private data available/missing    CouchDB API time (H) - note- also includes a count implicitly since it is a histogram.   - by channel   - by database   - by success/failure/timeout   - by API name"
Answer: 174278.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: Environment:  Hyperledger Fabric v 1.1.0    When we go to Fabric CLI command prompt ( docker exec -it cli bash ) when cli container has been created, and then issue invoke or query command, which peer/node are we at?  How can we find out which node/peer we are at?  (The "peer node" command does not seem to have a way to provide such vital info)    More importantly, when we are at Fabric CLI command prompt, *how do we create new folder and add files to chaincode base*?  For instance, if we choose -l (language) = node  For the first-network (byfn) under fabric-samples  for the chaincode, "mycc",  it's at the following path:  /opt/gopath/src/[github.com/chaincode/chaincode_example02/node/|http://www.google.com/url?q=http%3A%2F%2Fgithub.com%2Fchaincode%2Fchaincode_example02%2Fnode%2F&sa=D&sntz=1&usg=AFQjCNEf4xD1yyoTPEW0_OHXgQCPt76PuQ]    what if I want to create a new chaincode, "mycc2" and to create a new directory  called "chaincode_example03" under /opt/gopath/src/[github.com/chaincode/|http://www.google.com/url?q=http%3A%2F%2Fgithub.com%2Fchaincode%2F&sa=D&sntz=1&usg=AFQjCNEYf_uPuVQPkc4aO1RXzwOv4ZLi9w]  ?    under Fabric CLI command prompt we seem unable to use bash command(s) such as mkdir etc.  Other sdk do we have any flexible way to get them done?    Thanks.
Answer: 2893.0

User story: "I am trying to build Fabric on raspnerry pi, but I didn't find where I could build the fabric-javaenv image.  Is it a necessary image at all? If it is, how can we build it?"
Answer: 709437.0

User story: "Currently the PrioritySelector only provides two endorsers at a time (ExclusionFilter provides only one) and this is not enough information for some types of prioritization algorithms. For example, the Go SDK added a filter based on block height threshold (see FABG-755). This filter calculates the highest block height of the full set of endorsers and prioritizes the endorsers that are within a certain threshold of that block height."
Answer: 20170.0

User story: "This change takes advantage of key marshalling methods from FABG-427 to demonstrate how one can configure the SDK with a custom key store that stores SW keys as bytes."
Answer: 36.0

User story: The new lifecycle work will not be available in the 1.3 release and so the MetadataLifecycle capability must be decoupled with the "V1_3" application capability of a channel.
Answer: 178088.0

User story: "The application part of the sample"
Answer: 57845.0

User story: "Sub-tasks that do not have an assignee in this story are up for grabs for new contributors :)"
Answer: 653061.0

User story: "* TLS errors - minimally log TLS errors where possible  * Trace-level information for gRPC connections  * Cross component transaction tracing"
Answer: 50659.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'd like to replace map and Mutex in MSP mgmt code with sync.map and RWMutex for better performance. sync.map is a thread-safe version of map, and become available from Go 1.9.      Originally this patch was included in the change for [FAB-11321] (MSP cache optimization), but the original patch includes code that are not directly related to MSP cache.    Based on a review comment in https://gerrit.hyperledger.org/r/c/24797/4/msp/mgmt/mgmt.go  I split the original patch into two parts, and this JIRA issue is about the remaining part."
Answer: 11483.0

User story: "Short topic on transaction handlers"
Answer: 204367.0

User story: "This is a lower priority item that can be detached from the parent as a separate chore if needed.    The prover peer is responsible for handling a small number of different kinds of commands requests. In support of these, each command can have its own processor that manages validation, parsing, execution, and response.    We can choose to implement this in a middleware style invocation chain or as commands that encapsulate the request and use independently tested components.    Relates to: https://gerrit.hyperledger.org/r/c/25273/27/token/server/prover.go#54"
Answer: 734756.0

User story: "* Implement Contract class and stub API delegation framework   * Unit and Integration tests   * Documentation   * Tutorials"
Answer: 721354.0

User story: "Acceptance:  Chaincode client can pass pagesize and bookmark parameters to range, composite key, and rich query shim APIs in order to drive pagination."
Answer: 119939.0

User story: "Additional test rationalization and increase in coverage required.     * Move unit tests to be under each module    /cc   [~<USER>"
Answer: 527520.0

User story: "Proposals on updates to the stub api have been made.        - Update the 'clientindenity' accessor method so that this object is only created on demand, and not for every transaciton. Creating this object is a very expensive operation and if the contract implemetnation doesn't need it ... don't do it"
Answer: 575005.0

User story: "The py-sdk will target Python 3.6+ in order to take advantage of Type Hints and the newest improvements to Python. Support for Python2.7 will be removed as it is being deprecated in the greater Python community within the next 16 months."
Answer: 738938.0

User story: "Acceptance critieria:  Chaincode can set and get key-level endorsement policies."
Answer: 20451.0

User story: "Acceptance:  Chaincode client can pass pagesize and bookmark parameters to range, composite key, and rich query shim APIs in order to drive pagination."
Answer: 33631.0

User story: "Sample code moved to fabric-samples repository"
Answer: 74646.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: "Define the protobuf messages and services needed to allow a client to request the execution of specific *command*, (i.e.: request import, transfer, list tokens, and so on). The messages should guarantee the following properties:   * client request and prover peer response are authenticated    * prover peer response is cryptographically bound to the corresponding request. The link must be succinct and it should not be possible to derive from it the response's content.    As example of the available commands, an import request command will be defined as well."
Answer: 6120.0

User story: "The Python SDK has mention of the eventhub but with no capability. We should remove this and add support for the new delivery service."
Answer: 745847.0

User story: "Add test cases for:   * configuration with only users embedded in client configuration   * configuration with only users in orgs' msp directories"
Answer: 745905.0

User story: "*Acceptance*: A (simulated) client constructs a request to construct an redemption proof by   providing the identifier of tokens to be introduced into the system, and invokes   the peer API. The peer would need to construct the corresponding redemption proof and return it to the (simulated) client. Acceptance would require that the constructed proof matches the input parameters of the request."
Answer: 234579.0

User story: "*Acceptance*: A fabric client can be built to submit an “redemption proof” request to a peer. The peer validates the request and checks that the request's creator has the rights to submit that request. "
Answer: 122331.0

User story: "*Acceptance*: A (simulated) fabric client can be built to redeem a specific set of tokens. Validation assumes the input identities match the one of the transaction creator of input owners. If this is not the case, the transaction is rejected at validation time. If the inputs correspond to  outputs that have already been consumed, the transaction is rejected at commit time.      The ledger APIs can be used to retrieve the committed data. I can observe  inputs have been marked as spent."
Answer: 122917.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: *Acceptance*: A (simulated) client generates a "redeem tokens" transaction. Upon receiving this transaction, a committing peer redirects its processing to its FabToken specific validation & commit components.  The transaction is to be marked as valid during validation and invalid in the end of commit phase and will have no impact on the ledger state.    In more details, these are the points of entry:   * *Enabling FabToken Transaction Processor*: Customised transaction processors are setup with a call to *ledgermgmt.Initialize(...)*. This function is invoked in two places: *peer/peer.go* and *node/start.go*. In order to enable fabtoken transaction processing, those two entry points will be modified to include also *fabtoken.TxProcessor*.   * *Enabling FabToken Validation:* FabToken Validation is to be considered as a _statically compiled handler_, therefore a new method called *FabTokenValidation* will be added to *library.HandleLibray*. * *The new method will return an instance of *fabtoken.ValidationFactory*.
Answer: 120177.0

User story: "Here the client token library leverages the responses from the prover peer to create a token transaction for redemption that is submitted to the ordering service."
Answer: 261493.0

User story: "This refers to the implementation of signing identity local interfaces for the client to be able to actually sign a transaction using its long term fabric signing identity. Token client should be able to send requests to a prover peer and submit transactions to an orderer via real grpc client (instead of mocked local interface)         *Acceptance*: Token client is setup using a statically assigned MSP signing identity. Fabric client is able to sign messages (e.g., prover peer signedCommands, or Transactions) using this signing identity and send requests/transactions to prover peer and orderer."
Answer: 212119.0

User story: "{color:#333333}*Acceptance:* A client function (cwLib) takes as arguments the identifiers of tokens to be redeemed via a token redemption process. As a result the function would request from a peer to construct the corresponding token redemption proof. {color}    The redemption proof is returned to the client and the function will return successfully only if the returned issue proof is correctly computed."
Answer: 261520.0

User story: "All of the gRPC servers currently use the core/comm package to create gRPC servers.  The comm.GRPCServer does not currently expose the capability to add stream and unary interceptors which can be quite useful for tasks such as monitoring, auditing, auth checks, etc."
Answer: 5081.0

User story: "Add a script for executing interoperability tests in CI. These tests will be executed whenever merges from upstream jobs take place. Builds will only be published once these tests pass.    Use the @interop tag when executing these tests."
Answer: 8563.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: Run the PTE SVT daily test suite, [https://jenkins.hyperledger.org/view/fabric-test/job/fabric-test-daily-pte-master-x86_64/,] which includes some performance tests, in IKS cluster instead of in LF machine pool. The latter provides wildly fluctuating TPS test results over several days, and also produces intermittent test failures due to resource contention issues. Referring to the attachment "CI vs IKS", after running some tests for 5 days on both environments, it seems clear that a dedicated IKS cluster is more stable with less variability in the TPS results. There may be additional factors influencing the test results even in the IKS cluster, since it does not give perfectly consistent results, which we can troubleshoot further as we strive for more stable consistent performance test results.    We may wish to consider in future to move other jobs as well to the IKS environment, especially performance tests.    This story involves several tasks, such as: setting up a dedicated IKS cluster solely for this purpose, sharing the kubeconfig with the job, altering the job to use the IKS cluster instead of allocation a VM from LF pool, running the PTE tests using ATD in the network (instead of PTE running NL itself for each testcase), and possibly modifying testcases to run in the new environment.     
Answer: 501241.0

User story: "Acceptance criteria:    # User edits {{configtx.yaml}} so as to have a network with a single-node etcd/raft-based ordering service and a system channel that is also an application channel. Assume {{BatchSize}} is set to 1.   # User launches single-node etcd/raft-based ordering service.   # User invokes the Broadcast RPC to submit a channel creation request (for, say. channel {{foo}}). User immediately receives a SUCCESS response.  # User invokes the Deliver RPC on channel {{foo}} and receives its genesis block.  # User restarts the OSN and repeats the previous step with the same result."
Answer: 228819.0