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: "N.B. In this story we will work with the following configuration updates:   # Type A updates that are _not_ channel creation requests: e.g. a configuration updates that modifies {{BatchSize}}. The channel creation requests will be covered as a sub-task in FAB-11591.   # Type B updates that do not expand the consenter set: e.g. a configuration update that modifies {{MaxSizePerMsg}}, or the current consenter's client TLS certificate. The transactions that expand the consenter set should be covered as a sub-task in FAB-11161.    h2. Notation   * Type A configuration transaction: a configuration update that modifies anything but the {{ConsensusType.Metadata}} field, where we store the list of Raft consenters.   * Type B configuration transaction: The opposite of a Type A configuration.    For more info, [the design doc is your best friend|https://docs.google.com/document/d/138Brlx2BiYJm5bzFk_B0csuEUKYdXXr7Za9V7C76dwo/edit].  h2. Acceptance criteria  h3. Scenario 1 (Type A gets processed w/o issues)   # 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 send a Type A configuration update, e.g. one that increases {{BatchSize}} to 2. A SUCCESS status is returned. (For now, avoid any channel-creation requests. These are technically Type A as well.)   # User invokes the Deliver RPC and receives the genesis block and a configuration block that lists the {{BatchSize}} as having a value of 2.    h3. Scenario 2 (Type B that expands consenter set gets rejected)   # 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 send a Type B configuration update that expands the consenter. This request is rejected.    h3. Scenario 3 (Type B gets processed w/o issues)   # 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.   # User launches single-node etcd/raft-based ordering service.   # User invokes the Broadcast RPC to send a Type B configuration update that modifies one of the configuration settings introduced in FAB-11861. A SUCCESS status is returned.   # User invokes the Deliver RPC and receives the genesis block and a configuration block that shows that the updated value in Step 3 above."
Answer: 93899.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: "h2. Acceptance criteria    h3. Scenario 1 (check for persistence)   # 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 10 and {{Batch.Timeout}} is set to a reasonably high value, e.g. 120s.   # User launches single-node etcd/raft-based ordering service.   # User invokes the Broadcast RPC to send {{BatchSize}} transactions ({{foo-1}} to {{foo-10}}) to the ordering service within {{Batch.Timeout}}. User receives a SUCCESS response for each of those calls.   # Once {{BatchSize}} transactions have been sent successfully to the ordering service, user invokes the Deliver RPC and receives the genesis block and a block containing transactions {{foo-1}} to {{foo-10}}.   # User restarts the OSN.   # User re-issues Deliver RPC to the OSN and expects to receive the same blocks as in Step 4.    h3. Scenario 2 (check that crashed leader does not persist incomplete batches)   # 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 10 and {{Batch.Timeout}} is set to a reasonably high value, e.g. 120s.   # User launches single-node etcd/raft-based ordering service.   # User invokes the Broadcast RPC to send *less than* {{BatchSize}} transactions to the ordering service: {{foo-1}}, {{foo-2}}, {{foo-3}}. User receives a SUCCESS response for each of those calls.   # User restarts the OSN before {{Batch.Timeout}} has elapsed since the OSN received the first transaction ({{foo-1}}). The goal is to prevent the OSN from cutting a block based on elapsed time.   # User invokes the Broadcast RPC and successfully sends transactions {{bar-1}} to {{bar-10}} to the ordering service.   # User issues a Deliver RPC to the OSN and expects to get only two blocks: the genesis block, and a block containing transactions {{bar-1}} to {{bar-10}}."
Answer: 244715.0

User story: "The Kafka orderer currently relies on having the broker property `auto.create.topics.enable` set to true (which is the default).  Kafka best practices recommend setting this property to false for production deployments.    As people start to deploy the Kafka orderer in production, they may choose to use one of the hosted Kafka services (such as IBM Message Hub or Confluent's managed service).  Following best practices, both of these services set `auto.create.topics.enable`  to false.    Kafka nows support an AdminClient API which allows topics to be created.  In order to implement this story, we will leverage that API."
Answer: 6290.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: "There are two kinds of  endorsement policy descriptions,  EXPR(E[, E...]) expressions in cli and n-of identities strategy in sdk. But when a new participant joins in a channel, the endorsement policy seems out of date, and we will have to propose a new transaction to upgrade chaincode config,  more participants means  higher complexity. More often, in some scenes, we just want to get more than 1/2 or 2/3 votes, so I think current endorsement policy is not flexible.    Some features like distinguished user levels or dynamic set  or some special symbols (not affected by participants join or quit)  can be considered ? For example, we assume A as a set of all organizations and B as a set of some organizations (admin organizations of channels), may be policy is 2/3 agreements from A and all agreements from B. Then when another organization joins in,  it will join set A automatically and the endorsement policy can keep using."
Answer: 760460.0

