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: "This API takes the filesystem path for snapshot folder instead of genesis block  Perform followings to create ledger  - Populate blockstore index with txids from the from the corresponding file in the snapshot  - Populate collection config history db from the corresponding file in the snapshot  - Use worldstate from the corresponding file in the snapshot and populate         a) statedb,         b) purgeMgr bookkeeping DB,         c) private data store with missing entries,         d) Metadata hint db  - Invoke reconciler without pause to pull the private data  - Enhance blockstore to maintain height, last block hash, and last block commit hash (which is otherwise extracted from the last block)"
Answer: 276268.0

User story: "Introduce a snapshot mgmt component that    Maintains snapshots in a folder ledgersData/snapshots. A specific snapshot for a channel at a certain height H is maintained in folder ledgersData/snapshots/<channelName>/<blockHeight>   * CreateSnapshot API creates a new folder with four files   1) Exported collection config history below snapshot height   2) Exported txids below snaphost height   3) Exported world state (after pausing the transaction processing)   4) Exported snapshot metadata in human readable json format   Metadata to include    a) height of the snapshot,    b) hashes for txids   c) hashes for world state   d) hashses for collection config history   e) last block hash   f) last block commit hash   g) overall hash for snapshot by combining hashes in (b), (c), and (d)     * DeleteSnapshot API  (DEFERRED till we see the need of it as the admin can directly manage the generated snapshot folder)   deletes the folder for the snapshot   * SnapshotsInfo API  (DEFERRED till we see the need of it as the admin can directly manage the generated snapshot folder)   returns the metadata for all available snapshots"
Answer: 272022.0

User story: "AddValue() should be renamed to something more appropriate given it is used for both the addition and removal of values.     "
Answer: 359.0

User story: "As a consumer of the fabric config API I'd like to be able to remove a consortium from a config transaction.         *Acceptance*    I can call a function for removing a specific consortium from a channel config. The examples should be updated as well to demonstrate usage."
Answer: 9780.0

User story: "As a consumer of the fabric config API I'd like to be able to remove consortium, application, and orderer orgs from a config transaction.         *Acceptance*    I can call separate functions for removing an organization from a consortium, application, and orderer. The examples should be updated as well to demonstrate usage."
Answer: 14943.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: "Gossip bootstrap peer and anchor peer connection establishments are a two step process:   # Connect to the remote endpoint, and figure out its organization association   # Connect to the remote endpoint once again, this time sending membership information according to what it is eligible to.    Unfortunately, if the responding peer connects to the initiator peer at the same time, the connection of (1) will be overwritten by the connection (gossip keeps a single connection among every pair of peers) from the responder peer and the initiator peer will consider the responder peer as dead.    In production, where peers run for a long time and constnatly retry, this is not a problem.    However, in integration tests that expect data to be disseminated in a timely manner, this might cause flakes.         This story proposes to mark probes (1) with a special boolean flag that indicates this connection is not a long lasting one, and thus there is no point to add it to the connection store."
Answer: 1663.0

User story: "As a consumer of the fabric config API, I would like to be able to retrieve and update my channel's policies.     We initially supported adding/removing/retrieving policies for all other groups except for the channel group, lets add this in now before we support retrieving the entire channel config.         *Acceptance*    I can call a function to add a policy to the channel group and another to remove a policy from the channel group. I should also be able to retrieve the existing policies in the channel group. The examples should be updated to demonstrate usage of these features."
Answer: 4930.0

User story: "As a consumer of the fabric config API, I would like to be able to update the channel creation policy value in a consortium.    We don't support configuring it at channel creation time because it governs the validation of the channel creation request so allowing the channel create tx to set the value would defeat the point; however, we want to be able to allow consumers to update this value on config updates. Note that this is not a ConfigPolicy but rather a ConfigValue in a specific consortium group.         *Acceptance*    I can call the function to update the default channel creation policy value in an existing config. An example should be added to the example_test as well."
Answer: 5692.0

User story: "[https://golang.org/doc/effective_go.html#Getters]         func (c *ConfigTx) GetAnchorPeers(...) -> func (c *ConfigTx) AnchorPeers(...)         [https://github.com/hyperledger/fabric/pull/880#discussion_r397418783]"
Answer: 11720.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 user of the Fabric channel configuration API, I would like to be able to retrieve the entire channel configuration without manually parsing the config transaction. Now that we have the supporting functions in place for retrieving all dependent fields, we should be able to support retrieval of the entire channel configuration.         *Acceptance*    I should be able to call a function for retrieving channel configuration that returns a config.Channel."
Answer: 12968.0

