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: CLI query response contains "*Query Result :* " and "*\n*" which makes difficult to parse output from things like query system chaincode using protobuf or tools like configtxlator. rather it would be easier to parse the raw output using these tools.  {code:java}  peer chaincode query -o orderer0.example.com:7050 -C mychannel -n qscc -c '{"Args":["GetBlockByNumber","mychannel","1"]}'  {code}  Enclosed the response [^block.pb]
Answer: 90992.0

User story: "As [~<USER> described , copying content from [here|https://jira.hyperledger.org/browse/FAB-8193]  {code:java}  The configuration parameter in configtx.yaml, Orderer addresses is an enumeration of orderer which clients and peers should use to connect to ordering. It is not an exhaustive list of orderers, and adding and removing nodes from this list has no impact on their participation in ordering. This is a deliberate feature by design, as it may be desirable to configure hot spare orderers, or to remove an orderer from the list for maintenance, recovery etc.    To disconnect an orderer from Kafka, standard Kafka access control measures may be leveraged, such as TLS CRLs, or firewalling. If the orderer system and its key material were compromised, its certificate should be added to the orderer's MSP's CRL.  {code}  This needs to be captured both in the configtx.yaml and the readthedocs."
Answer: 30219.0

User story: "Endorsement Policy test document [^Endorsement_policy_verification_testcases_v1.1.0-preview.pdf]    Test cases include the simulation of insufficient proposal responses (simulated with the help of passing target peers or stopping endorser containers) and RW sets mismatch in those proposals (simulated with the help of peer file system tampering and non-deterministic chaincode)    Tests were performed on fabric, fabric-ca and fabric-samples/balance-transfer v1.1.0-preview version, with the attached patch [^endorse_test_code_changes_v1.1.0-preview.txt]         Patch intention: is to pass peer names from the client side and to prove that if RW Sets differs from endorsers (and if there is no check at client side for RWset equality), state changes are applied based on the last endorser's RWset.    This patch is useful, especially for Objective 2: Policy where endorsement from one of the two organizations is sufficient."
Answer: 1021829.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: In the upgrade doc http://hyperledger-fabric.readthedocs.io/en/master/upgrade_to_one_point_one.html#update-fabric-ca-binary ,    in section "Update Peer Binaries", near sentence `Next, remove all Docker chaincode images.`,    I think we might want to add some more words explaining why it is necessary to delete the images (The chaincode container will fail to connect, maybe explaining a reason or maybe not).    But it is more complicated than that, because my real objective is, per FAB-7915 , for those new words to also mention the same requirement - i.e. to remove the chaincode images - when changing peer binary version from v1.1 DOWN to v1.0.x (when backing down / aborting an upgrade, which is allowed if done before the config updates (PONR)).    We tested this; the chaincode container would fail to connect; chaincode container logs will show `Error starting Simple chaincode: error trying to read file content : open : no such file or directory`    I am not sure if this location in the identified doc is the correct place for adding error messages and detailed explanations for troubleshooting, but hopefully a short explanation could be added; otherwise, is there somewhere else to put such details?
Answer: 21472.0

User story: In mold of "Adding an Org to a Channel" tutorial, take people through CRLs (documenting concepts as well as providing script based on the Fabric-CA network – BYFN will not work with a CRL tutorial since it is not compatible with fabric-ca-client).    Will need commands and accompanying script, as doc should follow template of providing a script and taking people through concepts and the steps one at a time.
Answer: 1006414.0

User story: "Document fabric-ca-server commands, following template found here:    http://hyperledger-fabric.readthedocs.io/en/latest/peer-commands.html"
Answer: 45809.0

User story: "Document fabric-ca-client commands, follow template found here:    http://hyperledger-fabric.readthedocs.io/en/latest/peer-commands.html"
Answer: 24617.0

User story: "Document all configtxlator commands, following this template:    http://hyperledger-fabric.readthedocs.io/en/latest/peer-commands.html"
Answer: 21423.0

User story: "Document all configtxgen commands, following framework found here:    http://hyperledger-fabric.readthedocs.io/en/latest/peer-commands.html"
Answer: 21425.0

User story: "List all commands possible with cryptogen, following basic framework found here:    http://hyperledger-fabric.readthedocs.io/en/latest/peer-commands.html"
Answer: 54806.0