User story: "Currently, when the chaincode shim can't connect to the peer - it prints the same error message that gives little information about the actual problem to whoever inspects the shim container logs:       {code:java}  error trying to connect to local peergithub.com/hyperledger/fabric/core/chaincode/shim.userChaincodeStreamGetter/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:111github.com/hyperledger/fabric/core/chaincode/shim.Start/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:150main.main/chaincode/input/src/github.com/chaincode/example02/go/example02.go:195runtime.main/opt/go/src/runtime/proc.go:195runtime.goexit/opt/go/src/runtime/asm_amd64.s:2337 {code}    It would be useful to:  # Print the endpoint the shim is trying to connect to  # Whether it uses TLS or not  # To try to connect via *tls.Dial* (in case TLS is used) so that any TLS handshake errors would be propagated back to the caller, instead of an error saying the gRPC context deadline has passed.    "
Answer: 762339.0

User story: This story is to extend the existing 'peer chaincode list" command to support listing installed chaincodes via the new chaincode API.    The operation should be the same as before, but it should add a new '-N' parameter to indicate that the new lifecycle should be utilized, instead of the old.  It should invoke the '+lifecycle.QueryInstalledChaincodes' API, and print a list of name, version, hash.    Note, for the time being it is necessary to only allow querying installed chaincodes with '-N', the instantiated chaincodes will be covered in another story.
Answer: 229815.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 to exercise the new +lifecycle.InstallChaincode API.    It should extend the existing 'peer chaincode install' command.  It should require that a package be provided as input (to avoid non-deterministic multiple-packaging), and invoke SCC function.  It should require the 'name' and 'version' parameters, but the 'language' and 'path' parameters should not be allowed.     Like the other new lifecycle commands, it should distinguish itself from the old APIs by requiring a "-N" parameter.
Answer: 229633.0

User story: Because in the new lifecycle scheme, we will require that the package hashes are consistent, users will need to share chaincode packages.  However, there should be no centralized point of trust, so each user should be able to verify that the chaincode package contains the expected code.    Therefore, we need to extend the "peer chaincode package" command to be able to extract a chaincode package and write it out to disk.      This should be accomplished with a new chaincode sub-command 'inspectpackage'.  It should take a path to the chaincode package, and optionally a location to extract it to (defaulting to the current directory).  It should then extract the embedded code package.
Answer: 17883.0

User story: We need to add the ability to package chaincode in the new chaincode package format for the updated lifecycle.    This should come in the form of an extension to the "peer chaincode package" command.  It should take the same options for 'language' (type), and 'path', but it should refuse to allow the 'name', 'version', or 'instantiation policy' to be specified.  Additionally, the '-s' flag should not be allowed.    As with all peer chaincode commands utilizing the new chaincode lifecycle, it should indicate that the new lifecycle should be used with the flag "-N' for use of the new +lifecycle chaincode.    The operation should package the code along with the type and path into the new tar gz chaincode package format and write it to disk.
Answer: 232734.0

User story: "*Acceptance*: A fabric client can be built to submit a “transfer” request to a peer. The peer validates the request and checks that the request's creator has the rights to submit that request. If this is case, the TokenManagerSystem bound to the channel specified in the request is used to generate a RequestTransfer object which is then embedded in a TokenTransaction message. This message is returned back to the client via response.    *Remarks:* access control can be performed in multiple way. Example are:   # request's creator is a writer of the channel the request targets;   # request's creator is a writer of the channel the request targets AND the creator is in the contacted peer's organisation; "
Answer: 157013.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 fabric client can be built to submit an “issue” request to a peer. The peer validates the request and checks that the request's creator has the rights to submit that request. If this is case, a mockup RequestImport object is created which is then embedded in a TokenTransaction message. This message is returned back to the client via response.    *Remarks:* access control can be performed in multiple way. Example are:   # request's creator is a writer of the channel the request targets;   # request's creator is a writer of the channel the request targets AND the creator is in the contacted peer's organisation; "
Answer: 156900.0

