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: "In v1.4.0 there is a regression caused by [https://gerrit.hyperledger.org/r/27558] where the error caused by connection failure to CouchDB does not get handled. This leads to a nil pointer panic when the nil vdbProvider tries to get a handle to a database:       {code:java}  panic: runtime error: invalid memory address or nil pointer dereference  [signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x482af8f]  goroutine 1 [running]:  github.com/hyperledger/fabric/core/ledger/kvledger.(*Provider).openInternal(0xc00015a680, 0xc000218ac0, 0x3, 0xc0002ed001, 0x0, 0x0, 0x402ca32)   /Users/<USER>work/src/github.com/hyperledger/fabric/core/ledger/kvledger/kv_ledger_provider.go:158 +0x1ef  github.com/hyperledger/fabric/core/ledger/kvledger.(*Provider).Open(0xc00015a680, 0xc000218ac0, 0x3, 0x3, 0x5948c40, 0x0, 0x1)   /Users/<USER>work/src/github.com/hyperledger/fabric/core/ledger/kvledger/kv_ledger_provider.go:145 +0x116  github.com/hyperledger/fabric/core/ledger/ledgermgmt.OpenLedger(0xc000218ac0, 0x3, 0x0, 0x0, 0x0, 0x0)   /Users/<USER>work/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:122 +0x19b  {code}       This change will handle the CouchDB connection error gracefully and panic the peer with a good error message (e.g. connection problem, username/password problem) as was done in prior releases.          "
Answer: 26032.0

User story: "Acceptance:    An end-to-end test against a solo network and Golang chaincode can be executed without docker. In particular, the chaincode binary is compiled for the host platform, the peer that is launched points to a custom no-op builder, and the launcher simply executes the chaincode with the correct flags and environment variables."
Answer: 321315.0

User story: "Acceptance:    I can place a {{launch}} script in the peer's local file system next to {{detect}} and {{build}}. If present and {{detect}} and {{build}} have been successful, call the {{launch}} script with the following arguments: the path to the build directory populated by the {{build}} script and a path to a JSON file that contains chaincode metadata.    The chaincode metadata should minimally contain key/value pairs for the pem encoded keys and certificates necessary to launch chaincode, a pointer to the chaincode server address required for registration, and the chaincode ID/name."
Answer: 213498.0

User story: "Acceptance:    I can drop a {{build}} script the peer's local file system next to the {{detect}} script. When the {{detect}} script  exits successfully, the {{build}} script will be called. The arguments to the build script should be the extracted contents of the chaincode package, a directory to place chaincode metadata for the peer (ie. CouchDB index files), and a directory to place assets that may be needed to launch chaincode.    If the {{build}} script exits abnormally, the build process has failed."
Answer: 213503.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:    I can add keys to {{core.yaml}} that point to a path in the peer's local file system that contains a {{detect}} binary. If it exits, it is called prior to building chaincode. No further action is required.    System chaincode never uses the external launcher."
Answer: 213508.0

User story: "When checkpoint is enabled with a capability flag, latest channel config will need to be re-written to state database in a deterministic way across peers. The existing channel config at key resourcesconfigtx.CHANNEL_CONFIG_KEY may not have it's content saved in a deterministic order, due to maps not getting saved in a deterministic order during protobuf  marshaling. One approach is to take the Config directly from the ConfigEnvelope as produced by orderer, without unmarshaling and re-marshaling in each peer. Sample code for this approach can be found at https://gerrit.hyperledger.org/r/#/c/29766/."
Answer: 466721.0

User story: "Currently, token e2e tests only the case when double spending transactions are in different blocks.         Idea: Create a network where MaxMessageCount = 2 and BatchTime is large (30 seconds?). Then submit double spending transaction within the same block."
Answer: 467288.0

User story: "The chaincode provider no longer requires an Execute function"
Answer: 47801.0

User story: "The chaincode provider no longer requires an Execute function"
Answer: 291.0

User story: "createChain does not require a chaincode provider"
Answer: 315.0

User story: "Currently, verifier uses createTokenKey which calls createCompositeKey to build tokenKeys during action validation and commit. createCompositeKey internally validates the input and throws an error in case it can not create a valid CompositeKey.     However, for most transactions, tokenKeys are generated multiple times, first, during validation (check action path), and then again during commit. This looks like unnecessary extra work. In particular, avoiding string concatenation may improve performance.    Also, it seems that during commit the error handling of createTokenKey is never uses, as in presents of an invalid input, it is caught already during check action path.     Proposal: Create tokenKeys during validation and pass them into the commit path of the verify to avoid unnecessary re-creation of the keys including validation.      "
Answer: 472666.0

User story: "Update dockerfile to run chaincode container  as non-root"
Answer: 398883.0

User story: "- protos for issue, transfer, redeem and list"
Answer: 459452.0

User story: "As we move away from having chaincode installed locally, and even with local chaincodes, it doesn't make a tremendous amount of sense that hash is included in the chaincode definition.  If a peer is dishonest, they may run arbitrary code, and if the peer is honest, then they will be running the correct code in any event.  It really only prevents accidental mis-matches of code packages across the network, which should also be caught by endorsement policy checking."
Answer: 50956.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: "Go 1.12 is out."
Answer: 142472.0