User story: Topic was put together somewhat rushed – could use improvement:    [http://hyperledger-fabric.readthedocs.io/en/latest/peer-commands.html]    Nevertheless this is the basic framework that should be followed for all "commands" docs.
Answer: 24549.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: "BYFN is a nice sample but would be even more user friendly if it had images that accompany the creation of the network (especially in the second half as it is being build iteratively).    <USER>is working on this with Anthony O'Dowd (following image styling being established in new conceptual documentation)."
Answer: 1013910.0

User story: "Need to get API reference into the documentation to help developers."
Answer: 99157.0

User story: "Plan is to fold in current documentation under this organizational model (following overall guideline that documentation should be divided into three major categories (with sub categories underneath) - Concepts, Tasks, and Reference:    [https://github.com/FabricTOC/FabricTOC/blob/master/docs/Guide/Guide.md]    Current docs are noted with an asterisk."
Answer: 231589.0

User story: Since instructions on upgrading and updating are being spread across several docs, necessary to have a place that can point to which docs people should be looking at to find these steps and what order to do them in.    What's New" should also discuss more generally what is new in v1.1 (beyond capabilities and the process to update/upgrade). This will rely heavily on the wiki:    https://wiki.hyperledger.org/projects/fabric/proposedv1_1
Answer: 57869.0

User story: "We would like to submit a patch for balance-transfer to test endorsement policy.    *Patch details:* Attached [^endorse_test_code_changes_v1.0.4.txt] is created for fabric-samples/balance-transfer *release* version with git commit level  b99e1b8da2bc4d17f689c152078d96e8f6428a27 to test/understand endorsements policy working on fabric v1.0.4 version.    Patch incorporates code that passes/sends endorsement request to endorsement peers from *all* organizations (which needs to endorse the transaction). Without the patch endorsement request is sent to only 1 organization peer(s) based on the organization pertaining to the JWT token passed.    Details on applying patch and testing are documented in the attached pdf [^Endorsement_policy_verification_testcases_v1.0.4.pdf]    *Need for patch:* From balance-transfer code exploration, it is found that existing helper.js code (for loop, where clients, channels are initialized) maintains separate client objects for each organization, in which channel object is present and to the channel object organization peers are added. Due to which target peers are populated only for that organization.    Events from second organization peers are not considered here, to avoid MSP related error.    p.s: The patch is a tweak for balance-transfer code (b99e1b8da2bc4d17f689c152078d96e8f6428a27) to test endorsements. But, similar changes can be applied to test endorsement policy for fabric v1.0.0 to v1.0.4."
Answer: 800693.0

User story: "add releases and link to release roadmap to README"
Answer: 72202.0

User story: "http://docs.couchdb.org/en/2.1.1/api/database/find.html#db-index for more details and info.  "
Answer: 1028416.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: PTE document:   1) Recommend clarifying the fact that in section "running PTE" it should run from the installed location under {{fabric-test/fabric-sdk-node/test/PTE}} instead of {{fabric-test/tools/PTE}}    2) from the readme, replace all hardcoded gopaths with generic paths e.g. remove {{root/gopath}} with {{$GOPATH}}   3)  in the section "creating a local Fabric network", the first bullet point is actually a prerequisite, and the next two steps are either-or. This section should be formatted accordingly to avoid confusion.   4) Add sub-section for "if you are using mac" in the pre-requisite section with the following info:    Only for Mac, you need to install a gnu-compatible version of the  awk, date utility:   * Install Brew: [http://brew.sh|http://brew.sh/]   * run {{brew install gawk —-with-default-names; brew install gdate —-with-default-names}} in order to swap out Mac's default tar command for a gnu-compliant one.     This will be deferred for a future CR:  PTE code:   1) replace all instance of hardcoded path with generic paths eg replace {{/home/ibmadmin/gopath/}} with {{$GOPATH}}
Answer: 5996.0

User story: "Kindly, review the google document; and feel free to pitch in with ideas.  Suggest better mechanisms, and solutions.         https://docs.google.com/document/d/1J59WRPDT_DxcyKEA-_QUnFs7SGwVipz7x5cJ5y2nGS4/edit?usp=sharing"
Answer: 813312.0

User story: "Currently the MSP allows to identifier the orderer nodes by their organisational units. This functionality does not match the way fabric currently works. Indeed, orderer nodes are named explicitly, given that their identities needs to be known to the entire network. "
Answer: 678.0

User story: "The ote tests are named with format FAB-wxyz. To make it easier for a user to know what each one does, and to more easily verify the output data, it would be helpful to lengthen the names. For an example of the places to be modified in order to do that, refer to FAB-7936 update [https://gerrit.hyperledger.org/r/#/c/17365.] For example we gave detailed names to two of them, *FAB-7936_100tx_3ch_3ord_3kb* and *FAB-6996_1ch_solo*. Refer to the help text returned by the runote.sh tool, which is one easy way to run the ote tests, which identifies the available tests which can be renamed.         fabric-test/tools/OTE$ ./runote.sh -??  ./runote.sh: illegal option – ?  Invalid option: -  Usage:   ./runote.sh [opt] [value]   -t <testcase (default=FAB-6996_1ch_solo)>    Examples:   ./runote.sh # run the default testcase FAB-6996_1ch_solo  ./runote.sh -t FAB-6996_1ch_solo # basic test with 1 channel, 1 solo orderer  ./runote.sh -t FAB-7936_100tx_3ch_3ord_3kb # short test covering OTE functionalities    The supported testcases are:   FAB-6996_1ch_solo   FAB-7070   FAB-7024   FAB-7071   FAB-7026   FAB-7072   FAB-7027   FAB-7073   FAB-7036   FAB-7074   FAB-7037   FAB-7075   FAB-7038   FAB-7936_100tx_3ch_3ord_3kb   FAB-7076   FAB-7039   FAB-7077   FAB-7058   FAB-7078   FAB-7059   FAB-7079   FAB-7060   FAB-7080   FAB-7061   FAB-7081     "
Answer: 302050.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: "It would be nice if we can add newer chaincodes to demonstrate usage and purpose of following shimAPI for user/testers to consume these API.  {code:java}  GetBinding    GetCreator  GetTxTimeStamp  GetSignedProposal  GetTransient  GetTxID  GetDecorations  SetEvent{code}"
Answer: 1029946.0

User story: "Gossip tests run sequentially since some tests in different packages use the same port ranges.    The easiest and most cost-effective thing would be to just make a pass on the tests and assign different port ranges between packages.    [~<USER> wdyt? "
Answer: 48899.0

User story: "Gossip currently creates a real ledger instance for the state transfer tests, and it should ideally use a mock ledger instance to isolate the logic as much as possible.      [~<USER>"
Answer: 51708.0

User story: "There are many vendored packages which have not bee upgraded since the project began, e.g. viper.    As part of FAB-7083, dependent packages should be upgrade to the latest version possible"
Answer: 346733.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 several improvements that can be made to endorsement policies. To start with the simplest, endorsement policy for a chaincode is specified at the time of instantiation. There is no way to update except to do an "upgrade" using a different endorsement policy. This could be a workaround but has the following drawbacks   * disrupts service    * user have to go through the instantiation process just to update a policy     One example of need to update the policy is when the channel membership changes. A new member may not have invoke capability based on existing endorsement policy (see --FAB-5893--).     We could consider two types of enhancements just in terms of   * flexible ways to specify an endorsement policy during instantiation   ** e.g., "*.Admin" instead of "Org0.Admin or Org1.Admin"... of course this needs dynamic evaluation at commit time)   ** e.g. instead of named organizations in the endorsement policy, allow any 1 org, any 2 orgs, majority of orgs, etc. (see FAB-12292)   * ability to set the endorsement policy separately. This is trickier as the EP is part of the chaincode fingerprint    Beyond the above "update" requirement, there are several other enhancements that can be considered. From a list gathered from elsewhere   * Named endorsers is brittle wrt adding organizations   * In the real world endorsement often depends on data content, asset ownership, etc. (see FAB-8812)   * With multiple similar chaincodes managing endorsement policy individually is painful   * Current default endorsement policy default is entirely inadequate and allows arbitrary state manipulation even without executing chaincode   * Endorsement policy is tied to chaincode version so modifications require installing a second copy of the chaincode at a new version   * Providing a good dynamic default of all orgs is impossible   * Endorsement policy specified per chaincode function    Ideas:   * Key based endorsement policies (see FAB-8812)   * Endorsement policies by reference rather than by literal   * Endorsement policies based on preimage and or postimage
Answer: 570279.0