User story: "Hello-    The High throughput tutorial's README is very buggy/leaves a lot for the user to infer that can make it difficult to setup the network.  I would like to update the documentation, as well as update the chaincode slightly in order to allow traditional 'standard' assets to be deleted from the network, since currently there is no way to do so.           This pertains to the 'release-1.1' branch of the repository.  I understand the latest is v1.2, however a lot of the clients i work with still prefer 1.1 so it is worthwhile to update this documentation.         I have attached the new chaincode which includes the updates.  All it is is a simple `delstandard` function, that works in tandem with `putstandard()` and `getstandard()` in order to facilitate deleting something on the network if it is put on using the traditional way."
Answer: 769025.0

User story: "The communication between the ordering service node and Kafka brokers currently supports using mutual TLS for authentication.  There are some cloud deployments of Kafka which require leveraging the SASL Plain mechanism."
Answer: 2999.0

User story: "With the introduction of Fabric 1.2, there is a new feature called Service Discovery. I want to use this feature in balance-transfer Fabric sample. What should I do to do so? Is there any Fabric SDK sample which implements this feature?"
Answer: 769460.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 10 and {{Batch.Timeout}} is set to a reasonably high value, e.g. 120s.   # User launches single-node etcd/raft-based ordering service.   # User invokes the Broadcast RPC to send {{BatchSize}} transactions ({{foo-1}} to {{foo-10}}) to the ordering service within {{Batch.Timeout}}. User receives a SUCCESS response for each of those calls.  # Once {{batch.size}} transactions have been sent successfully to the ordering service, user invokes the Deliver RPC and receives the genesis block and a block containing transactions {{foo-1}} to {{foo-10}}."
Answer: 145448.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: "Client applications make connections to the channel delivery service in order to receive the status of transactions they submit.  Clients should not open multiple streams as a single steam can serve multiple transactions.  In order to prevent issues caused by poorly written and/or malicious clients, the peer should provide a configuration setting to limit the total number of concurrent deliver streams."
Answer: 773734.0

User story: "Create a new application capability so that features built can be gated behind the capability and potentially not exposed. This will allow us to develop enhanced concurrency control features in the master branch and only expose the features in a release when they meet production requirements.    See    https://gerrit.hyperledger.org/r/c/21247/19/core/chaincode/handler.go"
Answer: 773753.0

User story: When a peer is stopped or restarted, all chaincode containers essentially stop (they actually "crash" as they are only kept running by maintaining a connection to a running peer).   This results is multiple issues and causes confusion for users of Fabric.    There is no reason why the peer cannot actually automatically start the containers for chaincode which should be running.
Answer: 773828.0

User story: "The orderer should be able to use kafka with SASL/Plaintext authentication. This will help to run orderer with the hosted Kafka services."
Answer: 12283.0

User story: "Implement a utility function in the Go chaincode so that there is a common way to serialize an uint64. Operations and chaincode both need to understand how an uint64 is represented in byte format.    Method signature:    GetStateUInt64(key string) uint64, error         See the epic design doc for more information."
Answer: 299840.0

User story: "Implement a utility function in the Go chaincode so that there is a common way to serialize an uint64. Operations and chaincode both need to understand how an uint64 is represented in byte format.    Method signature:    PutStateUInt64(key string, value uint64) error         See the epic design doc for more information."
Answer: 299840.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "In the current chaincode install and instantiate model, installing chaincode simply means the peer writes the chaincode packages bytes to the filesystem.   When chaincode is instantiated, the chaincode image is built and then an instance of the container is created.  (This flow is actually leftover from the old Fabric model where the chaincode bytes were deployed as an actual deploy transaction).    This flow is problematic for several reasons:   # The user is left with the false impression that the chaincode package will compile and deploy.  This is not the case (especially for Go where the code is actually compiled as part of the image build process).   # It can take time to actually build the image and depending on the host system this leads to unnecessary timeouts.   # There are times when the peer host does not have Docker, the correct CC builder or base OS images installed.  It would be better to know this up front         The proposal here is to actual build the chaincode image at install time.          "
Answer: 776368.0

User story: "Documentation needs to be updated with enhanced concurrency control information so that chaincode developers can understand how to utilize built in operations and create their own operations if needed."
Answer: 777779.0

User story: "Integration tests are needed to ensure that a chaincode which includes both ExecuteUpdate and ExecuteAssert calls using the built in operations function correctly."
Answer: 302401.0