User story: "Now that we have an UpdateMSP function which allows directly modifying various fields of an MSP we should use that where possible instead of relying on highly specific, single use helper functions (such as AddRootCAToMSP and RevokeCertificateFromMSP). We should streamline things and rename functions as appropriate.     I'll update this with more concrete details shortly.     Rename:  * GetMSPConfigurationFor(Application,Orderer,Consortium)Org to (Application,Orderer,Consortium)MSP    Remove / refactor  * AddRootCAToMSP - likely remove this. any value to a separate function for this when we can just append directly to the fields using UpdateMSP now?  * RevokeCertificateFromMSP - consider separate helper for creating CRL given a SigningIdentity and then we can just use UpdateMSP to add the new CRL"
Answer: 7549.0

User story: "As a user of the Fabric channel configuration API, I would like to see smaller and more varied example usages for updating the config instead of one giant end to end flow that updates every field.         *Acceptance*    For now let's split out separate update examples dealing specifically with   * updating orderer configuration (including orderer policies)   * updating application specific values (including application policies)   * organization management (adding/removing orgs and anchor peers/orderer endpoints to application orgs and orderer orgs respectively)   * msp modifications   * capabilities (application, orderer, and channel)"
Answer: 7221.0

User story: "We want to remove the config package from Fabric before the release-2.1 branch is cut so it doesn't go into v2.1.0. This may involve a formal RFC justifying the creation (can probably just refer to information in FAB-17628) so the linux foundation can approve and create a new repo for us.         *Acceptance*    A new repo created in the hyperledger org that contains renamed packages for the config code. Contributing guide, CI process/configuration, integration tests exist for the new repo."
Answer: 70185.0

User story: "As a user of the Fabric channel configuration API, I would like to be able to update an application groups's ACLS by adding or removing ACLs.         *Acceptance*    I should be able to call this function to modify a config transaction and then process further configuration updates on the modified config transaction. The examples test should be updated to demonstrate usage of this feature.     "
Answer: 12859.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 user of the Fabric channel configuration API, I would like to be able to retrieve existing application configuration without manually parsing the config transaction.         *Acceptance*    I should be able to call a function for retrieving application configuration that returns a config.Application."
Answer: 17173.0

User story: "As a user of the Fabric channel configuration API, I would like to be able to add and remove application, orderer, and channel capabilities. Consider whether we should allow setting unsupported capabilities outside of the existing ones or if we should just have toggles (ie EnableV20ApplicationCapabilities() and Disable...)         *Acceptance*    I should be able to call these functions to modify a config transaction and then process further configuration updates on the modified config transaction. The examples test should be updated to demonstrate usage of this feature.     "
Answer: 17065.0

User story: "As a user of the Fabric channel configuration API, I would like to be able to retrieve existing orderer, application, and channel capabilities from a config transaction.         *Acceptance*    I should be able to call a function for retrieving orderer, application, and channel capabilities that returns a config.Capabilties."
Answer: 8866.0

User story: "Currently we pass a config object around to every update/API function, lets wrap the config proto so this:  {code:java}  err := UpdateOrdererConfiguration(config, orderer)  {code}  becomes something like  {code:java}  err := config.UpdateOrdererConfiguration(orderer){code}   "
Answer: 18738.0

User story: "As a user of the Fabric channel configuration API, I would like to be able to retrieve existing policies for an organization without manually parsing the config transaction.         *Acceptance*    I should be able to call a function for retrieving policies for a specific org (regardless of application/orderer/consortium org). The example test should also be updated to demonstrate usage of this helper."
Answer: 4220.0

User story: "As a fabric administrator, I want to use a fit-for-purpose library that can modify an existing channel configuration to remove an orderer endpoint from an orderer org's config group.    Acceptance:   Starting with an existing Config block/transaction, I can call a function that removes an orderer endpoint from the configuration. After performing that operation, I can compute a ConfigUpdate transaction that is ready for a signature workflow. An appropriate example should also be added to the example test that demonstrates this behavior."
Answer: 19914.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 administrator, I want to use a fit-for-purpose library that can modify an existing channel configuration to add an orderer endpoint to an orderer org's config group.    Acceptance:   Starting with an existing Config block/transaction, I can call a function that adds an orderer endpoint to the configuration. After performing that operation, I can compute a ConfigUpdate transaction that is ready for a signature workflow. An appropriate example should also be added to the example test that demonstrates this behavior."
Answer: 19897.0