User story: "blockevent listener function of getting all events for all channels is being deprecated    say we have    1000 channels, now we got to issue a 1000 calls to listen to events.    and change code as new channels are added    This is a feature regression.     "
Answer: 241600.0

User story: "When writing application using Node/Java SDK and tools like Fabric Composer having access to current Fabric version as an API that these tools can access is helpful."
Answer: 1035547.0

User story: "Identity conceptual information."
Answer: 34610.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 a chaincode returns a non-OK status code during transaction simulation, the ProcessProposal() RPC on the endorsing peer returns a ProposalResponse (with the correct error information inside it) and an error string describing the chaincode error.    [https://github.com/hyperledger/fabric/blob/v1.1.0-alpha/core/endorser/endorser.go#L477]    However on the client side of the RPC, when an error is present, [only the error is returned|https://github.com/hyperledger/fabric/blob/v1.1.0-alpha/protos/peer/peer.pb.go#L90] and not the proposal response object. It is recommended that servers return errors created using the [gRPC status|https://godoc.org/google.golang.org/grpc/status] package with a meaningful error code.    As things stand, there is currently no way extract the status code apart from parsing the returned error string."
Answer: 241866.0

User story: "To allow applications to perform channel config updates, the {{configtxlator}} tool was created.  It exposes a REST API for translating between protobufs and JSON, as well as a utility for computing a config update based on an original config and an updated config.    For examples and manipulation of channel config from the CLI, curl was used to invoke the functions of the REST server.  Because performing channel config updates was something most users did not need, this was considered a reasonable solution for v1.0.    However, channel 'capabilities' are required to be added to upgrade a fabric network, which is a modification to the channel config.  This can be accomplished by starting the REST server and issuing curl commands, but this is a bit cludgy.    It would be a fairly small amount of code to simply allow {{configtxlator}} to allow the REST functions to be invoked directly as CLI parameters, and it would make our upgrade samples easier to parse, and cleaner.    I propose the following three new commands to {{configtxlator}}    {noformat}  # Decode a protobuf message to JSON  configtxlator proto_decode --type <message_type> [--input <file.pb>] [--output <file.json>]    # Encode a JSON message to protobuf  configtxlator proto_encode --type <message_type> [--input <file.json>] [--output <file.pb>]    # Compute a config update from an original config and updated config  configtxlator compute_update --channel_id <channel_id> --original <original_config.pb> --updated <updated_config.pb> [--output <config_update_file.pb>]  {noformat}    Note, wherever input/output parameters are optional above, they default to stdin/stdout respectively.    Because this is a tool, and because it makes documentation and samples easier (and is not involved in any peer or orderer code path), it seems like this could still be a candidate for v1.1.0, but because it is an improvement and not a bug fix, excluding it could also be the correct decision."
Answer: 2342.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: "Address review comments from : [https://gerrit.hyperledger.org/r/#/c/16695/] .         1) Need to address this TODO in statecouchdb.go:            //TODO: processUpdateBatch is called with updateBatch of a single namespace/chaincode at a time.      // Hence, retrieving namespaces from updateBatch and looping over it is not required. Need to remove      // only the outer for loop.         2) Add comment for LoadCommittedVersions()"
Answer: 50232.0

User story: "There are several places where Node.js chaincode is used    ex: *Build your First Network , Fabcar &* *Balance-transfer*         Adding a link do the Node.js shim documentation [https://fabric-shim.github.io/] and about npm module will help application developers to understand the APIs and sample chaincodes."
Answer: 21328.0

User story: "H/T: https://gerrit.hyperledger.org/r/c/17313/1/core/peer/deliverevents.go#135"
Answer: 1569.0

User story: "To support more complex queries and improve performance."
Answer: 1040756.0

User story: "In BatchUpdateDocuments(), the chaincode JSON gets unmarshalled and re-marshalled.  It would be better to handle the chaincode JSON as a RawMessage so that it is not parsed/marshaled twice.  Here is the code in question... note that {color:#333333}jsonDocument.JSONValue{color} is []byte but it could be a RawMessage.         {color:#333333} //{color}{color:#333333}create{color}{color:#333333} a {color}{color:#333333}document{color} {color:#333333}map{color}   {color:#333333}var{color} {color:#333333}document{color}{color:#333333} = make({color}{color:#333333}map{color}{color:#333333}[{color}{color:#333333}string{color}{color:#333333}]{color}{color:#333333}interface{color}{color:#333333}\{}){color}    {color:#333333} //unmarshal the {color}{color:#333333}JSON{color}{color:#333333} component {color}{color:#333333}of{color}{color:#333333} the CouchDoc {color}{color:#333333}into{color}{color:#333333} the {color}{color:#333333}document{color}  {color:#333333} json.Unmarshal(jsonDocument.JSONValue, &{color}{color:#333333}document{color}{color:#333333}){color}"
Answer: 1041338.0

User story: "Policies that control replication factors for a collection and organization. The network should proactively redistribute data according to the desired balance of durability and scalability. For example, allow for:   * Minimum number of peers that should contain a data element to mitigate against reduction in durability when peer fails.   * Maximum number of peers that should contain a data element to enable scaling of larger collections."
Answer: 1041385.0

User story: "3 instances of a word are spelled incorrectly, in the Capabilities section:    imcompatibilities  : (im) -> (in)"
Answer: 5685.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "In the feature-upgrade behave tests, there are multiple steps that are used to perform certain actions. It would be nice to be able to write tests such that these steps can be consolidated into a single step. For example, when a user wants to invoke on a specific channel with a specific set of args, we should be able to write this in 1 step.     Behave allows for the consolidation of steps. For example,   {code}  @when('I do the same thing as before')  def step_impl(context):      context.execute_steps('''          When I press the big red button          And I duck      '''){code}"
Answer: 791157.0

User story: "When starting a new network in v1.1, after creating a channel, we have been told that a configAdmin for the OrdererOrg must send a capabilities config update to enable capability v1_1 in group /Channel/Application.    I sort of understand why this makes sense for the upgrade scenario, but this seems entirely unnecessary in this situation where we are starting the entire network on v1.1. Why should we require the network operator to enable a v1.1 capability, for every channel they create? If they didn't want v1.1 capabilities, they would not have installed a v1.1 network.    Is there some way to avoid this - maybe with a config parameter in orderer.yaml or configtx.yaml when starting the v1.1 orderer? Please explain.    As a side issue, we should probably document the need to do this when creating a channel in v1.1, and possibly mention it in the upgrade doc  https://docs.google.com/document/d/1JRYj7UW_3WXW5xCxXFdM5KtoNGmFr5g0HA_tR-8afLc/edit#heading=h.waeh2h8byypm"
Answer: 1169.0

User story: "The stop.sh script performs a docker-compose down which stops the network and the services that are in the composition file, but it does not stop the chaincode containers."
Answer: 7385.0

User story: "New Peers topic in Key Concepts section.    This is a new topic covering peers    (Uses markdown for content)"
Answer: 69398.0

User story: "Allow READTHEDOCS documentation to accept .md (markdown) files as well as current .RST format.     This will allow more contributors to create content."
Answer: 2959.0

User story: "Allow READTHEDOCS documentation to accept .md (markdown) files as well as current .RST format.     This will allow more contributors to create content."
Answer: 9.0

User story: "The current behavior of shim.MockStub is that it will set transaction time to be current time when shim.MockTransactionStart is called. But in some use case such as document's expiry date, it is necessary to be able to take control of transaction time to test this features.     My proposal is to add a new function shim.SetTxTimestamp which receive time.Time and set that time as a timestamp for transaction."
Answer: 1049223.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 the protocol buffer files (protobufs) are updated, the python files that are generated from them and used in some of the behave tests that now reside in the fabric-test repository need to be updated.    The files can be updated using the following command from the fabric-test base directory. This will generate python files from the proto files in fabric/protos  {code}  protoc --proto_path=fabric/protos --python_out=feature/common common/collection.proto common/common.proto common/configtx.proto common/configuration.proto common/ledger.proto common/policies.proto gossip/message.proto idemix/idemix.proto ledger/queryresult/kv_query_result.proto ledger/rwset/rwset.proto ledger/rwset/kvrwset/kv_rwset.proto msp/identities.proto msp/msp_config.proto msp/msp_principal.proto orderer/configuration.proto orderer/kafka.proto peer/admin.proto peer/chaincode.proto peer/chaincode_event.proto peer/chaincode_shim.proto peer/configuration.proto peer/events.proto peer/peer.proto peer/proposal.proto peer/proposal_response.proto peer/query.proto peer/resources.proto peer/signed_cc_dep_spec.proto peer/transaction.proto {code}    Install protoc by:  {code}  sudo apt install protobuf-compiler{code}"
Answer: 795673.0

User story: Running configtxgen on configtx.yaml.bad exits with error but gives no indication of what the cause of error was.         {{rm -f configtx.yaml}}  {{ln -s configtx.yaml.bad configtx.yaml}}  {{export FABRIC_CFG_PATH=.}}  {{configtxgen -profile SimpleOrdererGenesis -outputBlock orderer-genesis.block}}         The problem turned out to be that one element in the config YAML data had the wrong type (list of dicts instead of list of strings) due to the presence of an errant space.  Running configtxgen on configtx.yaml.good gets past that problem (though exits with error as expected, because we're not bothering to provide it with all the MSP materials it's looking for).  {code:java}  rm -f configtx.yaml  ln -s configtx.yaml.good configtx.yaml  export FABRIC_CFG_PATH=.  configtxgen -profile SimpleOrdererGenesis -outputBlock orderer-genesis.block{code}  If one were to provide MSP materials as advertised in configtx.yaml.good, then this command would succeed.    In particular, the error stemmed from this line in configtx.yaml.bad:  {code:java}    ...    Kafka:      Brokers:      - 127.0.0.1: 9092    ...{code}  Notice the space before the port number.  The same line in configtx.yaml.good is  {code:java}    ...    Kafka:      Brokers:      - 127.0.0.1:9092    ...  {code}  A fix for this would print an error message indicating that the "Orderer.Kafka.Brokers" element had the wrong type (and what type it expected), and ideally the line number of that element in the file.
Answer: 1051974.0

User story: "Endorser and chaincode debug did not consistently include channel and txid.  This made it impossible to correlate debug messages in production environments with many channels and transactions  flowing concurrently."
Answer: 547.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Add sample couchdb index to marbles02 chaincode to support the chaincode queries."
Answer: 214528.0

User story: "as we know,debug is a good learning method to start everything,however,in the fabric ,i want to start one orderer,one peer to study the theory,it doesn't support start the chaincode in process mode,i get disappointment,althought i know it can use the unit test to test whether the method is good? however,it doesn't work,i should get the entire process,not just a part"
Answer: 1054878.0

User story: "Assume in worst case, we cannot recover kafka/zookeeper cluster state, we need an approach to recover the whole fabric network from orderer ledger. Since it is a tedious/manual process, we need a instruction which could list all necessary steps. "
Answer: 801324.0

User story: "Endorser debug did not consistently include channel and txid.  This made it impossible to correlate debug messages in production environments with many channels and transactions  flowing concurrently."
Answer: 217162.0

User story: "Maintainers are constantly struggling to keep up with the flood of CRs that get submitted and could be helped in their reviews if more people reviewed the CRs.    Our documentation should mention that in the Contribution section and point out that it's a good way for people to ramp up and learn about fabric."
Answer: 5395.0

User story: "Any couchdb indexes defined for a chaincode will be deployed in the chaincode state database.  Indexes for collections of private data should be applied in the chaincode's collection state database rather than in the chaincode state database.    Indexes for public data are packaged in:    META-INF/statedb/couchdb/indexes    Indexes for private data collections will be packaged in:    META-INF/statedb/couchdb/collections/<collection_name>/indexes"
Answer: 178434.0

User story: to reproduce    go get github.com/hyperledger/fabric   cd $\{GOPATH}/src/github.com/hyperledger/fabric/orderer   go build    export FABRIC_CFG_PATH=/faddf    ./orderer   2018-01-17 12:58:18.960 UTC [orderer/common/config] Load -> CRIT 001 Error reading configuration: Unsupported Config Type ""  panic: Error reading configuration:Unsupported Config Type ""    goroutine 1 [running]:  github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*Logger).Panic(0xc42021c060, 0xc4201a1560, 0x2, 0x2)      /home/vagrant/golang/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/logger.go:188 +0xc7  github.com/hyperledger/fabric/orderer/common/localconfig.Load(0xc420120300)      /home/vagrant/golang/src/github.com/hyperledger/fabric/orderer/common/localconfig/config.go:265 +0x430  github.com/hyperledger/fabric/orderer/common/server.Main()      /home/vagrant/golang/src/github.com/hyperledger/fabric/orderer/common/server/main.go:73 +0xe2  main.main()      /home/vagrant/golang/src/github.com/hyperledger/fabric/orderer/main.go:15 +0x20
Answer: 43405.0