User story: "The ExecuteAssert function needs to be added to the Go chaincode shim so that chaincode developers can execute update operations.    Function signature    ExecuteAssert(operation string, args OperationArguments) error         See design doc in Epic for more details."
Answer: 302429.0

User story: "There appears to be no way to control the amount of work that a peer has to handle. This presents a problem when the peer is running on a machine with a fixed amount of memory.    Some examples:   * No limit on number of simultaneous event service connections.   * No limit on number of simultaneous proposal endorsement requests.   * No limit on size of proposals.    Abusing any of the above limits can result in out of memory related panics on machines without infinite memory."
Answer: 777886.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Private data collections specify which orgs peers are authorized to retrieve and persist private data.    If a client from a non-collection member does a chaincode query against an authorized peer with the private data, the client can get the private data back. Need chaincode APIs to enable access control within the chaincode such that non-member clients can be restricted from querying private data that they do not have access to. Previously the chaincode author had to manually construct such access control logic.    The access control for collection can be done in two ways:   # implicit ACL – at the peer;   # explicit ACL – at the chaincode;    +*Implicit ACL*+   In the implicit ACL approach, by default, the peer would ensure that only collection's members can access the private data. Though such ACL can be implemented at the chaincode (using new APIs such as IsAMemberOfCollection(Coll, MSP)), it would be better to implement at the peer so that not every applications need to rewrite the same ACL logic at chaincode.   * *Pros*: Chaincode does not need to do anything special. No need to upgrade the existing   chaincodes. No need to introduce new chaincode APIs.   * *Cons*: Rigid. Only collection's members can access the private data (not a non-member even if   such feature is required for a short time).    +*Explicit ACL*+   In the explicit ACL approach, the chaincode needs to take care of controlling the access to collection's private data. If the application has dynamic ACL requirements in which non-members may get access to particular private data for a short period of time, implicit approach may not work. In such scenarios, the chaincode should implement the ACL logic to dynamically decide the list of members who can access the   collection's private data. Especially when we do asset transfer between collections, the non-member may like to read the private data before finalising the transaction.    * *Pros*: Flexible. The access list can be controlled dynamically. Even a non-member can be allowed   to access the private data for a short time if required.   * *Cons*: Needs to introduce new chaincode APIs. The chaincode logic would become little   complex as compared to implicit ACL approach."
Answer: 186704.0

User story: Now, if a chaincode installs on a target peer, we just can get the installed chaincode info with name, path, ver, escc, vscc, etc. Not including the source code, like something in the ChaincodeDeploymentSpec.    I found it has a function, named "GetChaincodeFromLocalStorage", which can get the target chaincode's ccpack. So, why the lscc doesn't provide a method like "getLocalCCData" to return the chaincode data? 
Answer: 534709.0

User story: "Sending the same transaction proposal to duplicate targets (same peer) will cause one of the requests to fail with TxId already exists error"
Answer: 11606.0