User story: As a fabric administrator, I want to verify that a cert was issued by my organization's MSP before adding it to the MSP's revocation list.    Acceptance:   Provided with a config block/transaction, I can call a function to "revoke" a certificate issued by an MSP. This should result in a configuration update that appropriately modifies the {{revocation_list}} attribute of {{FabricMSPConfig}}.    Providing a certificate that has not been issued by the MSP should result in an error.
Answer: 27610.0

User story: "config as a package name isn't very descriptive of what this package is. We should consider renaming the package to something more appropriate for what it actually does (maybe configtx?)"
Answer: 64715.0

User story: "As a user of the Fabric channel configuration API, I would like to be able to retrieve existing msp configuration for an organization without manually parsing the config transaction so I can reuse CA certs or other relevant information.         *Acceptance*    I should be able to call a function for retrieving msp configuration for a specific org. The example test should also be updated to demonstrate usage of this helper."
Answer: 15572.0

User story: "As a fabric administrator, I want to use a fit-for-purpose function that adds an application org definition to a channel configuration. The result of this function should be a channel transaction that can be passed to other functions that can further mutate the config.    *Acceptance*    Calling the new function with appropriate arguments should generate a config transaction that contains a new application org. The examples test should also be updated to demonstrate usage of this feature."
Answer: 30181.0

User story: "As a fabric administrator, I want to use a fit-for-purpose function that adds an orderer org definition to a channel configuration. The result of this function should be a channel transaction that can be passed to other functions that can further mutate the config.    *Acceptance*    Calling the new function with appropriate arguments should generate a config transaction that contains a new orderer org. The examples test should also be updated to demonstrate usage of this feature."
Answer: 15496.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 user of the Fabric channel configuration API, I would like to be able to update a consortium org's, consortiums group's, and consortium group's configuration by adding or removing policies.         *Acceptance*    I should be able to call this function to modify a config transaction and then process further configuration updates on the modified config transaction. The examples test should be updated to demonstrate usage of this feature.     "
Answer: 23003.0

User story: "As a user of the Fabric channel configuration API, I would like to be able to update an orderer org's and orderer group's configuration by adding or removing policies.         *Acceptance*    I should be able to call this function to modify a config transaction and then process further configuration updates on the modified config transaction. The examples test should be updated to demonstrate usage of this feature.     "
Answer: 23004.0

User story: "As a user of the Fabric channel configuration API, I would like to be able to update an application org's and an application group's configuration by adding or removing policies.         *Acceptance*    I should be able to call this function to modify a config transaction and then process further configuration updates on the modified config transaction. The examples test should be updated to demonstrate usage of this feature.     "
Answer: 23010.0

User story: "As a user of the Fabric channel configuration API, I would like to be able to retrieve existing application, orderer, or consortium org configuration without manually parsing the config transaction so I can persist values I don't want to change when updating an org's configuration.         *Acceptance*    I should be able to call a function for retrieving an application, orderer, or consortium org's configuration that returns a config.Organization. I can then modify fields on the Organization and pass it to an appropriate update organization function to update the org's configuration. The example tests should also be updated to demonstrate usage of this helper."
Answer: 21449.0

User story: "As a user of the Fabric channel configuration API, I would like to be able to retrieve existing orderer configuration without manually parsing the config transaction so I can persist values I don't want to change when updating orderer configuration         *Acceptance*    I should be able to call a function for retrieving orderer configuration that returns a config.Orderer. I can then modify fields on the Orderer configuration and pass it to config.UpdateOrdererConfiguration to update the orderer's configuration. The example tests should also be updated to demonstrate usage of this helper."
Answer: 31751.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 user of the Fabric channel configuration API, I would like to be able to retrieve existing anchor peers without manually parsing the config transaction.         *Acceptance*    I should be able to call a function for retrieving anchor peers for a specific org. The example test should also be updated to demonstrate usage of this helper."
Answer: 6103.0

User story: "As a user of the Fabric channel configuration API, I would like an example in the library documentation that shows me idiomatic usage of the package to create new channel create transactions and sign them.         *Acceptance*    I can find an example for creating create channel transactions in the GoDoc for the package."
Answer: 14419.0