User story: "add option chan0 in gen_cfgInputs to allow user to specify the starting channel of the test     "
Answer: 654061.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 MAINTAINERS file in readthedocs.io is out of synch with [https://github.com/hyperledger/fabric/blob/master/docs/source/MAINTAINERS.rst]         Compared to what people see when they go to [http://hyperledger-fabric.readthedocs.io/en/release/MAINTAINERS.html]   h1. Maintainers  ||Name||Gerrit||GitHub||RocketChat||email||  |<USER>c0rwin|c0rwin|c0rwin|[<EMAIL>|mailto:bartem%40il.ibm.com]|  |<USER><USER><USER><USER>[<EMAIL>|mailto:<USER>40us.ibm.com]|  |Chris Ferris|<USER>christo4ferris|cbf|[<EMAIL>|mailto:chris.ferris%40gmail.com]|  |Dave Enyeart|<USER><USER>dave.enyeart|[<EMAIL>|mailto:enyeart%40us.ibm.com]|  |<USER><USER>gabre|hgabor|[<EMAIL>|mailto:gabor%40digitalasset.com]|  |<USER><USER><USER>garisingh|[<EMAIL>|mailto:gari.r.singh%40gmail.com]|  |<USER><USER><USER><USER>[<EMAIL>|mailto:gregory.haskins%40gmail.com]|  |<USER><USER><USER><USER>[<EMAIL>|mailto:<USER>40us.ibm.com]|  |<USER><USER><USER>jzhang|[<EMAIL>|mailto:jim_the_matrix%40hotmail.com]|  |<USER><USER><USER><USER>[<EMAIL>|mailto:<USER>40hacera.com]|  |<USER><USER><USER><USER>[<EMAIL>|mailto:bksmith%40us.ibm.com]|  |<USER><USER><USER>kostas|[<EMAIL>|mailto:kostas%40gmail.com]|  |<USER><USER><USER><USER>[<EMAIL>|mailto:manish.sethi%40gmail.com]|  |<USER><USER>srderson|<USER>[<EMAIL>|mailto:sranderson%40gmail.com]|  |<USER><USER><USER><USER>[<EMAIL>|mailto:<USER>40us.ibm.com]|  |Tamas Blummer|TamasBlummer|tamasblummer|tamas|[<EMAIL>|mailto:tamas%40digitalasset.com]|  |<USER><USER><USER><USER>[<EMAIL>|mailto:<USER>40il.ibm.com]|  |<USER><USER><USER><USER>[<EMAIL>|mailto:<USER>40gmail.com]|  ----   "
Answer: 1060253.0

User story: "FAB-5664 enhances the MSP infrastructure to tell apart fabric network nodes as clients, peers or orderers. In order to leverage this functionality, fabric needs to be configured in the appropriate way. Therefore, proper documentation and examples are needed.    [~<USER>, [~<USER>, [~<USER>."
Answer: 339.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "I analyzed goroutine proifles of Fabric peer, and found that the lock that guards the GRPC stream for the communication between peer and chaincode causes heavy lock contention.    [https://github.com/hyperledger/fabric/blob/v1.1.0-preview/core/chaincode/handler.go#L139]    I think removing this lock contention is important to improve the overall performance. I implemented a proof-of-concept code, and obtained 10% throughput improvement in my workload, and I think performance gain will become larger when the other bottlenecks in Fabric are fixed.    I come up with three ideas to alleviate this lock contention.       ----  *Solution 1: Lock Sharding*    One straightforward solution is to use lock sharding.  Lock sharding is a technique that split a single lock into multiple locks.  A similar technique is used in Java’s ConcurrentHashMap.    To use multiple locks, we need to establish a fixed number of multiple GRPC streams between peer and chaincode in advance, and manage relationship between each transaction and a used GRPC stream.    *Solution 2: Opposite TLS connection*    Currently, the TLS connection for GRPC is established from chaincode to peer.  In this case, chaincode is GRPC server and chaincode is GRPC client.  If this connection direction can be reversed, we can initiate a new GRPC stream per transaction.  With this change, we don’t need to guard each GRPC stream by a giant lock.      Initiating a GRPC connection from peer will need a lot of code changes in Fabric, but will simply the code of managing transactions. For example, currently we need to manage mapping of transaction contexts in order to correctly handle responses from chaincode, but if we use this solution, each transaction uses a dedicated stream for chaincode communication, so we don’t need to manage such relationship.    *Solution 3:  Reversal GRPC connection*    We can create a new GRPC connection using an existing TLS connection. This means that we can establish a TLS connection from chaincode to peer, and then create a new GRPC connection from peer to chaincode using the established TLS connection.    Using this technique, we can obtain all benefit of Solution 2 without changing the direction of TLS connection.  ----  I implemented a toy benchmark program that compares these 3 solutions as well as original approach.    [https://github.com/<USER>grpc-test]    The result shows these three techniques show about 30% better performance than the original one.    I think Solution 3 (reversal GRPC connection) is best one among three, so I am currently working of a proof-of-concept implementation of solution 3, and obtained 10% TPS improvement. I will post the PoC code later as a comment when I finish cleaning my code.     "
Answer: 1060853.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "In the [commit|https://gerrit.hyperledger.org/r/#/c/16795/5] which addresses FAB-7695 there are few changes was introduced for filtered block structure, among which was:    {code}  message FilteredProposalResponse {      repeated FilteredChaincodeAction chaincodeActions = 1;  }  {code}    where <USER>commented with respect to the naming of {{FilteredProposalResponse}}    {quote}  This is not my favorite name.  I probably would have gone with something like 'FilteredChaincodeActions' to indicate that this is a set of FilteredChaincodeAction. These would come from N different ProposalResponses rather than a single ProposalResponse as your name implies.    (Note that peer doesn't currently support N TransactionActions, but the structure allows it for the future.)    That being said, the overall structure here is what we want, so I will go ahead and +2 and merge to unblock SDKs.  I'll defer to Artem if you want to do another CR to tweak the names.  {quote}    After negotiation we came to the agreement/conclusion where it make more sense to rename/restructure proto definitions in the following way:    {code}  // FilteredTransaction is a minimal set of information about a transaction  // within a block.  message FilteredTransaction {      string txid = 1;      common.HeaderType type = 2;      TxValidationCode tx_validation_code = 3;      oneof Data {          FilteredTransactionActions transaction_actions = 4;      }  }    // FilteredTransactionActions is a wrapper for array of TransactionAction  // message from regular block  message FilteredTransactionActions {      repeated FilteredChaincodeAction chaincodeActions = 1;  }    //FilteredChaincodeAction is a minimal set of information about an action within a  //transaction.  message FilteredChaincodeAction {      ChaincodeEvent ccEvent = 1;  }  {code}    which makes more sense and aligns with original definitions of block transaction structure."
Answer: 278.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 Fabric ordering service node configuration file contains a *Kafka.Version* configuration property which the Fabric documentation currently instructs administrators to set to the version of the Kafka brokers used with the Kafka-based orderer. It turns out that this value has less to be with the Kafka broker version, and more to do with the Kafka protocol api versions.'  h2. Proposed Changes:   * Tweak the documentation of the  *Kafka.Version* property included in the orderer.yaml file.   * Update the [Fabric documentation|http://hyperledger-fabric.readthedocs.io/en/latest/kafka.html] such that a Fabric orderer admin is aware that:   * Kafka can be upgraded without altering the orderer.yaml.   * Why you *should* update the orderer.yaml when the Kafka version is updated, e.g.:   * Performance implications   * Log truncation protection.    h2. About Version Compatibility    The Kafka protocol is intended to be backward compatible with older clients ([source|http://kafka.apache.org/protocol.html#protocol_compatibility]):  {quote}_The server ... will always respond to the client with exactly the protocol format it expects based on the version it included in its request._  {quote}  h2. Impacts of Protocol Version  ||Kafka.Version   in orderer.yaml||Kafka Broker Version||Notes||  |{{0.9.0}}|{{0.9.x}}| |  |{{0.9.0}}|{{0.10.x}}|Performance impacted negatively|  |{{0.9.0}}|{{0.11.0+}}|Performance impacted negatively|  |{{0.10.0}}|{{0.9.x}}|Not compatible.|  |{{0.10.0}}|{{0.10.x}}|Performance impacted positively (vs. 0.9.0)|  |{{0.10.0}}|{{0.11.0+}}|Performance impacted positively (vs. 0.9.0)|  |{{0.11.0}}|{{0.9.x}}|Not compatible.|  |{{0.11.0}}|{{0.10.x}}|Not compatible.|  |{{0.11.0}}|{{0.11.0+}}|Performance impacted positively (vs. 0.9.0 & 0.10.0)   Better resiliency against log truncation after crash.|  h3.  "
Answer: 238.0

User story: "Fabric now supports adding capabilities via Go plugins in 3 areas:  - bccsp  - auth filters  - system chaincode    In order for all of this to work and for there to be no non-determinism, careful thought and planning needs to go into distributing peers with the plugins.      Given that, the default build for a peer should not include the ability to deploy / use plugins.      For that reason, we will add a build tag for plugin support and by default we will build the peer without the ability to load plugin."
Answer: 89125.0

User story: "Golang plugin support dynamic loading lib in runtime, it would be useful to make the shim layer as plugin, then we can do shim upgrade without breaking the chaincode.    This will provide another potential option for FAB-5676.    Please help vote if think this feature is helpful.    Thanks!"
Answer: 1066775.0

User story: "We should have one place to have our samples - fabric-samples"
Answer: 621623.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: By default, invokes should use the event listener in order to know when a transaction is written to the ledger. This will help to speed up the tests as well as ensure that transactions are written when expected.     An additional step is needed to outline the test case when one does *not* want to wait for the transaction to be written to the ledger. For example,   {code}  When a user, not waiting, invokes on the chaincode named "mycc" with args ["invoke","a","b","10"]"  {code}    Use of a flag to state when one should wait when performing invokes is recommended.
Answer: 273393.0

User story: "We need to for filtered blocks the block type it is.  configBlock updateConfig block or endorser transaction.    The values should be the same as   in common.proto  {code}  enum HeaderType {      MESSAGE = 0; // Used for messages which are signed but opaque      CONFIG = 1; // Used for messages which express the channel config      CONFIG_UPDATE = 2; // Used for transactions which update the channel config      ENDORSER_TRANSACTION = 3; // Used by the SDK to submit endorser based transactions      ORDERER_TRANSACTION = 4; // Used internally by the orderer for management      DELIVER_SEEK_INFO = 5; // Used as the type for Envelope messages submitted to instruct the Deliver API to seek      CHAINCODE_PACKAGE = 6; // Used for packaging chaincode artifacts for install      PEER_RESOURCE_UPDATE = 7; // Used for encoding updates to the peer resource configuration      CHANNEL_SERVICE_REQUEST = 8; // Used for packaging registration/deregistration requests for the channel service  }  {code}    currently filtered block structure looks as following:    {code}  //FilteredBlock is sent by producers and contains minimal information  //about the block.  message FilteredBlock {      string channel_id = 1;      uint64 number = 2; // The position in the blockchain      common.HeaderType type = 3;      repeated FilteredTransaction filtered_tx = 4;  }    //FilteredTransaction is a minimal set of information about a transaction  //within a block.  message FilteredTransaction {      string txid = 1;      TxValidationCode tx_validation_code = 2;      repeated FilteredAction filtered_action = 3;  }    //FilteredAction is a minimal set of information about an action within a  //transaction.  message FilteredAction {      ChaincodeEvent ccEvent = 1;  }  {code}    the {{FilteredTransaction}} need to be extended to include transaction type information.    [~<USER>"
Answer: 2915.0

User story: "With the addition of caching of versions, batching, and concurrency across different dbs (one per namespace), the state db implementation for couchdb is becoming unreadable.    This requires a refactoring and simplification in order to keep it readable - specially the code that is processed in the commit path"
Answer: 167493.0

User story: "If the ESCC is empty, the peer panics.  Optimally, it should not panic and just fail the endorsement."
Answer: 102.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: "GenerateCertificatesOrPanic is using temporary files when a simple buffer is sufficient. This results in untracked files getting left behind when tests failed.    The code can be easily refactored to use use a buffer."
Answer: 193.0

User story: "Peers should refuse endorsements, if their identity has expired."
Answer: 15586.0

User story: "Remove some of the repetition around filtering and expansion and try to rationalize some of the if/then flow around the job type."
Answer: 1476.0

User story: "LSCC should allow upgrade of collection policy.    Currently lscc.go has the following comment at ([https://github.com/hyperledger/fabric/blob/master/core/scc/lscc/lscc.go#L191):] currently, collections are immutable. Support for collection upgrade will be added later"
Answer: 2685.0

User story: "Although gossip auto-purges identities from its identity store right after they expire, it makes more semantic sense for the identity store not to accept expired identities in the first place.   "
Answer: 324.0

User story: "the unit tests are run serially in an inefficient manner. coverprofile is rarely used, so until we get to go 1.10 remove the coverprofile report from the unit-test target and run all the packages in the same go test command execution.    Add a PROFILE value for JOB_TYPE env variable to enable coverprofile report to be generated.    Resulting improvements cut the unit-test time nearly in half."
Answer: 1261.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 CLI command `peer channel create` honors the --tls and --cafile options as expected, and uses a TLS connection with the given CA file to the orderer for channel creation.  However, `peer channel join` and `peer channel list` do not honor the --tls and --cafile options, always attempting to make an insecure connection with the peer.    However, if one specifies the CORE_PEER_TLS_ENABLED=true and CORE_PEER_TLS_ROOTCERT_FILE=path/to/cert.pem environment variables, it does work.    Upon closer inspection, --tls and --cafile only specify the TLS settings for the orderer endpoint, not the peer endpoint.  This asymmetry (commandline options vs env vars) is confusing, probably stemming from the fact that the `peer channel join` and `peer channel list` don't even require an orderer endpoint, so the --tls and --cafile options are useless for those subcommands.    I'd suggest that at the very least, the --tls and --cafile options be moved to only the `peer channel create` and `peer channel update` commands.  Better yet, change --tls and --cafile to something that indicates they're for the orderer; --orderer-tls and --orderer-cafile.  Then also add commandline options for specifying the TLS settings for the peer connection; perhaps --peer-tls and --peer-cafile.    I think part of why this confusion occurred is because the line between the peer acting as a server (i.e. `peer node`) and the peer acting as a client (i.e. `peer channel`) is blurred and makes configuring and using the peer binary very confusing.  This is another argument for fully separating the peer binary into peer-client and peer-server, similar to the architecture of fabric-ca with its fabric-ca-client and fabric-ca-server.    I request that this fix, if made, be also added to the 1.0.x branch.     "
Answer: 1075176.0

User story: "SatisfiesPrincipal implementation of this MSP needs to handle the new types of MSP Principal, the one referring to the anonymous nature of the identity, and of combined principals."
Answer: 210187.0

User story: "For the X.509 MSP all identities are enrollment ones, therefore handling in SatisfiesPrincipal the anonymity principal is straight forward. The functionality for handling anonymity-specific and combined MSP principals is added to the X.509 MSP for v1.2, but the functionality is hidden behind a channel capability that will not be introduced until v1.3."
Answer: 209101.0