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: "Current PTE init service discovery regardless the setting of targetPeers.  Indeed, no need to init service discovery if the targetPeers is not discovery, i.e. user specified the target peers for the transactions."
Answer: 11844.0

User story: "The request was made to dump the memory usage between each test run in the system behave framework."
Answer: 45890.0

User story: "When the discover CLI returns the local peers (channel-less) query - it also prints ledger height as zeros and chaincodes as nils, since these are not set."
Answer: 103530.0

User story: "Alpine is the recommended base OS for Docker images.  It is generally more secure than other distros (i.e. typically does not have any vulnerabilities) and is much smaller than other distros."
Answer: 237337.0

User story: "The golang discovery client implementation only caches the last signature, and for maximum performance gains we should cache more to be able to take advantage of the peer side credential cache "
Answer: 17370.0

User story: "Increase test coverage for fabric/common/cauthdsl/"
Answer: 817380.0

User story: NewDeliverClientForOrderer() has two error return points like below:  {code:none}  func NewDeliverClientForOrderer(channelID string) (*DeliverClient, error) {      var tlsCertHash []byte      oc, err := NewOrdererClientFromEnv()      if err != nil {          return nil, errors.WithMessage(err, "failed to create deliver client")      }        dc, err := oc.Deliver()      if err != nil {          return nil, errors.WithMessage(err, "failed to create deliver client")      }     ...  {code}                                                      The first error message mentions "deliver client" but what it actually means is "orderer client".
Answer: 366778.0

User story: "The gossip communication layer has an API which allows to send a message to a peer given an endpoint and a PKI-ID.    If the remote peer presents a different PKI-ID from what is given in the Send() method - the connection aborts.  This keeps on until the peer eventually purges the PKI-ID from its memory, however it may take ~ 30 minutes.    This is problematic for cases in which a peer has renewed his certificate and now its PKI-ID has changed. Ideally we could identify if the certificate belongs to the same peer, but there is no API for that in the MSP as GetIdentifier() is implemented as a hash over the raw certificate.     A trivial solution for this problem that I think is good enough is to not abort the connection in case the peer still belongs to the organization that it belonged to beforehand. "
Answer: 4646.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: "Here's a small sample of tests that fail when running with the race detector running.  {code:java}  --- FAIL: TestGossipDiscoveryStopping (1.05s)  testing.go:730: race detected during execution of test{code}  {code:java}  --- FAIL: TestUpdate (1.93s)  testing.go:730: race detected during execution of test{code}  {code:java}  --- FAIL: TestGossipDiscoverySkipConnectingToLocalhostBootstrap (3.03s)  testing.go:730: race detected during execution of test{code}  {code:java}  --- FAIL: TestSelf (0.04s)  testing.go:730: race detected during execution of test{code}  {code:java}  --- FAIL: TestMemRespDisclosurePol (3.10s)  testing.go:730: race detected during execution of test{code}  {code:java}  --- FAIL: TestConnect (10.63s)  testing.go:730: race detected during execution of test{code}  {code:java}  --- FAIL: TestGetFullMembership (16.89s)  testing.go:730: race detected during execution of test{code}  {code:java}  --- FAIL: TestDisclosurePolicyWithPull (18.37s)  testing.go:730: race detected during execution of test{code}"
Answer: 891581.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: "[~<USER>  created a great video describing some private data concepts, beyond what is covered in the Private Data tutorial and I think the information would be beneficial to the community. We could link to the video, in a For more information....  link.    [https://ibm.box.com/s/j4vkrfcsajoouy85vob9w5aznfwe5vfn]    The video is published on YouTube https://www.youtube.com/watch?v=qyjDi93URJE    I'm talking to Mark P about that.         [~<USER>"
Answer: 11764.0

User story: "Clarify documentation for private data limitations wrt types of queries supported."
Answer: 2799.0

User story: "Our lawyers have a specific requirement that our organization's use of Fabric['s Docker images] requires that OSS licenses be included *within* the images and that I be able to provide paths for each image to the OSS licenses on the image.        An admittedly cursory review (assuming 'LICENSE') of the images (excl. NPM as this appears to diligently include package LICENSEs) shows that few LICENSE-named files are included:    {{./opt/go/LICENSE}}  {{./opt/go/misc/tour/static/lib/codemirror/LICENSE}}  {{./opt/go/src/cmd/vendor/github.com/google/pprof/LICENSE}}  {{./opt/go/src/cmd/vendor/github.com/ianlancetaylor/demangle/LICENSE}}  {{./usr/local/LICENSE}}  {{./usr/share/doc/git/contrib/persistent-https/LICENSE}}         Even for the Hyperledger Fabric components, multi-stage builds remove the sources from the runtime images (including LICENSE).    Request:   * Licenses be included in the images (if not already)   * Licenses be readily enumerable, i.e. find -name LICENSE   * Some affirmation that the images contain definitive lists of OSS licenses    I'm willing to pursue with our attorneys (legally) considered alternatives that are being employed by this community|others."
Answer: 645973.0

User story: "Transaction simulator should provide simulation block height.    In v1.2, the endorser gets the simulation height separately, and passes it with the private data dissemination and to transient store (where the block height information is used for purging decisions). It would be better if the transaction simulator provides the block height.    For more details see:    https://gerrit.hyperledger.org/r/#/c/23767"
Answer: 825531.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: For test purposes I was trying to use the {{cauthdsl.AcceptAllPolicy}} policy when instantiating my CC.    image tag: 1.2.0-rc1  channel: my-channel  cc: my-cc  cc-version: 1    {code:java}  AcceptAllPolicy = Envelope(NOutOf(0, []*cb.SignaturePolicy{}), [][]byte{})  {code}    peer log:  {code:java}  Invalid policy, either Identities([]) or Rule(n_out_of:<> ) are empty:  {code}    As a result the {{fabric-sdk-go}} (not related to this issue) returns  {code:java}  error getting channel response for channel [my-channel]: Discovery status Code: (11) UNKNOWN. Description: error received from Discovery Server: error getting endorsers from target [localhost:7051]: failed constructing descriptor for chaincodes:<name:\"my-cc\" > "  {code}    more peer logs:  {code:java}  2018-06-27 12:55:31.735 UTC [discovery] validateStructure -> DEBU 1545a Received request from 172.18.0.1:44948  2018-06-27 12:55:31.736 UTC [discovery/lifecycle] Metadata -> DEBU 1545b Returning metadata for channel my-channel , chaincode my-cc : {my-cc 1 […] […] []}  2018-06-27 12:55:31.737 UTC [discovery/lifecycle] Metadata -> DEBU 1545c Returning metadata for channel my-channel , chaincode my-cc : {my-cc 1 […] […] []}  2018-06-27 12:55:31.737 UTC [discovery/DiscoverySupport] PolicyByChaincode -> WARN 1545d Invalid policy, either Identities([]) or Rule(n_out_of:<> ) are empty:  2018-06-27 12:55:31.737 UTC [discovery/endorsement] computePrincipalSets -> DEBU 1545e Policy for chaincode ' name:"my-cc"  'doesn't exist  2018-06-27 12:55:31.737 UTC [discovery/endorsement] PeersForEndorsement -> WARN 1545f Principal set computation failed: policy not found  2018-06-27 12:55:31.737 UTC [discovery] chaincodeQuery -> ERRO 15460 Failed constructing descriptor for chaincode chaincodes:<name:"my-cc" > ,: policy not found  2018-06-27 12:55:31.738 UTC [discovery] validateStructure -> DEBU 15461 Received request from 172.18.0.1:44948  2018-06-27 12:55:31.739 UTC [discovery/lifecycle] Metadata -> DEBU 15462 Returning metadata for channel my-channel , chaincode my-cc : {my-cc 1 […] […] []}  2018-06-27 12:55:31.739 UTC [discovery/lifecycle] Metadata -> DEBU 15463 Returning metadata for channel my-channel , chaincode my-cc : {my-cc 1 […] […] []}  2018-06-27 12:55:31.739 UTC [discovery/DiscoverySupport] PolicyByChaincode -> WARN 15464 Invalid policy, either Identities([]) or Rule(n_out_of:<> ) are empty:  2018-06-27 12:55:31.739 UTC [discovery/endorsement] computePrincipalSets -> DEBU 15465 Policy for chaincode ' name:"my-cc"  'doesn't exist  2018-06-27 12:55:31.739 UTC [discovery/endorsement] PeersForEndorsement -> WARN 15466 Principal set computation failed: policy not found  2018-06-27 12:55:31.739 UTC [discovery] chaincodeQuery -> ERRO 15467 Failed constructing descriptor for chaincode chaincodes:<name:"my-cc" > ,: policy not found  2018-06-27 12:55:31.836 UTC [gossip/election] waitForInterrupt -> DEBU 15468 […] : Exiting  {code}
Answer: 827121.0

User story: "Update the policy topic for Architects,Operators and Application Developers"
Answer: 753647.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: "peer help text is generated using:  {code:java}  make help-docs{code}  Need to document the process so that people don't try to update the help docs manually, or if they do, we can give them a pointer on the correct process.  Perhaps the /docs/README.md would be a good place, although I'll defer to doc team.           The /docs/README.md may also need some other cleanup as well."
Answer: 929876.0

User story: "When trying to run the longrun (FAB-10853) with mutual tls and service discovery in the network with 1.2.0-rc1 load, observed the logs from pvtdatastorage saying about the purging the private data in blocks in peers logs as shown below  {code:java}  2018-06-26 04:58:35.148 UTC [kvledger] CommitWithPvtData -> INFO 28e Channel [testorgschannel1]: Committed block [599] with 10 transaction(s)  2018-06-26 04:59:00.175 UTC [kvledger] CommitWithPvtData -> INFO 28f Channel [testorgschannel1]: Committed block [600] with 10 transaction(s)  2018-06-26 04:59:00.175 UTC [pvtdatastorage] func1 -> INFO 290 Purger started: Purging expired private data till block number [600]  2018-06-26 04:59:00.175 UTC [pvtdatastorage] func1 -> INFO 291 Purger finished  2018-06-26 04:59:25.147 UTC [kvledger] CommitWithPvtData -> INFO 292 Channel [testorgschannel1]: Committed block [601] with 10 transaction(s)  2018-06-26 04:59:50.164 UTC [kvledger] CommitWithPvtData -> INFO 293 Channel [testorgschannel1]: Committed block [602] with 10 transaction(s)  {code}  Looks like it is trying to purge the private data in blocks for every 100 blocks.         If not core.yaml is the right file to look for this parameter, where can we find the information for this parameter and how to set it?     "
Answer: 133961.0

User story: "New topic covering application development."
Answer: 92123.0

User story: "Currently, chaincode argument generation logic (based on {{ccType}}) is hardcoded in the PTE execution engine ({{pte-execRequest.js}}). We need to decouple this logic so that the execution engine is application-agnostic. We can move the argument-generation logic to separate files corresponding to the application ID."
Answer: 53661.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "When the chaincode policy does not contain the same set of MSPs as the collection policy then the following error is returned from the endorsers query on the Discovery service:    'Principal set computation failed: chaincode isn't installed on sufficient organizations required by the endorsement policy'.    Instead of an error, I would suggests that the endorser groups be prioritized according to those in which the greatest number of peers have read-access to the collection, and return the group with the highest priority.    Consider the following example:    MSP1: (peer1,peer2)  MSP2: (peer3)  MSP3: (peer4)    CC policy: (MSP1 AND MSP2) OR MSP3  Collection policy: MSP1, requiredPeerCount=1    The possible endorser groups based on chaincode policy are:    (peer1,peer3), (peer2,peer3), (peer4)    There is no group in which ALL of the peers have read-access to the collection, but I would expect  either group (peer1,peer3) or group (peer2,peer3) to be returned, since peer1 and peer2 have read-access to the collection.    Further, let's say that peer3 is not available, then I would expect the group (peer4). The endorsement would succeed with (peer4) since the private data would be pushed to peer1 and/or peer2, satisfying the collection's requiredPeerCount of 1.  "
Answer: 10889.0

User story: "In [https://github.com/hyperledger/fabric/blob/master/core/peer/peer.go#L126-L139], the panic messages all appear to be formatted to print just the channel id at the beginning. The second and third panics, however, print the entire Configtxvalidator() object.     See attached log for an example of the messy output, which was captured while CI was having an issue grabbing the correct images, resulting in 1.2 capabilities being attempted on a v1.1 peer."
Answer: 9989.0

User story: "Docker images associated with Fabric are VERY large >1GB.    In a scenario where these images aren't cached|cacheable pulling the set is a substantial volume of bandwidth. In environments where Fabric is deployed to ephemeral machines or a dynamically scaling environment, moving these images around is impeded by their size. The broader surface of functionality additionally broadens the attack|vulnerability surface.    The base is Ubuntu and image have a JVM added. IIUC not all the images require this broad set of OS|application functionality; the pure Golang components could be statically built, combined with a minimal init and delivered as 2 process images.  h3. Propose   * Consider reducing the base image – ideally to scratch or perhaps Google's distroless   * Add minimal additional runtimes e.g. JVM only to images that require it   * Consider busybox as a self-contained and minimal toolset for debugging variants"
Answer: 650381.0

User story: "Desire to run perf measurements of sampCC chaincode, scaling the # of KV reads/writes. This will provide more sample performance profiles that our customers can utilize to better size their needs. Also potentially expose some scaling issues within fabric. "
Answer: 830037.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "[https://hyperledger-fabric.readthedocs.io/en/master/releases.html]     "
Answer: 3925.0

User story: "Add a new what's new section to the documentation - possibly as a topic in the TOC immediately after the Introduction highlighting what we've delivered for this release and links to the content in the docs."
Answer: 24610.0

User story: "Dave asked us not to use the term SideDB in the docs, but rather use the term 'private data'.    We have 1 reference to sideDB in the private data key concept, so that if someone searches on the term sidedb, they will be taken to the appropriate content.         However, Barry noticed that the search also returned a hit in the Introduction and was confused because there is no doc topic called SideDB.         I'd like to remove the reference to sideDB in the Introduction. This sentence:         Fabric is also working on two sets of features that are intended to improve upon its privacy and confidentiality capabilities, specifically: private data – a feature we call SideDB, and zero knowledge proofs (ZKP).    to    To improve upon its privacy and confidentiality capabilities, Fabric has added support for <link: private data> and is working on zero knowledge proofs (ZKP) available in the future.          "
Answer: 4096.0

User story: "Some of the links in README.md are outdated in the master branch (release-1.1 branch was already fixed)."
Answer: 98.0

User story: Currently, the stub.GetStateByRange(startKey, endKey) works with simple keys only.     The following code in fabric/core/chaincode/shim/chaincode intentionally made it not to work with composite keys.  However, there are use cases that we need to query range of a partial composite key.  So, we should remove the restriction of simple-key from this method, or add another public method for GetStateByPartialCompositeKeyRange, so we can do range queries on composite keys.     // GetStateByRange documentation can be found in interfaces.go  func (stub *ChaincodeStub) GetStateByRange(startKey, endKey string) (StateQueryIteratorInterface, error) \{      if startKey == "" \{          startKey = emptyKeySubstitute      }      if err := validateSimpleKeys(startKey, endKey); err != nil \{          return nil, err      }      collection := ""      return stub.handleGetStateByRange(collection, startKey, endKey)  }
Answer: 86182.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 story corresponds to the 'Define' step in the design document from FAB-8787.    The implementation should add a new chaincode function called {{Define}} which accepts a new message as its only parameter.  This message should have a single field, corresponding to the {{Definition}} message as defined in FAB-10726.  It should return a new empty message.    It should read from the organizations private store the key at <hash> and verify that each the messages are equal or fail.  It should use protobuf equality checking rather than direct bytes comparison.    Next, it should check to see whether the world state key <chaincode_name> is set.  If so, it should should read the bytes there, unmarshal it as a chaincode definition, and check that the sequence contained in the new definition is exactly one larger than the existing sequence number or fail.  If the key does not exist, it should ensure that the sequence number is 0 or fail.    Finally, it should marshal the definition and store it at world state key <chaincode_name> and return the empty message successfully."
Answer: 353309.0

User story: "Move the environment variable information in this section:   [http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#environment-variables]    to after you have started the docker container:    [http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#create-join-channel]         Otherwise, users get errors when they run peer channel create (see -FAB-10690-)"
Answer: 2544.0

User story: This corresponds to the 'InstallChaincodeMetadata' step described in the FAB-8787 design document.    This chaincode API should be called {{AgreeToDefine}} and should accept as input a message containing a single field {{Definition}} which is itself a protobuf message with the fields:  # Name as a string  # Version as a string  # Sequence an unsigned 64 bit integer  # Hash as bytes (corresponding to the hash returned by FAB-10725)  # Endorsement plugin as string  # Validation plugin as string  # ValidationParameter as bytes    The chaincode API should return an empty protobuf message.    The function should first verify that the user is an administrator of the org per the channel configuration.  Then it should then take the {{Definition}} and put it in the organization's private data collection at key "<hash>".    Note, the ability to write to an org scoped collection does not exist at the time of writing this story, but should be implemented via FAB-8864.
Answer: 353318.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 new lifecycle system chaincode needs to expose a function to allow the installation of ChaincodeInstallPackages.    It should take as a parameter a message containing the name, version, and ChaincodeInstallPackages.  It should return a message containing the hash of the code package.    The chaincode function name should be {{InstallCodePackage}}    Both the input and output should be new protobuf messages so that we may use the protobuf versioning mechanisms to extend and deprecate fields.    It should declare a new interface which declares the dependency on the function provided by FAB-10720 to store the package."
Answer: 219426.0

User story: "FAB-10720 introduces a way to persist chaincode packages onto the filesystem and FAB-10723 introduces a way to retrieve those packages by hash.    However, users may not know the hash of their installed chaincode by may only know the friendlier name/version. In this case, we will need to be able to look up the hash by name/version. Once the correct hash is known, the existing API for retrieving the code bytes themselves may be used.    The implementation should accept name/version as parameters, and return a byte slice which is the hash."
Answer: 60238.0

User story: "FAB-10720 introduces a way to persist the chaincode install packages.  In order for this to be useful, this persistence mechanism must also allow chaincodes to be retrieved.    The implementation should accept a package hash (corresponding to the hash of the marshaled chaincode install package) and retrieve the package itself, as well as the stored name and version associated with this package."
Answer: 39983.0

User story: "As part of the new lifecycle work, there is a new chaincode package format as defined via FAB-10719.  In order for the new life cycle to use this new package format, it needs a way to persist these code packages.    The existing persistence is done through the ccprovider package, however, because of the legacy and problematic nature of this code (package scoped state and functions), and the irrelevant details like instantiation policy, extending the existing mechanisms is likely to be more work than simply creating a new persistence system.    This new persistence should take as a parameter a name, a version, and a set of bytes.  This set of bytes is a marshaled form of the the new message from FAB-10719.    The persistence should use the existing configurable chaincode storage directory to store chaincodes, but instead of storing them as '<name>.<version>' as the current code does, it should store the marshaled package and the package name/version as {{<hash_of_chaincode_install_package>.bin}} and {{<hash_of_chaincode_install_package>.json}} respectively.    The implementation should be careful not to expose these details to the user.    The implementer should evaluate whether creating a new file in the ccprovider package, or simply creating a new package is more sensible for this work."
Answer: 35478.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 new lifecycle work will need a way to store chaincode to the filesystem.  Today, the peer stores chaincode either in a CDSPackage or SignedCDSPackage, both of which are inappropriate for the new lifecycle.    These existing package formats include references to legacy datastructures that do not make sense in the new lifecycle world, such as instantiation policy, and conflate things which identify the chaincode (ie, its name, version, and hash) with properties of the chaincode itself (such as its type, and code).    This should be a new protobuf message named {{ChaincodeInstallPackage}}. which includes:   # {{Type}} as a string (ie, go, java, node)   # {{Path}} as a string (as required by some of the current platform packages)   # {{CodePackage}} the package itself as bytes (typically a tar file)."
Answer: 22701.0

User story: "add make docker-tag-stable target/recipe so that we can retag an image as 'stable' in CI"
Answer: 52754.0

User story: "The text in this doc –- in addition to its title — refer explicitly to v1.1.    We need a doc with a non-specific name and to change the text to refer to v1.2."
Answer: 1401.0

User story: Currently, the peer cli binary outputs:    ``` 2018-06-18 13:30:53.104 EDT [main] main -> ERRO 001 Fatal error when initializing core config : error when reading core config file: Unsupported Config Type ""   ```    For a new user, a fabric user used to using a fabric sdk, this poses a somewhat opaque first message.    Proposal is to improve the error output of the config check in peer/main.go when no FABRIC_CFG_PATH value is provided, to its previous output prior to:    [https://github.com/hyperledger/fabric/commit/ea5971a0ebaca110745437a4aad5ea64e9ce59bd]    while keeping the above default functionality, and improving the other cli tools that share useage of core/config/ to return the same error when no fabric_cfg_path is provided, or the configName value passed (e.g. "core", "orderer", "configtx") doesn't exist with any file extension.
Answer: 839667.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: "      *Actual :  Error: got unexpected status: BAD_REQUEST – Attempted to include a member which is not in the consortium when trying to create channel with empty name.*    *Expected: peer channel create command should have failed argument validation with error when $CHANNEL_NAME is empty and aborted channel creation but it seems it continues and fails with a error that does not clearly indicate root cause of failure.*    *Please see attached logs for details.*         Followed steps in here [http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html] but did not set CHANNEL_NAME.    **but getting error on executing    ```peer channel create -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/channel.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem```    ```     root@29ec3dc3d76d:/opt/gopath/src/github.com/hyperledger/fabric/peer# echo $CHANNEL_NAME     Note: $CHANNEL_NAME is not set    root@29ec3dc3d76d:/opt/gopath/src/github.com/hyperledger/fabric/peer# env | grep CORE    CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt    CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key    CORE_PEER_LOCALMSPID=Org1MSP    CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock    CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt    CORE_PEER_TLS_ENABLED=true    CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/<EMAIL>/msp    CORE_PEER_ID=cli    CORE_LOGGING_LEVEL=DEBUG    CORE_PEER_ADDRESS=peer0.org1.example.com:7051         root@29ec3dc3d76d:/opt/gopath/src/github.com/hyperledger/fabric/peer#     Please see attached logs for details"
Answer: 840019.0

User story: "GetTransactionById returns the transaction including validation status.    In the rare case that the same transaction id gets submitted a second time, that submission will automatically get invalidated.  GetTransactionById will continue to return the initial valid transaction.  This can be confusing to the client that (accidentally) submitted the duplicate.  To make this more clear, it would be better to utilize a new API like GetTransactionsById which could return all the transactions and their statuses matching the transaction id.    See FAB-8557 for more context."
Answer: 841460.0

User story: "'gotools' are not installed when following the official guidance to set up dev environment, 'make dist-clean all'"
Answer: 844106.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 orderer currently does not handle SIGTERM or any other signals which might be sent to the process to allow it to shutdown gracefully.  We should really add a handler which at the very least prints the signal and announces that the process is exiting, but ideally, that also shuts down resources like Sarama etc."
Answer: 238834.0

User story: "After adding a collection configuration to a channel's chaincode at instantiate time, need ability to retrieve the current collection configuration from a peer.  This is needed for example if you'd like to alter the collection configuration in a subsequent chaincode version."
Answer: 91061.0

User story: "As titled, for dynamic deployment, I attempted to use these steps   * create a new CA 'ca.NewConsensus'   * generate orderer crypto material for new orderer 'orderer0.NewConsensus', generate new Admin user also   * request channel update to system channel 'testchainid' to add new orderer organization 'NewConsensus' with msp name 'newConsensus', msp id 'NewConsensusMSP'   * request channel update to add a new orderer address to existing list   * bootstrap docker container for 'orderer0.NewConsensus'    As in attached log file, the orderer cannot catch up with existing chain from kafka message     "
Answer: 519569.0

User story: "The orderer for listing Root CAs *ORDERER_GENERAL_TLS_CLIENTROOTCAS*. It expects a list of certificates. When setting in docker compose, the certificates are a comma separated list within brackets. [/data/org0-ca-chain.pem]    The peer for listing Root CAs *CORE_PEER_TLS_CLIENTROOTCAS_FILES*. In the yaml file, it also expects a list, but in docker compose, when using a comma separated list within brackets, the following error occurs:  {code:java}  Error: Failed to get client TLS config: Failed to read '/var/hyperledger/orderer/[/var/hyperledger/configs/ca.org0-cert.pem': open /var/hyperledger/orderer/[/var/hyperledger/configs/ca.org0-cert.pem: no such file or directory{code}"
Answer: 846684.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: make all generates following error:    .build/bin/peer  peer github.com/hyperledger/fabric/peer  CGO_CFLAGS=" " GOBIN=/cygdrive/i/go/src/github.com/hyperledger/fabric/.build/bin go install -tags "experimental" -ldflags "-X github.com/hyperledger/fabric/common/metadata.Version=1.2.0-snapshot-efbe29f6a -X github.com/hyperledger/fabric/common/metadata.BaseVersion=0.4.8 -X github.com/hyperledger/fabric/common/metadata.BaseDockerLabel=org.hyperledger.fabric -X github.com/hyperledger/fabric/common/metadata.DockerNamespace=hyperledger -X github.com/hyperledger/fabric/common/metadata.BaseDockerNamespace=hyperledger -X github.com/hyperledger/fabric/common/metadata.Experimental=true" github.com/hyperledger/fabric/peer  cannot install, GOBIN must be an absolute path  make: *** [Makefile:259: .build/bin/peer] Error 1    Solution: In Makefile, command    $(CGO_FLAGS) GOBIN=$(abspath $(@D)) go install -tags "$(GO_TAGS)" -ldflags "$(GO_LDFLAGS)" $(pkgmap.$(@F))    should be broke into 3 lines as:    $(CGO_FLAGS)    GOBIN=$(abspath $(@D))    go install -tags "$(GO_TAGS)" -ldflags "$(GO_LDFLAGS)" $(pkgmap.$(@F))
Answer: 847387.0

User story: "Below link says '_It retrieves *four* platform-specific binaries'_ but the list shows 6 bindaries being downloaded instead. Not clear if 4 of 6 are platform-dependent while 2 or not, OR, a typo. Being binaries, my guess is four needs be changed to six.    [https://hyperledger-fabric.readthedocs.io/en/release-1.1/samples.html#download-platform-specific-binaries]          "
Answer: 829460.0

User story: "Currently each chaincode platform is implemented as a package under {{core/chaincode/platforms}}. Each chaincode platform implements the {{Platform}} interface.    Whilst looking for the chaincode platform specific chaincode start commands, I found that this was implemented elsewhere in a big {{if}} block in {{ContainerRuntime.LaunchConfig}}.    It would be easier to find and cleaner if the chaincode start command was in the chaincode platform specific code instead!"
Answer: 156770.0

User story: "The function that performs a bulkupload of docs to couchdb  `{color:#000000}commitUpdates{color}` ([https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/statedb/statecouchdb/commit_handling.go#L92)] monolithic in the sense that it retries committing the individual doc if the bulkupload fails. This makes it hard to write a test to make sure that bulkload works in a regular scenario (see related bug - FAB-10558).    This function and the code that uses this should be refactored such that a unit-test can be written to verify this."
Answer: 852573.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 function `{color:#000000}BatchRetrieveDocumentMetadata{color}` returns a results-set that contains one entry for each key. ([https://github.com/hyperledger/fabric/blob/master/core/ledger/util/couchdb/couchdb.go#L1434).]    However, for the keys that are not present in the db, the result-set contains empty entries (empty in the sense that they don't even include even the key). The entry should either contain key or the entire entry should be removed. Otherwise, this is unnecessary cause confusion in the statecouchdb layer (e.g., the revision map gets filled with an empty entry "":"").    This is how this empty entry looks like   ```  \{   ID: (string) "",   Rev: (string) "",   Version: (string) "",   AttachmentsInfo: (json.RawMessage) <nil>  }  ```
Answer: 852579.0

User story: "{color:#191f25}Fabric uses software based digital signature by default. The clear text of private key is exposed in file system and memory, which is insecure. Although Fabric does have support for pkcs11 HSM now, user needs to prepare HSM which is an additional work.   {color}    {color:#191f25}This proposal is to leverage intel SGX enclave to protect digital signature computing and private key, which is a high performance and integrated security solution in x86 system with intel SGX feature.{color}"
Answer: 855103.0

User story: (2 comments from Kostas):    Low-priority observations attached, we can merge for now.  [docs/source/fabric_model.rst|https://gerrit.hyperledger.org/r/#/c/22691/2/docs/source/fabric_model.rst]  Line [16|https://gerrit.hyperledger.org/r/#/c/22691/2/docs/source/fabric_model.rst@16]:  "enable private and confidential multi-lateral transactions that are usually required by..."    Because I'm not sure what constitutes a low degree of privacy or confidentiality.  Line [119|https://gerrit.hyperledger.org/r/#/c/22691/2/docs/source/fabric_model.rst@119]:  (achieve?)
Answer: 26.0

User story: "*Edited 13/03/2019 to reflect the changes made to Golang's toolchain*    Now that modules are enabled by default in Golang v1.12, the Fabric team should consider what changes need to be made to the project to support this new dependency management system. You can read more about 'Go Modules' on the [Golang Wiki|https://github.com/golang/go/wiki/Modules].    Unlike existing dependency management tools such as 'govendor' or 'dep', modules are built into the toolchain and the go command itself. When you run 'go build', dependencies will automatically be downloaded for you (like dep does). Instead of a `Gopkg.lock` and `Gopkg.toml` files, 'go modules' use `go.mod` and `go.sum` files to track dependencies.    Adding module support will also allow things like vendored chaincode dependencies to be automatically downloaded and imported into our binary during install. This means *no more vendoring!*    Related:  - [FAB-8841|https://jira.hyperledger.org/browse/FAB-8841]  - [FAB-13667|https://jira.hyperledger.org/browse/FAB-13667]"
Answer: 980230.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: "Need to run benchmark on Channel Client operations using a real user (not mocked) to ensure the GO SDK is performing well."
Answer: 55070.0

User story: "Current MockStub does not implement _GetDecorations() _  This would be useful for chaincode development that uses decorators."
Answer: 56078.0

User story: "[http://hyperledger-fabric.readthedocs.io/en/latest/configtx.html#configuration-updates]  {noformat}  Channel: (version 0)      Orderer (version 0)      Appplication (version 3)         Org1 (version 2){noformat}  _Appplication_ mis-spelled."
Answer: 848172.0

User story: "{color:#205081}_..._{color}    {color:#205081}_We will leverage a script to spin up *our* network._ {color}    Somewhere else,     {color:#205081}_..._ {color}    {color:#205081}_First let’s start *your* network:_{color}    {color:#333333}Probably update above line with 'our'.{color}"
Answer: 2816.0

User story: "Current PTE test summary report shows only Total transactions but does not show successful and failed transactions. We have seen 503 instantiation failures during the test but PTE did not capture that in summary report. It will be helpful to include information that will help determine success or failure of PTE test.          ======= PTE 0 main Test Summary: executed at Fri Jun 01 2018 18:02:08 GMT+0000 (UTC) =======   (defaultchannel:sample_cc_ch1): INVOKE transaction stats   (defaultchannel:sample_cc_ch1): Total transactions 12396 timeout transactions 0   (defaultchannel:sample_cc_ch1): start 1527876160814 end 1527879765271 duration 3604457 ms   (defaultchannel:sample_cc_ch1): TPS 3.44   (defaultchannel:sample_cc_ch1): peer latency stats (endorsement)   (defaultchannel:sample_cc_ch1): total transactions: 12396 total time: 603378 ms   (defaultchannel:sample_cc_ch1): min: 12 ms max: 10007 ms avg: 48.67521781219748 ms   (defaultchannel:sample_cc_ch1): orderer latency stats (transaction ack)   (defaultchannel:sample_cc_ch1): total transactions: 12396 total time: 424656 ms   (defaultchannel:sample_cc_ch1): min: 5 ms max: 8476 ms avg: 34.25750242013553 ms   (defaultchannel:sample_cc_ch1): event latency stats (end-to-end)   (defaultchannel:sample_cc_ch1): total transactions: 12396 total time: 12953484 ms   (defaultchannel:sample_cc_ch1): min: 115 ms max: 11632 ms avg: 1044.972894482091 ms"
Answer: 122367.0

User story: "In the consensus interface, the config sequence (and message type) are not signed.    In a BFT setting, this allows nodes to modify config sequences or message types, and thus e.g. commit transactions that were using old configurations."
Answer: 65682.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: Error: Unsupported config type error on peer version  {code:java}  ibmadmin@build-vm:/opt/gopath/vb1st/src/github.com/hyperledger/fabric/build/bin$ ./peer version  2018-06-02 21:00:42.397 EDT [main] main -> ERRO 001 Fatal error when initializing core config : error when reading core config file: Unsupported Config Type ""{code}  Below is the orderer version  {code:java}  ibmadmin@build-vm:/opt/gopath/vb1st/src/github.com/hyperledger/fabric/build/bin$ ./orderer version  orderer:   Version: 1.2.0-snapshot-08e5958   Go version: go1.10   OS/Arch: linux/amd64   Experimental features: true{code}  fabric# 08e5958
Answer: 79901.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: "With IdeMix being deferred to 1.3, it's necessary to make sure that IdeMix documentation isn't merged into the live docs."
Answer: 38.0

User story: "in the peer/channel package,it defines the const like `EndorserRequired,EndorserNotRequired,OrdererRequired,OrdererNotRequired,PeerDeliverRequired,PeerDeliverNotRequired`,but the peer/chaincode package need it too    `"
Answer: 610669.0

User story: "none of the existing tests appear to require multiple endorsers"
Answer: 25993.0

User story: "homebrew-fabric should be the latest version"
Answer: 7118.0

User story: "It is observed that on install chain code failure, PTE does not abort..instead it continues to instantiate chaincode steps etc. If install itself has failed, PTE should abort. In general, it will be good to have error handling implemented to abort test on critical failures such as install failure.     "
Answer: 611217.0

User story: "Even when network_setup.sh script is passed a variable for channel name, it still reports a WARNING with down operation. Need a minor fix to remove the WARNING message."
Answer: 865993.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 per issue "FAB-10479 - "Blind Writes" not mentioned in the docs / faqs" BlindWrites can be an issue for unwary chaincode developers at present. Therefore, a new API is proposed to better represent the intent behind the code written. The proposal is that "PutState()" is deprecated, and new "CreateState()" and "UpdateState()" APIs are introduced. This would allow a chaincode developer to indicate if they are expecting a new key to be created vs an existing key to be updated. This would prevent the BlindWrite problem as Fabric could catch and reject calls where the current state of the world state did not match the intent.       CreateState("x", ...) - Precondition key "x" must not exist. If at the time this API is called at simulation time in an endorser, key "x" does exist, an error will be returned. This API will also cause an entry for key "x" to be present in the both the Read and Write parts of the RW Set. This means that if the precondition changes before commit it will be caught in the VSCC and rejected.       UpdateState("x", ...) - Precondition key "x" must exist.  If at the time this is called at simulation time in an endorser, key "x" does not exist, an error will be returned. This API will also cause an entry for key "x" to be present in the both the Read and Write parts of the RW Set. This means that if the precondition changes before commit it will be caught in the VSCC and rejected.       Essentially these APIs will enforce an "every write must have a matching read" semantic against the world state.       Using the example from issue FAB-10479, the code would change to:    {{queryThing("x") \{}}   {{  //return thing "x" if it exists}}   {{}}}       {{createThing("x") \{}}   {{  //call CreateState("x") to create thing "x" enforcing the "x" does not previously exist}}   {{}}}       {{updateThing("x") \{}}   {{  //call UpdateState("x") to update thing "x" enforcing the "x" must previously exist}}   {{}}}    
Answer: 866166.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: "*Noted: The work is still in drafting, welcome to add comments in the spec.*    Currently, Fabric controls the access using policies. However, there is no unique governing model, i.e., different governing policies are implemented following different policy models and may involve several components. E.g., some policies are defined in the channel as configurations, with guaranteeing some Reader, Writer, Admin roles, while other policy like node are defined in system chaincodes, chaincode policies are defined in user input and executed by system chaincodes.    It will be easy to confuse what policies are supported, what roles are guarantees, and what operations can be done with given resource.    Even the experimental RSCC [] is finally deprecated, partially due to unclear governing model.    In this spec, we want to provide a unique governing model for all important resources in the network, following the same process and capabilities.    More details can be found at    [https://docs.google.com/document/d/14xSD-qoaZkuTK8447dlBViJidJE58j9t4_NO3hCTz7A/edit#heading=h.o41wsif4iwbv]"
Answer: 866313.0

User story: "Currently BYFN does not support ACLs. But it should."
Answer: 867361.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: "Move the channels topic - there is probably some editing that can be done in here too - for example we might want to mention the new capability to have private data on channel."
Answer: 1062419.0

User story: "New conceptual topic for transaction, bring some already existing material on transactions. Will be in Key Concepts section of TOC. "
Answer: 868731.0

User story: "New conceptual topic for chaincode, bring together some already existing material on chaincode.  Will be in Key Concepts section of TOC."
Answer: 855486.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: "For a new contributor, fabric's contribution guide is too complex.     How about adding a efficient one which like cello's, and in the end of guilde, we can tell reader refer to original contribution guide for details .     [https://github.com/hyperledger/cello/blob/master/docs/CONTRIBUTING.md]      What do you think? Is it necessary?    [~<USER> [~<USER> [~<USER>"
Answer: 870220.0

User story: "Add a script to check the Go version before building native binaries peer, orderer, configtxgen, cryptogen, and configtxlator. This is helpful to users just starting off with the project.    This gives a nice error message rather than just failing to compile.    $ make    ERROR: fabric requires Go version 1.10+. Please update your Go installation:    [https://golang.org/dl/]"
Answer: 413026.0

User story: "1. The order/README.md needs to be placed under the main doc folder  2. Fix broken links"
Answer: 872279.0

User story: "The discovery service requires clients to be able to generate an ephemeral TLS certificate when they don't have one.         To ease the usage of the discovery CLI, we would want to reuse existing code that already does that."
Answer: 2594.0

User story: "FAB-4045 PTE test case needs to configure Kafka replication setting as KAFKA_DEFAULT_REPLICATION_FACTOR=5.  But NL uses a number of brokers as replication setting. NL doesn't support to change replication setting. "
Answer: 17580.0

User story: "Add new v1.3 MSP version, for which SatisfiesPrincipal will be enhanced to handle the extended version of MSPPrincipal. Even though this feature is planned for v1.2, it will be hidden behind a v1.3 channel capability, which will not be introduced until v1.3. It will therefore not be possible to create a v1.3 MSP before that, and Anonymous and Combined Principals will not be recognized by v1.2 X.509 MSPs."
Answer: 8872.0

User story: "Parallel integration test execution fails today due to port conflicts. Local processes and port mapping’s should not use hard-coded ports but should reserve a port from a range. Once this is done, we *should* be able to run the tests within a suite in parallel."
Answer: 490878.0

User story: "We store the revocation key in PEM format, which is simpler for compatibility with the java sdk."
Answer: 9715.0

User story: "Today it is rather tedious to do version upgrades in fabric, because a channel reconfiguration transaction must be constructed by hand, sometimes adding additional elements like ACLs to bring the system up to a new base level.    These config updates could be computed automatically by configtxgen, simplifying life for our  users.    As a rough flow, the user could pass in the latest config block for a channel and either pass in a target version, or a target profile.  Then configtxgen could compute the necessary update to upgrade the channel and write it out, like the anchor peers update."
Answer: 875918.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 {{configtxgen}} tool has enhancements to print the org definition in JSON format to make editing channel configs easier.  It would also be helpful for it to print the value definition for policies defined in the global policy section as well.    A very similar syntax to the {{-printOrg}} could be used, simply naming a policy rather than an org name."
Answer: 875931.0