User story: "As a user of the Fabric channel configuration API, I would like an example in the library documentation that shows me idiomatic usage of the package to create configuration updates and sign them. The updates should involve multiple changes to instruct on how state is managed.         *Acceptance*    I can find an example for updating channel transactions in the GoDoc for the package. It should also sign the config update envelope."
Answer: 20400.0

User story: "As an administrator, I want to use a fit for purpose library to add a new root CA certificate to an MSP configuration.    Acceptance:  Starting with a configuration transaction/block, I can call a function that adds CA certificate to the MSP configuration. After this operation, I should be able to create a config update transaction that is ready for the signature workflow.    Minimal certificate validation should be done when processing the function. In particular, reject certificates that is missing the KeyUsageCertSign/CA attributes."
Answer: 31816.0

User story: As a fabric administrator, I want to use a fit for purpose library to generate a configuration update that revokes a certificate issued by my organization's MSP.    Acceptance:   Provided with a config block/transaction, I can call a function to "revoke" a certificate issued by an MSP. This should result in a configuration update that appropriately modifies the {{revocation_list}} attribute of {{FabricMSPConfig}}.
Answer: 31822.0

User story: "As a fabric administrator, I want to use a fit-for-purpose library that can modify an existing channel configuration to remove an anchor peer.    Acceptance:  Starting with an existing Config block/transaction, I can call a function that removes an anchor peer from the configuration. After performing that operation, I can compute a ConfigUpdate transaction that is ready for a signature workflow.    https://hyperledger-fabric.readthedocs.io/en/release-1.4/channel_update_tutorial.html#updating-the-channel-config-to-include-an-org3-anchor-peer-optional"
Answer: 8799.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 administrator, I want to use a fit-for-purpose library that can modify an existing channel configuration to add an anchor peer.    Acceptance:  Starting with an existing Config block/transaction, I can call a function that adds an anchor peer to the configuration. After performing that operation, I can compute a ConfigUpdate transaction that is ready for a signature workflow.    https://hyperledger-fabric.readthedocs.io/en/release-1.4/channel_update_tutorial.html#updating-the-channel-config-to-include-an-org3-anchor-peer-optional"
Answer: 10332.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: Despite the fact that the ledger is immutable and that you can spread nodes around to different Geos to reduce risk of disaster.  Users are still asking for backup/restore capability for a few reasons:  1 - Human Error.  Accidental Deletion for example.  2 - Code issues where it's easier to revert the ledger vs undo damage.  3 - Corporate requirements that anything in prod must have a tested backup/restore plan.         This is easy when not using Private Data collections.  Keep the peers behind the ordering nodes and everything works fine.  If you ever need to restore the ordering service for example, you can either stand up new peers and let them catch up, or restore the peers to an earlier backup to speed up the process and avoid having to redo chaincode/channel operations.          The issue is when using PDCs, there's no good way to orchestrate a backup because the orderer being behind the peers of course still doesn't work, and the peers being behind the orderer doesn't really work either.      To fix this, I believe you have 3 options:    1 - Stop all peers and orderers to ensure consistency, back everything up, start it up again.  This of course causes an outage with every backup, which is bad and is hard to orchestrate given that different organizations own the peers.    2 - Restore the peers to a point earlier than the orderers.  This doesn't work without work on the user because the orderer will have hashes for private data that the peers no longer have and the peers will keep trying to fetch the data.  My understanding is to fix this the user would have to do blind writes to the PDC in their application.    3 - Roll back the ledgers on the orderering nodes  to a height that matches that of the "highest" peer.  This is preferred to rolling back peers because it matches the restore flow for non PDC of always keeping the orderers ahead of peers, and because there will normally be less ordering nodes owned by less organizations than the peers.  So the rollback process would be easier.    The point of this story is to provide the ability to perform option 3 above in Fabric.  In addition to the ability to be able to roll back the orderer to a specific block height on a ledger, some additional code/doc would be needed to help users figure out how far to roll back each channel.    Alternatively, if it can be proven that option 2 above is an easier/better way to get back to a consistent state and code/instructions can be provided to do that, that could also suffice.      To be very clear.  No one is expecting the PDC or any other data that was lost in the restore process to be recovered.  It's a restore from backup.  Everyone understands that anything done after the backup is gone forever and this would only be done/recommended as a last resort.  The goal of this issue is to be able to restore fabric to a consistent state such that operation can continue cleanly going forward.          
Answer: 151387.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 administrator, I want to use a fit-for-purpose function that adds an org definition to a named consortium in system channel configuration. This result of this function should be a channel update transaction that can later be signed.     Acceptance    Calling the new function with appropriate arguments should generate a config update transaction that semantically matches one produced by the process that uses {{configtxgen}} {{-printOrg}}, {{protolator}}, and {{configtxgen}}.    This story is only concerned with adding the org to the consortium - not creating a channel.    Most of the manual steps are documented here: https://hyperledger-fabric.readthedocs.io/en/release-2.0/channel_update_tutorial.html"
Answer: 13100.0