User story: "Each of the command line tools that we ship in support of fabric should be moved to cmd/${tool name}.     Most of these exist in common/tools and should updated to have their main functions moved to cmd/${tool name}/main.go. The main should handle flag processing and then call supporting code as necessary. The main test (if present) should also be moved with the main.    The supporting code (other than the main) that lives in common/tools should be moved to internal/${tool name}. At some point, some of the code may move again but let's start there.    At first glance, this looks like configtxgen, cryptogen, and configtxlator."
Answer: 9841.0

User story: "This story aims at providing an e2e flow, not considering the client SDK or the client cli, to allow the client list their non-fungible tokens. This includes:    * The definition of the protobuf messages  * An update of the client API together with the prover peer's  * An update of the transactor  * The implementation of e2e tests"
Answer: 463735.0

User story: "This story aims at providing an e2e flow, not considering the client SDK or the client cli, to allow the client to redeem their non-fungible tokens. This includes:    * The definition of the protobuf messages  * An update of the client API together with the prover peer's  * An update of the transactor and the verifier  * The implementation of e2e tests"
Answer: 463735.0

User story: "This story aims at providing an e2e flow, not considering the client SDK or the client cli, to allow the client to transfer their non-fungible tokens. This includes:    * The definition of the protobuf messages  * An update of the client API together with the prover peer's  * An update of the transactor and the verifier  * The implementation of e2e tests    "
Answer: 477167.0

User story: "This story aims at providing an e2e flow, not considering the client SDK or the client cli, to allow the client to issue non-fungible tokens. This includes:    * The definition of the protobuf messages  * An update of the client API together with the prover peer's   *  An update of the issuer and the verifier   * The implementation of e2e tests"
Answer: 463737.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 where there is an error... for example if the chaincode is already installed on the peer or if the policy isn't allowing user to submit a transaction, etc because if insufficient signatures... we get a sting with a reason. But the issue is that string keeps changing between different versions. We can't reliably look for the response and give the user a proper error message. This is also an issue with translation.         If could be good to get a list of error codes and what they mean so that we can use that reliably."
Answer: 1120.0

User story: "Administrative ability to rollback a channel's ledger on a peer to a prior block height in the case the channel gets into a corrupt state at a later block height. During the rollback, need to preserve private data since it cannot be obtained from ordering service at a later time.    Design Doc: [https://docs.google.com/document/d/1_-e4Bu42E9vfdttrYBmiSUeOdanH2SiSnuhM1oOn1TA/edit] "
Answer: 558634.0

User story: "1. The log msg should support multiple languages."
Answer: 481832.0

User story: "- Remove V1_4_FABTOKEN_EXPERIMENTAL capability since it was not used in v1.4 .     - Enable FabToken feature when V2_0 capability is enabled"
Answer: 10053.0

User story: "Currently fabtoken supports uint64 type for quantity. In certain use-cases this poses a limit.     This story proposes to enhance fabtoken to be able to handle arbitrary precision numbers, precision that can be customised during initialisation of fabtoken (via lifyccile).    The quantity field will be converted from uint64 to string. Supported encodings will be all provided by [https://golang.org/pkg/math/big/#Int.SetString.] Therefore, a client invoking the prover peer to assemble a token transaction, can use any format supported by [https://golang.org/pkg/math/big/#Int.SetString.] The prover peer will use the hex representation to represent quantities in the token transaction. Though, quantities in token transactions can be represented by using any format supported by [https://golang.org/pkg/math/big/#Int.SetString.]    This is also the approach used by Ethereum.     "
Answer: 7200.0

User story: "The implementation of the deployed cc info interface currently does not distinguish I/O error from deterministic errors. This story tracks the necessary work to review that code, determine if any error conditions may lead to a fork or similar undesired behaviour and fix the code."
Answer: 73443.0

User story: "We need a mechanism to specify some configuration for chaincode server:   # TLS properties (enabled or not, certificate and key files)   # Root CAs of clients (peers)   # Logging properties   # Others?    We will keep these configuration in a `yaml` file, which is read by the chaincode shim upon start up. "
Answer: 422644.0

User story: "As a user of Fabric 1.4, LTS, I'd like to benefit from the Kafka health checks introduced into the master branch."
Answer: 14872.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: "Before committing any token transaction, the output's owner must be validated. For an MSP Identity that means that there exist an MSP in the channel that can deserialise and validate it."
Answer: 4797.0

User story: The fabric-ca-peer and fabric-ca-orderer images no longer exist. The desire is that we use the fabric-peer and fabric-orderer images and then use the fabric-ca-client binary as a "helper binary" similar to how cryptogen and configtxgen are used.
Answer: 502880.0

User story: "The chaincodes that were in the fabric/examples directory in the Hyperledger Fabric repo were removed. These chaincodes were used in much of the testing in fabric-test. As a result, the chaincodes should be moved to the fabric-test repo."
Answer: 502930.0