User story: "Add java chaincode example02 to chaincodes folder in fabric-samples and update first-network scripts to support -l java switch"
Answer: 58530.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 think that ideally - the user should be oblivious of the fact that a chaincode has state based endorsement or not, and the discovery service can hint to the SDK in the endorsement descriptor given by the query response - whether the chaincode has state based endorsements or not.    That's because, since the discovery query (to obtain the set of endorsers for the chaincode) happens before the actual chaincode execution - the discovery service can't foresee the keys the chaincode execution would update (without executing the chaincode itself ;) )    Therefore, if the SDK sees a hint in the endorsement descriptor returned by the peer - it would know that it would need to send to the peer a subsequent query after the endorsement of the proposal, in which it would specify the keys in the write-set that are changed, in order for the discovery service to compute a new endorsement descriptor that satisfies the combination of the endorsement policies of these keys.    The discovery service would extract the endorsement policies for the keys, convert them to the discovery representation of endorsement policies, and then combine them all to a policy that satisfies each policy in the combination.   The endorsement descriptor returned from that 2nd discovery query would be derived from that combined policy.    This would mean that state-based endorsements transactions (that are sent to ordering) would require a discovery query beforehand, but I think that's a necessary evil considering the fact that in state based endorsements - anyone can change the owners of the key without the SDK to know, and thus - the peer set derived from the endorsement policy the SDK uses can be stale.    A way to make this more efficient, is for the SDK to cache endorsement descriptors per key, and optimistically reuse these descriptors and hope the key ownership hasn't changed.    Given that in some use cases - only filtered events are returned to the SDK, I don't think that parsing events and figuring out which key metadata has changed and invalid the cached per-key descriptors is the way to go.         Now, in any case - the SDK would need to pass the keys from the RWSet in order for endorsement descriptor to be calculated according to the following logic (taken from the playback):    !Capture.PNG!         This means, that if a key doesn't have an attached EP, or doesn't exist - the EP for that key to be taken into the computation of the combination of the EPs would be the chaincode's own EP.         Opinions?    [~<USER>  [~<USER> [~<USER> [~<USER> [~<USER> [~<USER> [~<USER> [~<EMAIL>]"
Answer: 782493.0

User story: "Prover peer grpc service is now ready to fully process TLS-authenticated client requests to for proof computation. At the end of this item acceptance criteria of the parent item should be fulfilled."
Answer: 276525.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: "Client local interface for grpc connection with the peer is implemented. In this way the implementation of issue/redemption/transfer operations is enhanced with the ability to submit the related request to a grpc connection to the prover service."
Answer: 279504.0

User story: " I analyzed bottlenecks in Fabric peer code, and identified that the mutex locks in MSP cache cause heavy lock contention when TPS is very high.    [https://github.com/hyperledger/fabric/blob/v1.2.0/msp/cache/cache.go#L41-L59]    In the current implementation of MSP cache, mutex locks are used to guard LRU lists that hold entries of MSP cache. Every get operation of a LRU list always updates the order of the list, so we need a mutex lock instead of a RW lock to guard the LRU list.    Some approximate LRU algorithms such as second-chance algorithm are known to work with reader-writer locks instead of RW locks. I have a work-in-progress code, and obtained 50% TPS improvement for some workloads. Please see the attached PDF file for more details.    Later, I will post my work-in-progress code to show how it works.          "
Answer: 53533.0

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

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

User story: "{color:#333333}Acceptance: A client function (cwLib) takes as arguments the identifiers of the tokens {color}{color:#333333}to be transferred and the expected recipients. As a result the function would request from a peer to construct the corresponding transfer proof. The transfer proof is returned to the client and the function will return successfully only if the returned transfer proof is correctly computed.{color}  {color:#333333} {color}"
Answer: 331160.0

User story: "*Acceptance*: Client wallet library for token operations in Fabric is enhanced with a function that takes as arguments the long term identity of an end-user and queries a peer on the set of tokens that this end-user owns. The peer receives the request and acts according to the specification of previous story."
Answer: 252774.0

User story: "{color:#333333}{color:#333333}Acceptance: A client function (cwLib) takes as arguments the type and quantity of assets to be introduced into the system via a token issue process. As a result the function would request from a peer to construct the corresponding issue proof. {color}{color}  {color:#333333} {color:#333333}The issue proof is returned to the client and the function will return successfully only if the returned issue proof is correctly computed.{color}{color}"
Answer: 279572.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 query providing the transfer request’s details  (i.e., identifiers of tokens to be issued, and expected recipients). The peer is to consult the   current state of the ledger to retrieve the details of the tokens that are to be transferred, and   assess if they exist, have not been spent, and  if the inputs match the quantity of the intended   outputs, i.e., suffice for accommodating the full set of tokens transferred to all the specified   recipients. If any of these conditions is not met, the peer rejects; otherwise it returns to the   client a transfer proof.  The peer responds with a transfer proof   that matches the requester’s parameters. "
Answer: 279644.0

User story: "*Acceptance*: A fabric client can be built to submit a “list tokens” query to a peer.  Peer considers the current ledger state and returns the tokens owned by the   creator of the query; if the creator of the query does not have permission to read  the channel’s data, the request is rejected; if the creator of the query does not own  any tokens the peer would return an empty list. The client can observe the correctness  of successive “list my tokens” queries in correlation with the content of the ledger."
Answer: 279642.0

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

User story: "Given FAB-11942, and FAB-11371 this item refers to the testing that the transfer transactions can be correctly processed by the existing tx processor and TMS implementation."
Answer: 279611.0

User story: *Acceptance*: A (simulated) client generates a “transfer 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 invalid in the end and will have no impact on the ledger state.         This one relates to the extension of proto messages to accommodate transfer   transactions and of the corresponding test, testing that transfer token transactions   go through the right path.    The first part was already completed (proto messages definition). The second is   blocked by  FAB-11175.
Answer: 179990.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 an "issue tokens" transaction that is submitted  to the system.  Upon receiving this transaction, a committing peer redirects its processing to its   Token specific validation & commit components.  FabToken custom validation ensures that  the tokens requested to be issued are of the right form (e.g., of acceptable type), and custom   commit ensures that the transaction creator is authorised to issue tokens.  Upon successful  transaction validation and commit, the ledger state is updated to reflect this. The ledger APIs   can be used to retrieve the committed data. 
Answer: 152755.0

User story: "{color:#333333}Acceptance: I can setup the token client library using a fixed set of token parameters, and monitor the internal state of the created client to ensure that its initialization took place with the right parameters. The client library would not provide any further functionality at this point beyond setup.{color}"
Answer: 331281.0

User story: "Transaction processing at committing peer side consists of validation (vscc) & commitment (performed by a transaction processor component). The token-related setup of the committing peer expands on both components.    *Acceptance*: I can setup the peer using a fixed set of fabtoken parameters, and monitor the internal state of the peer to ensure that FabToken initialisation took place with the right parameters."
Answer: 70716.0

User story: "After creating a start and end composite key, user cannot use `_GetStateByRange()_` as we check whether the passed key is simple or composite key. If a composite key is passed to the range query, we would throw error.     With `_GetStateByPartialCompositeKey(objectType, []keys)_`, user can get all entry for a given partial composite key only. However, user cannot perform a range query with a start and end key.     We need provided the following two APIs to allow range query using composite keys.    # `GetStateByCompositeKeyRange(compositeStartKey, compositeEndKey)`   # `GetStateByPartialCompositeKeyRange(partialCompositeStartKey, partialCompositeEndKey)`"
Answer: 788135.0

User story: "Acceptance: Setup runs, and internal state of the peer indicate the FabToken initialization with the right parameters."
Answer: 789697.0

User story: "Acceptance: I can create a serialized protocol buffer message from a human readable YAML document that provides the FabToken initialization parameters. Validation is expected on the input such that inconsistent data is flagged.     "
Answer: 776300.0

User story: "Capabilities are used to gate features and functions that impact a network of peers. We need to establish a capability name (and associated configuration support) to enable the token features of fabric.    Acceptance: I can define the new capability in an config update transaction, submit it, and observe the peer can support the new capability.         3 points"
Answer: 154282.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: "Add feature to enable or disable create _global_changes db.         couchdb recommended to delete _global_changes db if you don't use it because this db will get bigger in short time and you don't want to waste system resources on compacting it regularly.         [ttp://docs.couchdb.org/en/latest/install/setup.html#single-node-setup|http://docs.couchdb.org/en/latest/install/setup.html#single-node-setup]     "
Answer: 28828.0

User story: "To help debugging, log error stacks when the errors first happened.   # When an error came from external source (e.g., go lib or vendor), wrap the error with stack and log it with logger.Errorf   # When ledger creates a new error, creates the error with stack and log it with logger.Errorf    Custom errors defined in ledger will be handled separately in FAB-11105."
Answer: 412027.0

User story: "Increase test coverage      for fabric/cmd/common/signer/signer.go"
Answer: 17080.0

User story: "Presently, Fabric reserves portions of the state db namespace through the LSCC table.  This assumes that all of the reserved namespaces are restricted to user chaincodes.  This is not the case generally, and will become even less so as Fabric gains more features.    Because of this, lifecycle should be built on a more basic principle that namespaces in the state database are reserved."
Answer: 249636.0

User story: "The cclifecycle package has an interface which enumerates installed chaincodes.  Presently, this depends on a concrete implementation which queries the filesystem directly.  Like with the core/chaincode package, we need a shim which will first query the new package repository, and the chaincode does not exist in the new repo, check the old."
Answer: 42012.0

User story: "The new chaincode lifecycle brings with it a new packaging format.  The storage and retrieval of this format has been implemented in prior stories.    Now, it's necessary that both stores work, with the newer store taking preference.  There is an interface {{PackageProvider}} in the core/chaincode.  This would be a good place to start.  We need a shim which satisfies this interface and uses the chaincode stored in the newer store if it is present and in the older one if it is not."
Answer: 51613.0

User story: "Fabric base os image is built using multiple packages out of which Ubuntu is one. There is no process within the FABRIC team which regularly checks for any security or vulnerability reporting for Ubuntu. This scan process needs to be integrated and repeatedly regularly (weekly)  to look for newly found security vulnerabilities in the image.  This should be conducted on older supported versions of Fabric as well as the current version.    Discussion with <USER>mentions, this is only 1 item in pending and in progress state. Opening FAB for tracking.    Documentation mentions - Ubuntu ([https://github.com/hyperledger/fabric-baseimage)] "
Answer: 797946.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: FAB-1870 has a set of guidelines in regards to logging. One of the guidelines is to add an entry and exit logging statement to major methods that includes any important entry/exit parameters. This can help debugging.  {code:java}  logger.Debugf("Entry") // modify to include any input parameters  defer logger.Debugf("Exit"){code}   
Answer: 799068.0

User story: *Acceptance*: A (simulated) client generates an "issue 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: 165342.0

User story: Although there's a _Block Number_ attribute inside the _Block Header_ (explained at [Read-the-docs|https://hyperledger-fabric.readthedocs.io/en/release-1.2/ledger/ledger.html#blocks]), there are [no attributes|https://hyperledger-fabric.readthedocs.io/en/release-1.2/ledger/ledger.html#transactions] stated to know the depth of a transaction.    Some transaction attributes can be explored, e.g. name and version for its chaincode. But they have no link with other block transactions in a single channel, forcing developers to search workarounds, making the implementation heavier and adding an overhead.    As an example, Hyperledger Explorer inspects each block to store the _count_ value on a local database.    In order to provide new features, the ability to supply the "channel transaction count" value directly from the ledger is a nice improvement.
Answer: 800095.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 use vagrant Shared directory on Windows ,and set up a virtual machine, launched the fabric network in the virtual machine, and then I want to debugging chaincode in Windows Goland IDE, i don't know what should i do?"
Answer: 418070.0

User story: ***Requirement*   Those opting couch database as world state ledger can use the same for running rich queries for production support. This could include Operations or Support user. This avoid user to go through chaincode log which most of the time would be in ERROR mode in Production or Pre-Production.    Server Admin credential cannot be shared for such purpose and should be used exclusively by the respective fabric-peer. This is already implemented as part of -FAB-10048-.    This JIRA is filed to further extended the current functionality to provision Read Only User.         This can be achieved by allowing Server Admin creates a couch database user (_users database) and add following JSON  {code:java}  {   "name": "readonlyuser_username",   "password": "readonlyuser_password",   "roles": ["channel1_member"],   "type": "user"  }{code}       2.  Same read only user name can be added to \{db}/_security object to the member list    for example - consider the database (channel name) = channel1  {code:java}  '{"admins": { "names": [], "roles": [] }, "members": { "names": [], "roles": ["channel1_member"] } }'{code}    OR    (haven't tried the below option)  {code:java}  '{"admins": { "names": [], "roles": [] }, "members": { "names": ["readonlyuser_username"], "roles": [] } }'{code}         3. Adding a validate function that allows write only to _admin  {code:java}  "validate_doc_update": "function(newDoc, oldDoc, userCtx, secObj) { if (userCtx.roles.indexOf('_admin') == -1) { throw({forbidden: 'Document can be updated only by server admin user.'});}}" }'{code}       FAB-1308 has a similar Point 3 requirement - this can be further restricted to use userCtx.names as validation logic.
Answer: 803609.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: "According to the concept, private data collection allows a defined subset of organizations on a channel the ability to endorse, commit, or query private data without having to create a separate channel.  However, the unauthorized organization can endorse a transaction to put private data and the proposed transaction is stored on the ledger.    Steps to reproduce   --------------------------  I tried a tutorial for private data (http://hyperledger-fabric.readthedocs.io/en/latest/private_data_tutorial.html) with fabric v1.2.0.  I changed test steps a little to see that the unauthorized organization (= org2) can’t put private data collection `collectionMarblePrivateDetails`.   After switching the test user to org2, I invoked `initMarble`.    Expected Results  --------------------------  The peer on org2 returns a proposal error at endorsement time because the peer is not allowed to access to a private collection.  There is no update on private data collections.    Actual Results  --------------------------  The peer on org2 returned success as a proposal response.  There was update on private data collection `collectionMarblePrivateDetails`. The physical file is located under /var/hyperledger/production/ledgersData/pvtdataStore.  - Org1’s peer has private data. Org1 can get this data when calling `readMarblePrivateDetails`.  - Org2’s peer doesn’t have private data. Org2 fails to get this data when calling `readMarblePrivateDetails`.    Issue   --------------------------  The namespace under private data collection can be consumed by unauthorized organizations.  As a result, the authorized organizations can read incorrect data produced by unauthorized organizations.  "
Answer: 693352.0

User story: "use the fmt.println replace logger.info in the `peer logging getlevel` cmd"
Answer: 419984.0

User story: "When removing re-enabling the composite checks, the following files no longer pass the vet checks due to their use of unkeyed struct literals.  {code:java}  common/channelconfig/msp.go  core/chaincode/chaincode_support_test.go  core/chaincode/platforms/golang/platform.go  core/chaincode/platforms/java/platform.go  core/chaincode/platforms/node/platform.go  core/chaincode/shim/shim_test.go  core/committer/txvalidator/vscc_validator.go  core/common/privdata/store_test.go  core/deliverservice/deliveryclient_test.go  core/handlers/validation/builtin/validation_logic_test.go  core/ledger/kvledger/txmgmt/validator/valimpl/helper_test.go  core/policy/policy_test.go  core/scc/lscc/lscc_test.go  integration/discovery_service/e2e_test.go  integration/pvtdata/e2e_test.go  integration/runner/couchdb.go  integration/runner/couchdb_test.go  integration/runner/discovery_service_test.go  integration/runner/kafka.go  integration/runner/zookeeper.go  integration/world/config.go  integration/world/config_test.go  msp/mgmt/mgmt.go  peer/gossip/mcs_test.go  peer/gossip/sa_test.go  {code}    Use the {{keyify}} tool to add the field names and then format as necessary."
Answer: 5437.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 EventHub functionality was replaced by the much improved Channel Event Service in v1.1.0.  We've always known that the EventHub was a stop gap on the way to a channel-scoped event service.    Given this and given the number of issue that exist with the EventHub (many of which cannot really be fixed without major surgery if at all), we should remove the EventHub from the peer as well as all of the SDKs."
Answer: 108029.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: "Right now, PTE can install/instantiate the chaincode, but does not have the capability to upgrade the chaincode.    Upgrading chincode mechanism in PTE is to closely follow the instantiate mechanism in PTE."
Answer: 22720.0

User story: "We should add a hook in peer/node/start.go to call an upgrade procedure which migrates the old chaincode package format to the new.  Note, that this migration will necessarily duplicate data, as the old package format is required for channels which do not upgrade to the new lifecycle.    This hook should read in each installed chaincode, convert it into the new package format, and write it to the new package format (if a chaincode of that name does not already exist."
Answer: 259806.0

User story: "In order to facilitate upgrade, we will need to convert the old chaincode install packages to the new format, and persist them.  Note, this will be discarding some of the irrelevant fields, like the instantiation policy, signers, etc. but as they are unneeded in the new lifecycle approach this should not be a problem.    To fulfill this story, there needs to be two utility functions, one which accepts a SignedCDSPackage and outputs name, version, ChaincodeInstallPackage, and one which accepts a CDSPackage and outputs the same.  Note, that the SignedCDSPackage embeds a CDS, so likely the one function will ultimately call the other."
Answer: 31651.0

User story: "Currently custom errors do not contain stack info. For serviceability, need to include stack when creating custom errors.     Because the structs defined in the package 'github.com/pkg/errors' are not public, we could not extend our custom errors from it. Therefore, we will have to do the following   - create the actual error using errors.New...   - wrap the above error in our custom error   - Implement the additional function 'Format' in our custom error (this will simply invoke the 'Format' function of the wrapped error)     "
Answer: 424149.0

User story: "Every doc has a description except the Service Discovery CLI. Should add one."
Answer: 994.0

User story: "There as a user request on rocket-chat that the fault tolerance and failure modes of Fabric be more clearly documented.  https://chat.hyperledger.org/channel/fabric-orderer?msg=mhD9XJpcHaXXB2FEy    This seems like it would be a good idea. The user's suggestion was as a new section under https://hyperledger-fabric.readthedocs.io/en/release-1.2/architecture.html    Some possible topics for discussion could be:  # Replacing a failed peer  # Replacing a failed OSN  # Fault tolerance limitation of Kafka based ordering  # Strategies for disaster preparedness (ie, spreading deployments over multiple datacenters)    The above is not meant to be exhaustive, but simply as a starting point."
Answer: 809526.0

User story: "Following the pattern that [~<USER> started for including basic images in the glossary to represent glossary items."
Answer: 109567.0