User story: "As a fabric administrator, I want to use a fit-for-purpose library function to calculate a ConfigUpdate message that would update a {{base}} config to the {{modified}} config. This function should not need to be provided with anything beyond the two transactions.    Acceptance    Calling the new function with appropriate arguments should generate a {{ConfigUpdate}} that is semantically equivalent to the output of {{configtxlator compute_update}}.    See https://hyperledger-fabric.readthedocs.io/en/release-1.4/channel_update_tutorial.html for the current manual process."
Answer: 24563.0

User story: "As a fabric administrator, I want to use a fit-for-purpose library function to generate a ConfigGroup representing an Organization. The input to the function should not depend on existing MSP material but should accept directly the necessary cryptographic material.    Acceptance    Calling the new function with appropriate arguments should generate a proto structure that is semantically equivalent to one generated by {{cryptogen}} and {{configtxgen -printOrg}}."
Answer: 24573.0

User story: "As a fabric administrator, I want to use a fit-for-purpose library to generate a channel update transaction that modifies the {{max_message_count}} batch size parameter. The channel update transaction that is generated should not be signed.    Acceptance    Calling the new function with appropriate arguments should generate a config update transaction that matches one produced by manually transforming and generating a configuration update using the existing tools (ignoring any signature that may be applied by the existing tools)."
Answer: 34401.0

User story: As a fabric admin, I want to take a {{ConfigUpdate}} transaction and a collection of detached signatures and use them to create a complete, signed channel config update transaction that can be validated by the orderer and the peers.    Acceptance:    The generated configuration transaction should be equivalent to one generated by "building up" signatures in order using the existing `signtx` command on the peer.
Answer: 34402.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 admin, I wish to sign a {{ChannelUpdate}} transaction and generate a detached signature. The key material used to sign the transaction should be one of the input parameters and should not be derived from configuration.    Acceptance:    Calling the new function with appropriate arguments generates a detached signature that I can use later as one of the _n_ required signatures when assembling the configuration update transaction."
Answer: 33015.0

User story: "As a fabric administrator, I want to use a fit-for-purpose library to generate a channel creation transaction from input data structures. This library should not make assumptions about how any key material is stored and should not require network access.    Acceptance:    Calling a function similar to what we have below returns a proto-encoded genesis block that roughly matches that produced by {{configtxgen -channelID channel-id -profile profile-name ...}} using a prototypical {{configtx.yaml}} from our integration test suite.    Generating a genesis block from the configtx.yaml and an msp folder, and using code implemented in this story, I should get two `proto.Equal` blocks.    {code}  type Profile struct {   Consortium   string   Application  *Application   Orderer      *Orderer   Consortiums  map[string]*Consortium   Capabilities map[string]bool   Policies     map[string]*Policy  }    ...    type Option func(options)    // Options for extensibility  type options struct {}    func CreateChannelTx(channelSpec ChannelConfig, options ...Option) (*cb.Block, error) {    // Implement me  }  {code}    The types that are listed above come from the {{genesisconfig}} package in fabric and appear to be managed through a combination of viper and yaml processing. We do not want to use these packages directly; we want to copy and adapt the necessary structures into our package."
Answer: 34421.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-17303  defaulted private data dissemination policies requiredPeerCount=0 and maxPeerCount=1 for implicit org-specific private data collections. However depending on number of peers your org has, and the amount of redundancy you desire for storing private data, you may want your peer to override these defaults with values in peer's core.yaml, for example:    {code:java}  peer.gossip.pvtData.ImplicitCollectionDisseminationPolicy.requiredPeerCount  peer.gossip.pvtData.ImplicitCollectionDisseminationPolicy.maxPeerCount  {code}    The override will apply to all channels the peer has joined. The implication is that requiredPeerCount has to be smaller than the number of peers in a channel that has the lowest numbers of peers from the org (this should be mentioned in the doc and/or core.yaml comments).    Acceptance criteria:    If requiredPeerCount or maxPeerCount are specified locally in core.yaml, when peer endorses a proposal that writes to its OWN implicit collection,  these values override the default values of 0 and 1 for disseminating private data.    Note that FAB-17491 will ensure that peer does not disseminate private data targeted for OTHER organization's implicit collections.  "
Answer: 35966.0