User story: The chaincode will run as a server when "chaincode.servermode" property is set to true.    *Phase 1 - use existing single-stream protocol*  On receiving a connection it will launch into the old "chaincode as client" protocol flow on the established stream.    *Phase 2 - Invoke as a separate RPC call*  Each invoke will be a separate RPC call. This has advantages of simplicity and improved performance. However this is more disruptive from code change and refactoring point of view.    The two phases should be seamless for devops or enduser. Phase 2 can be done later once phase 1 proves out the "chaincode as server" concept. 
Answer: 722742.0

User story: "Using the peer admin API, provide CLI to configure chaincode endpoints for a set of peers"
Answer: 430645.0

User story: "Pending PoC with LB whether we need connection pool or not? It looks like Envoy and Linkerd might load balance if we do multiple rpc call over a connection."
Answer: 430652.0

User story: "The install optionally doesn't need the chaincode source package. We need to modify the code to detect and process this chaincode as the 2.0 chaincode model."
Answer: 430687.0

User story: We need to configure peer with the info about the "external" chaincode, including its name, endpoint address, and root CA if using TLS. The chaincode 2.0 lifecycle model provides a good framework for a workflow to fit seamlessly with deployment model needed for deploying external chaincodes.    External chaincode will be treated as a new "Type" of chaincode called "external" (other types are "golang", "java", "node" and "system" as defined in the Fabric's proto definitions. In the chaincode lifecycle 2.0 workflow, a chaincode is packaged with other metadata in a targz file. The external chaincode is specified just as a "yaml" file with endpoint information including address and CA cert (used if TLS enabled). There is no other change to the chaincode lifecycle 2.0 workflow. 
Answer: 430715.0

User story: "- Back port the Metadata generate command    Ensure that the directory is created if it doesn't exist    Ensure that the path to the file can be either relative or absolute"
Answer: 322379.0

User story: "This task is to test that a transfer to a invalid owner or amount should be rejected."
Answer: 31463.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 goal of this story is to check that Alice cannot spend Bob's tokens"
Answer: 10390.0

User story: "If a request to a prover peer generates a panic, this will crash the peer. To goal of this story is to add panic resistance."
Answer: 8910.0

User story: "The goal is to have an e2e to test double-spending"
Answer: 30421.0

User story: "As a fabric consumer, I expect the protos packages to include externally consumable artifacts yet the protos packages contain a collection of generated code, utilities, and extensions to proto objects.    Let's begin to clean this up by moving protos/utils to protoutils"
Answer: 59005.0

User story: "The documentation for protocol buffers includes a wonderful note:    {quote}  Protocol Buffers and O-O Design    Protocol buffer classes are basically dumb data holders (like structs in C); they don't make good first class citizens in an object model. If you want to add richer behaviour to a generated class, the best way to do this is to wrap the generated protocol buffer class in an application-specific class. Wrapping protocol buffers is also a good idea if you don't have control over the design of the .proto file (if, say, you're reusing one from another project). In that case, you can use the wrapper class to craft an interface better suited to the unique environment of your application: hiding some data and methods, exposing convenience functions, etc. You should never add behaviour to the generated classes by inheriting from them. This will break internal mechanisms and is not good object-oriented practice anyway.  {quote}    With respect to that note, we violate it many times and in many ways in the following files:    {code}  protos/common/block.go  protos/common/block_test.go  protos/common/common.go  protos/common/common_test.go  protos/common/configtx.go  protos/common/configtx_test.go  protos/common/configuration.go  protos/common/configuration_test.go  protos/common/ledger_test.go  protos/common/policies.go  protos/common/policies_test.go  protos/common/signed_data.go  protos/common/signed_data_test.go  protos/discovery/extensions.go  protos/discovery/extensions_test.go  protos/gossip/compatibility_test.go  protos/gossip/extensions.go  protos/gossip/extensions_test.go  protos/gossip/message_test.go  protos/ledger/rwset/kvrwset/helper.go  protos/ledger/rwset/kvrwset/tests/kv_rwset_test.go  protos/ledger/rwset/rwset.go  protos/ledger/rwset/rwset_test.go  protos/ledger/rwset/tests/rwset_test.go  protos/msp/msp_config.go  protos/msp/msp_principal.go  protos/orderer/configuration.go  protos/orderer/etcdraft/configuration.go  protos/orderer/etcdraft/configuration_test.go  protos/peer/chaincode.go  protos/peer/chaincodeunmarshall.go  protos/peer/configuration.go  protos/peer/proposal.go  protos/peer/proposal_response.go  protos/peer/transaction.go  protos/testutils/txtestutils.go  {code}"
Answer: 59038.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 a fabric consumer, I expect the protos packages to include externally consumable artifacts yet the protos packages contain a collection of generated code, utilities, and extensions to proto objects.    Let's begin to clean this up by moving protos/utils to protoutils"
Answer: 43363.0

User story: "Token protobufs need some love.    For instance, in PlainSwapIntention, comments are not correct and variable token_type is used whereas everywhere else we use just type.    Also protobuf related should be fixed, for instance, use proto.Equal instead of deepEqual when testing proto messages."
Answer: 58891.0

User story: "The MemoryPool was used for testing purposes but it has been replaced by mocks."
Answer: 1549.0

User story: Currently, the token ledger namespace is set to *tms*. To goal of this story is to make it more readable and rename it to *fabtoken*.    The system must ensure that no chaincode can be deployed with that name.    LSCC is responsible to check if a chaincode name is valid or not.     Ideas:   # -add chaincode.name == "fabtoken" to lscc. Would be better to access const namespace located in token.namespace but this introduces an import to lscc. Bad idea.-   # -More general, add a method like isReservedName(chaincode.name)bool that is called when a new chaincode is deployed. lscc can maintain a list of reserved chaincode names.-    # -We can introduce a system chaincode called fabtoken. Maybe this sys chaincode can also be used to enable/disable token functionality at a peer?!-   # Instead of using "fabtoken" we can use an invalid chaincode name, such as "_fabtoken". That way we do not get a namespace conflict, however, maybe this violates namespace conventions         Solution: Use reserved namespace FAB-11308. Reserved namespaces are denoted with "_" prefix, for example "_lifecycle". See [FAB-13850|https://gerrit.hyperledger.org/r/#/c/28931/]
Answer: 11713.0

User story: "InvalidTxError errors are used at committing time to signal that a transaction should be marked as invalid. If these errors are not propagated then the committer treats them as fatal errors.    Currently, FabToken Tx Processor does not propagate InvalidTxError. "
Answer: 1736.0

User story: "Currently, the token transaction processor adds always a key prefixed with *tokenTx* to check for transaction uniqueness. This is not needed cause this check is already performed at validation time."
Answer: 14573.0

User story: "Currently, the owner field is meant to contain a serialised MSP identity. In the future, we will support additional type of identities like a chiancode identity or MSP Owner Identifier.     The goal of this story is to introduce an additional data structure to describe the different types of identities an owner field can contain"
Answer: 33216.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 basic use-case is:     GPG encrypts the file once with a symmetric key, then places a header identifying the target keypair and an encrypted version of the symmetric key.    When encrypted to multiple recipients, this header is placed multiple times providing a *uniquely encrypted version of the same symmetric key for each recipient*."
Answer: 517054.0

User story: "Fabric currently uses the fsouza, 3rd party Docker client. At the time of vendoring, this was the mainstream Docker client for Go. There is now an official Docker Client for Go, and the fsouza repo now states you should use this moving forward, as the fsouza client will no longer guarantee support for Docker updates."
Answer: 84834.0

User story: "The current version of 1.11 is 1.11.5 and includes security related fixes for crypto/elliptic.    We need to bump the version of go that we build with in fabric, fabric ca, our docker images, and all of the other miscellaneous places - including our build environments in CI."
Answer: 38847.0

User story: "The current version of 1.11 is 1.11.5 and includes security related fixes for crypto/elliptic.    We need to bump the version of go that we build with in fabric, fabric ca, our docker images, and all of the other miscellaneous places - including our build environments in CI."
Answer: 36658.0

User story: "[~<USER> implemented the gRPC health check service in the peer as part of  FAB-12909 (Add HealthCheck service to GRPCServer). This provides a way for a gRPC client to determine a server is available and, for registered services, whether or not they're active.    Then, on top of that, a HealthChecker was implemented in the peer that would use the gRPC healcheck client to loopback dial the gRPC server for health checks. While, in concept a good thing, in practice there are a number of ways that this could be problematic.    We should either remove the health check client that is registered with the server or introduce configuration mechanisms that allow us to determine if we want it on or off."
Answer: 26727.0

User story: "Provide service discovery functionality using chaincodes installed / approved / committed via _lifecycle. "
Answer: 183956.0

User story: "* The car ID scheme is a bit unusual (you'd never see it in a real life application) and it is non-trivial to sort (CAR1... CAR999)  * Querying all cars is not really best practice (no pagination, assumes maximum car ID of CAR999)  * Creating a new car does not check to see if the car already exists"
Answer: 523441.0

User story: "Example02 plays a prominent role in our documentation and tutorials. However, its name is historical and meaningless, and with the cleanup of fabric/examples looks very odd on its own.    Renaming it to something like ABstore would better convey what it does."
Answer: 195912.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 trying to download fabric-ca using *go get* tool, we get the following error:  {noformat}  github.com/hyperledger/fabric-ca/lib  /opt/gopath/src/github.com/hyperledger/fabric-ca/lib/server.go:719:23: cert.Issuer.String undefined (type pkix.Name has no field or method String)  /opt/gopath/src/github.com/hyperledger/fabric-ca/lib/server.go:720:24: cert.Subject.String undefined (type pkix.Name has no field or method String)  {noformat}  Our current *go env* is set as:  {noformat}  GOARCH="amd64"  GOBIN=""  GOCACHE="/home/ci/.cache/go-build"  GOEXE=""  GOFLAGS=""  GOHOSTARCH="amd64"  GOHOSTOS="linux"  GOOS="linux"  GOPATH="/opt/gopath/"  GOPROXY=""  GORACE=""  GOROOT="/usr/local/go"  GOTMPDIR=""  GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"  GCCGO="gccgo"  CC="gcc"  CXX="g++"  CGO_ENABLED="1"  GOMOD=""  CGO_CFLAGS="-g -O2"  CGO_CPPFLAGS=""  CGO_CXXFLAGS="-g -O2"  CGO_FFLAGS="-g -O2"  CGO_LDFLAGS="-g -O2"  PKG_CONFIG="pkg-config"  GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build151124065=/tmp/go-build -gno-record-gcc-switches"  {noformat}
Answer: 250393.0

User story: "This Story belongs to all the build artifacts we publish from fabric repository.   * fabric docker images   ** to docker hub   ** to Nexus3   * fabric binaries   ** to nexus2"
Answer: 411634.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: "Raft FSM is single-threaded, and the Raft leader periodically sends heartbeats to the followers.   Currently - the Step RPC is not a stream, so it means that if the number of nodes is *n* and the RTT time is *T*, then each heart beat cycle takes at least *(n-1)xT*  which might easily balloon to be above the threshold that the followers can tolerate, and as a result - the followers would stop following the leader over and over and the cluster would get into an unrecoverable spin - imagine that if we have 10 nodes, then the leader has 9 followers and the last follower currently waits above 8*T*  time to receive a heartbeat from the start of the heartbeat cycle.  Had it been a stream - it'd wait only *T* time.  {code:java}  # HeartbeatTick is the number of Node.Tick invocations that must  # pass between heartbeats. That is, a leader sends heartbeat  # messages to maintain its leadership every HeartbeatTick ticks.  HeartbeatTick: 1  # ElectionTick is the number of Node.Tick invocations that must pass  # between elections. That is, if a follower does not receive any  # message from the leader of current term before ElectionTick has  # elapsed, it will become candidate and start an election.  # ElectionTick must be greater than HeartbeatTick.  ElectionTick: 10{code}    I recommend the following:  # Make the cluster Step - a stream (now it's an RPC): We don't use the return value from the Step RPC (the Raft FSM sends messages one way and doesn't expect a synchronous response) anyway so there is no point in waiting for any response from the remote OSN.   If Step would be a stream, then the message sending would be asynchronous and as a result a heart beat cycle would finish very quickly.  # Make the T {{HeartbeatTick}} number something more sane than 1. Currently, the tick interval is set to 100ms, and the leader sends the followers a heart-beat once per 100ms. I think it's way too harsh for production environments and we should make the leader tick once in 5 seconds, and the  \{{ElectionTick}} should be something like 15 seconds.  I know the leader failover would be slower, but I am a bit uneasy about releasing a default with timeouts that are not lenient. I think we could always document that to make the failover fast, one can make a config update and reduce these times.         Please chime in - [~<USER> [~<USER> [~<USER> [~tock]"
Answer: 14292.0

User story: "Ensure that data is marshalled from the incoming data to the appropriate types based on how the metadata is coded. "
Answer: 202898.0

User story: "As part of the contract, make metadata available as per the adopted standard."
Answer: 170976.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 a developer of contracts, I need to be able to get access to the the 'transactional context' that the current method is operating in.    This will give access to the stub and other APIs.           Node.js passes this is as the first parameter to any function. Consideration that within Java to help with thread-safety perhaps the instance of the object should be created per transaction.    Saftey vs Performance"
Answer: 113514.0

User story: "The {{fabric-lib-go}} repository needs to have build scripts or a makefile added that can be used to test and validate change requests."
Answer: 123716.0

User story: "The {{fabric-lib-go}} project exists in Gerrit but is not associated with a Jenkins build. A build needs to be defined that is triggered on Gerrit CRs."
Answer: 171477.0

User story: "Pprof is useful to analyze performance issues inside of Fabric. To enable pprof, currently we need to restart a peer or an orderer since pprof is configured by a yaml file or an environment variable only at the start up time.    But inside of the Go language runtime library, pprof is always enabled. The flag profile.enabled just spawns a goroutine to handle REST API requests to control profiling and export results.    Dynamic control via a peer CLI command (like the logging control) allows us to collect profiles of the target peer without restarting it, and also minimizes exposure of the port 6060."
Answer: 431.0

User story: principalBytes, err := proto.Marshal(&m.MSPRole\{Role: m.MSPRole_CLIENT, MspIdentifier: msp.name})  if err != nil {       return errors.Wrapf(err, "failed creating MSPRole_CLIENT")   }  // we constructed a valid object. No need to check for error, so delete check  principalBytes, _ := proto.Marshal(&m.MSPRole\{Role: m.MSPRole_CLIENT, MspIdentifier: msp.name})
Answer: 530849.0

User story: if channelConfig is nil, persistConf already return err:      proto: Marshal called with nil  so below code no chance to compare      if channelConfig == nil {          return fmt.Errorf("Channel config found nil")      }  i think this code should be delete, but if not, move to before persistConf
Answer: 1651.0

User story: "The ability to build fabric-ca-* images was removed from the fabric-ca repository. These images were being used when performing tests that used fabric-ca. These tests currently use the CLI, sdk-node, and sdk-java. In order to execute true interoperability tests to ensure consistency, these images are needed.     The fabric-ca sample has also been moved to fabric-test. There are a couple of scenarios that are only tested when this sample is executed. Until this sample has been transposed into proper tests for these particular cases, this sample should continue to exist as it has caught errors at times in the past. The sample can be removed when there is better test coverage for fabric-ca and fabric interoperability."
Answer: 31371.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 existing devenv is a mess. It's cluttered with a bunch of legacy that's no longer relevant to what we build.    Let's simplify what's there and bring it up to date with the current patterns."
Answer: 5119.0

User story: "{color:#569cd6}ledger{color}{color:#d4d4d4}:{color}  {color:#569cd6} pvtdataStore{color}{color:#d4d4d4}:{color}  {color:#d4d4d4}    {color}{color:#6a9955}# the maximum db batch size for converting{color}  {color:#d4d4d4}    {color}{color:#6a9955}# the ineligible missing data entries to eligible missing data entries{color}  {color:#d4d4d4}    {color}{color:#569cd6}collElgProcMaxDbBatchSize{color}{color:#d4d4d4}: {color}{color:#b5cea8}5000{color}  {color:#d4d4d4}    {color}{color:#6a9955}# the minimum duration (in milliseconds) between writing{color}  {color:#d4d4d4}    {color}{color:#6a9955}# two consecutive db batches for converting the ineligible missing data entries to eligible missing data entries{color}  {color:#d4d4d4}    {color}{color:#569cd6}collElgProcDbBatchesInterval{color}{color:#d4d4d4}: {color}{color:#b5cea8}1000{color}"
Answer: 7326.0

User story: Currently, the CLI/chaincode containers have Golang version 1.10    From version 1.11 onwards, Golang supports the use of "Go Modules" which makes dependency package management much simpler and also eliminates the restriction of setting GOPATH.     Go Modules: [https://github.com/golang/go/wiki/Modules]    Thoughts?     
Answer: 660594.0

User story: on windows run go env, show like:    PS C:\Users\laoshu> go env  set GOARCH=amd64  set GOBIN=  set GOCACHE=C:\Users\laoshu\AppData\Local\go-build  set GOEXE=.exe  set GOFLAGS=  set GOHOSTARCH=amd64  set GOHOSTOS=windows  set GOOS=windows    so need to TrimPrefix "set "      
Answer: 1916.0

User story: "A comment was added to the handler method a few months ago.    {code}  // Deprecated: Please note the issues described in the doc comment of  // InstrumentHandler. You might want to consider using promhttp.Handler instead.  {code}    So, switch to the new handler method."
Answer: 4159.0

User story: "The initial CLI with an example command should be implemented to provide a structural skeleton for the project.   The focus is to design a workflow regardless of the contents of a command.  Commands should be treated equally.         Configuration details should be stored in the local file system.  By default a “.fab” directory should be created at the user’s home directory.  An option should be made available to override this default.         Scripts will be needed to lint, build, and test. "
Answer: 126642.0

User story: "This story contains all tasks related to the refactoring and new code necessary to enable chaincode lifecycle v2 in the validator component of the fabric peer"
Answer: 170134.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: "Tokens in Fabric represents the assets that can be exchanged in an atomic fashion via Fabric transactions. Tokens in Fabric represents the assets that can be exchanged in an atomic fashion via Fabric transactions. Tokens are assigned to a Fabric network using an issue operation. From the moment token issuing takes place, new tokens are generated to represent the associated assets in Fabric network. Ownership of these tokens can be changed throughout Fabric transactions. The assets (tokens) themselves remain under the custody of Fabric network until when their owner claims the associated assets back via a redeem operation.      SDK needs to be enhanced to support tokens so that applications can call SDK API to perform the following token operations.   * issue: creates new tokens to the specified users   * transfer: transfers tokens from one user to other users   * redeem: redeems existing tokens owned by the user   * approve: authorizes to transfer owning tokens to other users   * transfer from: transfers tokens that have been approved by the owner   * swap: transfers tokens among multiple participants   * list: lists unspent tokens owned by the user   * allowance: amount of tokens approved by the owner that can be transferred to other users         To implement the above APIs, SDK needs to perform the following:   # Communicate to a prover peer (via token.ProverClient grpc client) to get back a token transaction for each token operation mentioned above   # Create a transaction envelope for the token transaction (common.HeaderType_TOKEN_TRANSACTION type) and broadcast it to the orderer   # Allow the application to register for the transaction event      A token client package has been implemented in go that are used to test e2e token scenarios. This package can be used as a reference implementationfor SDK.  For more details of the token client package, refer to token-client-design.docx under the epic story FAB-11153 and CR https://gerrit.hyperledger.org/r/#/c/27631/ (see token/client and integration/token)"
Answer: 410080.0

User story: "since ledgermgmt.Initialize has been invoked in node start serve function, there is no need to call again in peer Initialize function, and this change make code more clearly"
Answer: 215951.0

User story: This is where add all system verification tests (SVT) involving the etcd/raft-based ordering service.    A few guidelines:    # We'll be adding a sub-task per test.  # We'll use the "Description" field in the sub-task to describe the test's setup, inputs, and expected outputs in detail.  # We'll avoid acronyms as much as possible, and go with descriptions in plain english.  # We'll keep logs of both successful and unsuccessful runs around.    Anything that applies to all system verification tests should be recorded in _this_ story.
Answer: 7664.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: Retrieving the chaincode ID is a little involved today and requires   digging through signed proposal, specifically, looking at the   ChaincodeHeaderExtension within the proposal's header.    Further, retrieving this chaincode ID can be counter-intutive to   what a programmer would expect when the current chaincode was called   by another. In this case, the chaincode ID is the ID of the calling   chaincode, not the callee (current) chaincode.    This issue proposes adding a new method to the   ChaincodeStubInterface that will simplify the process of retrieving   the current or calling chaincode's ID.    Proposed methods to ChaincodeStubInterface:    // GetChaincodeID returns a sequence of chaincode IDs from the "chaincode-call-stack".   // For instance, give an invoke sequence ChaincodeA->ChaincodeB->ChaincodeC   // this function will return []string\{ChaincodeA, ChaincodeB, ChaincodeC}.   GetChaincodeID() []string    In the case of a direct call, the function above would return a   slice with just one element containing the ID of the executing   chaincode. In the case of a series of calls, the function would   return a slice of strings of chaincode IDs in the order in which the   chaincode-to-chaincode invocation happened.
Answer: 545421.0

User story: Add "memberOnlyWrite" support for collections.    Implicit org-specific collections would utilize memberOnlyWrite=true.    Validation needs to enforce (coordinate with [~<USER> )
Answer: 525046.0

User story: "Currently, when an OSN starts up, for each chain it doesn't participate in - it registers into an object that periodically tracks whether it is added to the channel, and starts an inactive.Chain which returns service unavailable to every request.    If the OSN detects its own addition to the channel, it pulls the blocks, and then starts the etcdraft chain, after which it replaces the chain instance of the inactive.Chain.    However, if the OSN is removed from the channel afterwards - it simply halts its chain operation when it detects its eviction from the channel.     If it is re-added afterwards into the channel, it won't know that and won't re-activate the chain.  The only way to make it re-activate the chain is restart the OSN.     In order to make this work without user intervention (i.e - restart), we need to pass the registration callback from the consenter into the etcdrart chain instance, which would make the chain register itself in the tracker object when the membership eviction is detected.       I personally don't think this is a very pressing matter to attend to in the short term, but we should keep it in the backlog for now and take care of it when we have the time.    opinions? [~<USER> [~<USER> [~<USER> [~tock]"
Answer: 446544.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: 1.Chaincode instantiate - add this may take a few minutes to complete.    2. Change  This is because it additionally submits an instantiate transaction to the orderer, which will include the transaction in the next block and distribute it to all peers that have joined mychannel, enabling any peer to execute the chaincode in their own isolated chaincode container.  To  This is because it additionally submits an instantiate transaction to the orderer, which will include the transaction in the next block and distribute the chaincode  to all peers that have joined mychannel, enabling any peer to execute the chaincode in their own isolated chaincode container.     3. Change:  Note that instantiate only needs to be issued once for papercontract even though typically it is installed on many peers.  To  Note that instantiate only needs to be issued once for papercontract on a channel even though typically it would have already been installed on all the peers that will run it.    4. networkConnection.yaml contains a reference to Hyperledger Composer ../gateway/networkConnection.yaml  # the "x-type" property with the "hlfv1" value example below is used by Hyperledger Composer to  # determine the type of Fabric networks (v0.6 vs. v1.0) it needs to work with.  #        5. I didn’t see any instructions on how the ../gateway/networkConnection.yaml.  As an application developer,  I would be interested to know where that comes from and if I need to provide it and how to create it.     6.Change  The response needs to deserialized from a buffer into paper, a CommercialPaper object which can interpreted correctly by the application.  To  The response needs to be deserialized from a buffer into paper, a CommercialPaper object which can interpreted correctly by the application.    7. Should `beta` be removed from here:  "dependencies": {      "fabric-network": "^1.4.0-beta",      "fabric-client": "^1.4.0-beta",      "js-yaml": "^3.12.0"    },    8. Let’s install these packages with the npm install command – this may take up to a minute to complete:  I think we need to tell them that `npm install` needs to be run from the ../commercial-paper/organization/magnetocorp/application directory
Answer: 86070.0

User story: "This needs more detail, but is a placeholder so as not to lose track of it."
Answer: 82718.0

User story: "This needs more detail, but is a placeholder so as not to lose track of it."
Answer: 77348.0

User story: "Refer to FAB-10726 for the system chaincode side of ApproveChaincodeDefinitionForMyOrg.    As a start, the CLI should only support the built-in endorsement and validation plugins (and thus return an error when those parameters are set).  {code:java}  peer chaincode approveformyorg -C <channel-id> --name <cc-name> --version <cc-version> --hash <hash-bytes> --sequence <sequence> --policy <e.g. plain-text endorsement policy when using escc>{code}   "
Answer: 77344.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: "One of the persistent problems with running a fabric network is that 'Init' transactions have extreme latency if the chaincode has not already been built and started."
Answer: 368117.0

User story: "The end result of this story should be a new GetPrivateDataHash function in the chaincode shim which exposes the underlying hashed value of a key.  It should accept 'plain' keys which are the unhashed version of the key name in the query."
Answer: 3877.0

User story: "This should be relatively straightforward as things have already been wired to allow this.  However, when the new lifecycle defines a chaincode, the Init function should be callable once and exactly once."
Answer: 85793.0

User story: "Per FAB-13523 and FAB-13524 the validation parameters obtained by the validation code should be injected as a dependency.  This story is to create a small routing shim which first checks the new lifecycle implementation to determine if there are validation parameters defined there, then, if none exists, falls back to the legacy LSCC implementation."
Answer: 54185.0

User story: "As a companion task to FAB-13523, the new lifecycle should implement the interface which returns the validation parameters for a chaincode.    Note, as a special edge case, this validation interface should also return the validation info for '+lifecycle' itself, beginning with an automatically generated signature policy requiring the majority of orgs to endorse.    Later, we should support evaluating channel config policies as endorsement policies, and this validation info can be changed."
Answer: 85795.0

User story: "Today, the validation code reaches directly into the LSCC namespace in order to retrieve information about which validation code to execute and what parameters to pass to it (endorsement policy).  In order to ultimately support the new lifecycle, the source of this information must be abstracted.  The first step is to remove the existing implementation out and into its own module, and inject it as a dependency."
Answer: 23603.0

User story: "The current chaincode definition messages do not include any collection information.  This is because originally when the new lifecycle was designed, collection management was going to be delegated to within the chaincode itself.  Since this did not happen, it must be implemented in the new lifecycel."
Answer: 63441.0

User story: "By reporting the existence of implicit collections for any chaincode namespace defined with the new lifecycle, we automatically get most of the implementation of implicit collections for free.    The implementation should additionally report the existence of implicit collections for the '+lifecycle' namespace to enable the new lifecycle functionality."
Answer: 23134.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 was updated to rather than directly interrogate collections definitions from the lscc table, to instead delegate to an injected dependency which returns collection information based on changes to the world state.    This story is to have the existing lifecycle implement this interface so that it can be used (in time) to provide collection information to the ledger."
Answer: 85803.0

User story: "This story is to create a routing shim to satisfy the chaincode.Lifecycle interface defined in core/chaincode/chaincode_support.go.    It should first attempt to retrieve the chaincode definition from the new lifecycle, and if not found, it should fallback to looking for that definition in the old lscc lifecycle.    This new routing shim should be wired in place of the existing legacy lifecycle when constructing the chaincode support."
Answer: 85804.0

User story: "This story is to wire the existing ACL provider (complete with 'p' type ACLs per FAB-13515) into the new +lifecycle chaincode.    The existing functions are:    +lifecycle/InstallChaincode -- Chainless, should be restricted to admin  +lifecycle/QueryInstalledChaincode -- Chainless  +lifecycle/QueryInstalledChaincodes -- Chainless  +lifecycle/DefineChaincodeForMyOrg -- Has chain, but should be restricted to local admin  +lifecycle/DefineChaincode -- Has chain, should be writers  +lifecycle/QueryDefinedChaincode -- Has chain, should be readers  +lifecycle/QueryDefinedNamespaces -- Has chain, should be readers"
Answer: 85803.0

User story: "Existing SCCs like lscc and cscc do custom local checking for ACLs for chain-less actions.  These should be converted to use the 'real' ACL infrastructure."
Answer: 62971.0

User story: "Existing ACLs work in a generic way only for 'c' or 'channel' type ACLs which are defined in a channel.  But, there are other channel-less ACLs and ACLs which are specific to a peer's organization which must be enforced.  There was therefore the notion of 'p' type ACLs which was never implemented.  This story is to complete that implementation.  "
Answer: 62972.0

User story: "For the new lifecycle, each organization records whatever definnition they desire for the new chaincode definition.  This function should read all of the votes, and return a slice of which organizations agree to a given definition."
Answer: 63476.0

User story: "For the new lifecycle, each organization maintains state as to whether that org agrees with a particular chaincode definition.  If the chaincode is already defined, then making any definition other than the current one does not make sense.  If the chaincode is not defined, then any definition should be allowed as part of the voting mechanic."
Answer: 63477.0

User story: "For the purposes of serialization/deserialization, the part of the state that the keys reside in is irrelevant, so, we need a uniform way to access the state.  This can be accomplished via shims which pass through to the underlying implementation.  "
Answer: 63477.0