User story: "Add barebones test (FAB-17350) into daily suite. "
Answer: 8906.0

User story: The TLS cert section of the configuration is outdated. We need to change the key_path, cert_path, root_cert_path to "client_key", "client_cert" and "root_cert" respectively. Also all should be PEM encoded strings.
Answer: 80027.0

User story: "In many scenarios, chaincode needs to perform access control. The chaincode requester certificate information including MSPID is already available to chaincode. In some scenarios chaincode needs to determine whether the client requestor is from the same org as the peer, for example when determining whether to return private data from a peer's implicit collection. Therefore, this story will make the peer's MSPID available to chaincode."
Answer: 6447.0

User story: "Many tests will need to change to use the new interfaces, to remove the install/instantiation steps and replace with approve/commit etc. In the current format, that means editing lots of runCases files and json test description files under CITest/ directory. In the new system test framework for k8s, it means changing the test input specification file. In addition, the tools and command functions must all be added. There will likely be many pieces to merge for this."
Answer: 200508.0

User story: "Today, if the orderer does not have any channels defined, it panics because it cannot find the system channel.  This story is to remove those startup checks to allow the orderer to start successfully, even though it will not be in a position to accomplish anything.  This should also block channel creation requests if no system channel is defined to route them to."
Answer: 24562.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: Currently the Private Data Collections get defined when instantiating the Chaincode using the "collections-config" option, e.g.     _--collections-config "/opt/gopath/src/github.com/hyperledger/fabric/peer/config/private-data-collections.json"_       This implies, that you have to reinstantiate the Chaincode every time you make a change to the Private Data Collections Definition.    The goal is to decouple the Private Data Collections from the Chaincode instantiation, so that you can dynamically add, remove and update Private Data Collections without having to reinstantiate the Chaincode.    Therefore, I suggest three new SDK methods:   * addPrivateDataCollection   * updatePrivateDataCollection   * removePrivateDataCollection          
Answer: 134970.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: "Current *peer lifecycle chaincode approveformyorg* does not seem to output any information of the specified package ID to both the standard output on the console and the peer logs, when the command is executed successfully.    The following is an example of the current peer logs for approved definition.  {code:java}  Successfully approved definition sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (), name 'fabcar', on channel 'mychannel'  {code}       As a Fabric admin, at least, I want to see the output of the specified package ID for approved definition in the peer logs as follows.  {code:java}  Successfully approved definition sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (), name 'fabcar', package ID 'fabcar_1:a6b61184ef66929c1b6e6ad657c248e9ba6283080eb59250a93e1706eeffe981', on channel 'mychannel'  {code}  The log message will be useful for the following scenarios:   - The message can help Fabric admins to confirm the applied package ID later without recording the command history with the parameters on their console   - The message can help Fabric admins to quickly notice operation mistakes on the applied package ID especially when environment variables are interpolated in package IDs (e.g., empty package ID)"
Answer: 7397.0

User story: "Similar to using service discovery to determine the endorsers needed to meet a user-defined chaincode's endorsement policy, we should also be able to use it to discover the endorsers required to commit a chaincode definition using _lifecycle.    Acceptance:  - Query _lifecycle on a specific channel and receive the valid list of endorsers required to meet the endorsement policy. (Version does not come into play.)    The list of endorsement should match the active configuration. This will likely involve creating a test with a non-standard _lifecycle endorsement policy."
Answer: 30165.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, when a client queries discovery with an endorsement query which has collections in the query, discovery intersects the available peers with the collection definition by removing peers which are not part of the collection since they do not have the pre-images required to read from the namespace.    However, the introduction of *GetPrivateDataHash* makes new use cases possible, namely scenarios where some of the endorsers of a transaction aren't in the collection, but they are fed with the pre-image via other means (e.g the transient field) and after validating the pre-image using *GetPrivateDataHash*, they can perform the same computation as peers that are in the collection. In such a case, discovery will filter out those peers needlessly.    Furthermore, we want to be able to support writes to collections that have their own endorsement policy, while at the same time the membership of the collections might not even intersect (e.g if we have an org specific collection and we want to delete a key from collection "orgA" and write it into collection "orgB").    The above use cases require the ability to convey to discovery not to filter out peers based on collection association.    Additionally and independently, we sometimes want to do a chaincode-to-chaincode transaction where some of the chaincodes are used for read only, and then we don't want to take into account the endorsement policy, however it can be useful if discovery would still be aware of this so it can filter out peers that do not have the chaincode installed.    To support all the above, I propose to add 2 new flags (3 and 4 below) in the [ChaincodeCall|https://github.com/hyperledger/fabric-protos/blob/master/discovery/protocol.proto#L156] protobuf message:  {code:java}  message ChaincodeCall {      string name = 1;      repeated string collection_names = 2;      bool no_private_reads = 3; // Indicates we do not need to read from private data      bool no_public_writes = 4; // Indicates we do not need to write to the chaincode namespace  }  {code}  Adding these 2 booleans will preserve backward compatibility to Fabric versions 1.4 and below, but will enhance the expression power to support more use cases.         [~<USER>
Answer: 142766.0

User story: "Org-specific implicit collections are used by v2.0 lifecycle, and can also be used by user chaincodes. Traditional collections allow for configuration properties such as *requiredPeerCount* and *maxPeerCount* to specify private data dissemination behavior, for example to require that private data has been disseminated for redundancy as a condition for successful endorsement.     Without an ability to configure properties on implicit private data collections in v2.0, we'll have to live with reasonable defaults. This story will update the defaults for explicitly defined collections and implicit collections to be:  requiredPeerCount = 0  maxPeerCount = 1"
Answer: 34815.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 types section of [https://hyperledger-fabric.readthedocs.io/en/master/developapps/wallet.html] needs updating to match the new wallet API and structure in v2.0 of the Node (and Java) SDK. The key differences are:   * Wallet types are defined only by their backing store, not by the type (HSM or non-HSM) of identity they hold.   * There are three wallet types: file system, in-memory and CouchDB.   * All wallet types can hold both HSM and non-HSM identities.   * All of the wallet types are created using factory function on the new Wallets class. Individual implementation classes are not exposed.         All of the above information is captured on a new tutorial page in the SDK docs: [https://hyperledger.github.io/fabric-sdk-node/master/tutorial-wallet.html]    Hyperlinks to wallet information on that page are all out-of-date. Node SDK documentation is now located at [https://hyperledger.github.io/fabric-sdk-node/master/]"
Answer: 42693.0

User story: "In v2.0 an option to specify endorsement policy at collection level is added. Therefore service discovery for endorsements at collection level also needs to take the collection level endorsement policy into consideration.    This will require an API to get endorsement policy given chaincode and collection name."
Answer: 172878.0

User story: "With the introduction of external builders, docker should no longer be necessary.    To ensure that's true and that it remains the case, implement an integration test that explicitly removes any docker configuration from the peer and uses the binary builder in our integration tests to run an end-to-end scenario."
Answer: 22033.0

User story: "Per https://gerrit.hyperledger.org/r/c/fabric/+/34401#message-eccb8901_793a8c92    The protolator decoration stuff https://github.com/hyperledger/fabric/blob/33139a966bb75377f65c5d9dc990619bd80ca22d/common/tools/protolator/protoext/decorate.go is currently missing any sort of tests.    Some changes would be caught by integration tests, but a more  basic level of unit testing, ensuring that we are not accidentally omiting decoration of a type we intend to decorate would be nice."
Answer: 146719.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: Chaincode execution is currently managed through RuntimeLauncher. The launcher needs to be extended to include a "Stop" verb to properly disconnect from / shutdown running chaincode that is launched through the external/container/platform packages.
Answer: 93594.0

User story: There is a state listener in the new lifecycle that tracks when chaincode is invocable (or not). Today, when a chaincode becomes invocable, we call the custodian to start it... A similar call needs to be made when a chaincode is no longer invocable to request the custodian to stop it.    The lifecycle cache already has a reference counted list of channel references to chaincode.    Acceptance:  1. Install chaincode with a name and package-ID "A"  2. Define chaincode  3. Install chaincode with name and package-ID "B"  4. Upgrade chaincode definition to "B"  5. Observe that chaincode container for package-ID "A" is stopped.    This story applies to internal platform chaincode and externally built and launched chaincode.
Answer: 111152.0

User story: "As a user  I want a transaction to be invalidated if an endorsing peer has tampered read set  So that tampered data is not propagated among other peers         The read set contains only the keys and the versions of the data read during chaincode execution. Thus if the world state of let's say single endorsing peer was tampered, all peers will commit an updated invalid value. On the other hand, if along with the versions there were values in the readset, the peers could compare them with their own and discard a transaction if needed.    the use case is well described in the article     [https://medium.com/@kctheservant/exploring-the-behaviour-of-hyperledger-fabric-when-world-state-is-tampered-764676fe90f2]"
Answer: 234365.0

User story: When using the new lifecycle to install chaincode, if the build fails due to timeout or some other reason such that the "endorsement" fails at the peer, the chaincode package should be removed from the local file system.    This prevents an odd behavior where the invoke of a chaincode that failed to build (during install) succeeds.
Answer: 16053.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 a lot of certs to keep up with in fabric and when they expire, it's exceedingly bad.    The issue is fabric does nothing to help with this that I've seen.    I have heard that with Raft, the orderer will log when the raft TLS certs are about to expire.  Can the same be done for enrollment certs for all components?         One possible issue here is if every component is logging cert expiration warnings, that could get pretty chatty in the logs.  My counter argument here is if it were my prod environment and the certs were about to expire, I think I would want it to be pretty chatty.  Also I think we could limit the time that the logging starts to maybe 1 week before the certs expire?  I think if you get that close, you'd want to be notified even if it's noisy.         Another better option if it's possible might be to provide a metric for cert expiration time.    Then a user could monitor this in a graph and set alerts if it gets below a certain threshold and also control how they get alerted based on the remaining time (page if < 1 week, slack if < 2 weeks for example)  Finally, the metrics approach would cause much less noise than the logs.         The holy grail might be to do both, since metrics is better, but requires more knowledge by the operator to enable, whereas logs you get pretty much for free."
Answer: 5597.0

User story: "  1) We'd like to understand whether Fabric applications currently produce any of the below event logs and what these are.     (appreciate that not every one of these will be universally applicable to Fabric constituents)    * Privileged user commands and activities  * Security and audit policy changes  * User logon failure  * User logon success  * Service account logon failure  * Service account logon success  * User or group added  * User or group deleted  * User or group modified  * User password change  * User role modified  * Concurrent user sessions  * Persistent user session  * Unauthorised activity attempt  * Unauthorised data modification / modification attempt  * System time change    2) Then more generically, is there a class of security events that may be deemed 'suspicious' that any of the Fabric constituents currently produce?    "
Answer: 247323.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 CA Test Engine (fabric-test/tools/CTE/) contains crl_test.sh and mycatest.sh, scripts to test the timings and operations of the CA. Since it only requires code in the CA repository, it belongs not in fabric-test repo but in fabric-ca repo.    The maintainers of fabric-ca may of course make final decision about whether to keep or abandon the tool and when to trigger the scripts. This proposal is to move the CTE tool to the fabric-ca repo, where it can be used by developers to catch errors immediately. We propose also to continue to execute the existing CTE daily test job until an alternative job in fabric-ca is provided to execute these tests.    On master branch AND in release-1.4:   * +fabric-ca+:  Add CTE (and any useful parts of the Makefile/Readme information) to fabric-ca repo   * +CI+: modify the CI daily job for CTE, to find the scripts in the fabric-ca repo., and to be triggered when appropriate.   * +fabric-test+: Remove all references to CTE tool and tests from the Makefile and README and regression/daily/ and regression/smoke/.   * +fabric-test+: Remove fabric-test/tools/CTE/.    Refer to the CTE test results of the daily job here: [https://jenkins.hyperledger.org/view/fabric-test/job/fabric-test-daily-ca-master-x86_64/] "
Answer: 255199.0

User story: "The Orderer Test Engine (OTE) tool is an extension of a developer tool. System tests can be done using other available test performance tools (e.g. fabric-test tools NL, PTE, and Operator, and HFRD), so we seek to remove the burden of maintaining this tool. Clean up the following, on master branch AND in release-1.4 :   * +CI+:  Abandon the daily CI job for fabric-test OTE tests (Note: it should be already abandoned in master branch; remove it from 1.4 too.)   * +CI+: Remove the OTE results from the fabric-test daily results job   * +fabric-test+: Remove all references to OTE tool and tests from the Makefile and README and regression/daily/ and regression/smoke/.   * +fabric-test+: Remove fabric-test/tools/OTE/"
Answer: 61575.0