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: Add "permanent Link" to readthedocs documentation pages.    Update configuration in mkdocs.yaml file to provide link for each header in readthedocs pages. This helps user to share specific section of the document.     Provided reference link here..    http://fabricrepo.readthedocs.io/en/latest/#chaincode-developer-guide
Answer: 31443.0

User story: Update unit-test target in "make file" and "documentation" to *go-sdk-unit-tests*.     In Fabric "Makefile", unit-test target name is confusing as we have Node-sdk and Go unit tests. As we mentioned node-sdk-unit-tests target for node-sdk-tests, it's better to update unit-test to *"go-sdk-unit-tests"*
Answer: 273237.0

User story: "Modify tests as needed for automation, and submit to correct repo/branch: master, v0.6  Specify which ones can be executed for each story (each of the automation test suites) and provide instructions how to run them:  * smoke * daily * longrun"
Answer: 295131.0

User story: When i run any unit tests, including both the headless and those that require a target network, I should just be doing "npm test" or "node <path to test JS>", without relying on any external shell scripts.    The first step should be building a local target based on docker images.
Answer: 48670.0

User story: "Documentation & implementation of replay attack resistance related components on the committing peer side, endorser, and client side."
Answer: 1484099.0

User story: "Here, we would need to use the crypto interface defined within FAB-355 to build the commiting peer component that performs all the security checks within a transaction."
Answer: 278124.0

User story: "This is in association to FAB-351, and FAB-489.    In two steps:   - Golang client   - Nodejs client    These checks will be implemented given the membership service provider interfaces defined in FAB-823 and when needed the BC-CSP (crypto library interface) decided within FAB-355."
Answer: 269551.0

User story: "This is in accordance to FAB-351, and FAB-489."
Answer: 91926.0

User story: "The current documentation states to pull the sample app.js file and run using 'node app' which does not work.    Cmd line fix:  CORE_CHAINCODE_ID_NAME=mycc CORE_PEER_ADDRESS=0.0.0.0:7051 MEMBERSRVC_ADDRESS=0.0.0.0:7054 DEPLOY_MODE=dev node app    File fix - update line - to :  30 - var PEER_ADDRESS         = '0.0.0.0:7051';   31 - var MEMBERSRVC_ADDRESS   = '0.0.0.0:7054';  48 - var mode =  'dev';  97 - chaincodeName: 'mycc',      "
Answer: 223.0

User story: "There is a need to dynamically modify the log levels for components of the fabric for debugging and problem determination purposes.     This story emerged as a next logical step from the fix in https://jira.hyperledger.org/browse/FAB-394."
Answer: 145500.0

User story: "Error scenarios and failure scenarios testing  "
Answer: 544442.0

User story: "Research Plans, to see what features are in pipeline and what needs to be tested"
Answer: 295066.0

User story: "Research Release Notes / COMMITS to identify more testcases (per release)  "
Answer: 544441.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 is important that the ordering service not accept arbitrary configuration transactions, especially as the peer will not require any endorsement of these transactions initially.  Therefore, the ordering service should inspect and filter out these configuration changes, with a hook to allow them to be processed later, likely through validation of some endorsement-like process."
Answer: 51342.0

User story: When the peer receives a configuration transaction, as defined in FAB-496, it needs to call the Configuration System Chaincode (CSCC) which performs the following:  # map the changes into the correct read-write-set for the ledger to store  # process the configuration changes if applicable;  ex, removing a member CA from the chain, calling gossip  # commit the transaction to ledger    CSCC will provide the following functions:  # process "join channel" for the peer to start receiving transactions on the specified channel  # process transaction on commit  # process "queries" to return configuration data on channel (status, members, crypto)    For now, we will not require any endorsement of the transaction though this may be added in the future.  
Answer: 115527.0

User story: "The orderer needs to be able to take its initial configuration and deterministically generate a configuration transaction which all orderers will agree on.  This transaction should be well formed, and must be able to be interpreted by both the ordering service and the peer."
Answer: 285698.0

User story: "The orderer configuration needs to be embedded within the raw ledger.    This is for two reasons:    1. The orderer service needs to be able to convey initial configuration and configuration changes to the peer service so that the peer knows how to properly validate the raw ledger being returned (this may be different per orderer implementation, and may as simple as verifying a public key, or as complicated as a PBFT f+1 out of N signatures or connections)  2. The orderer service must agree to an initial configuration as without a common initial configuration (and common points of time for changing the configuration) the correctness of the orderer service may not be guaranteed.    This will require coordination between the chaincode/ledger peer side for applying and interpreting the configuration changes, as well as the orderer side for generating, and agreeing upon such changes.."
Answer: 103652.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: "Our GO obcsdk is used by a set of tests written in GO for consensus acceptance and regression, ledger stress tests, concurrency, and longrun testing. To talk to the Peers, client threads use REST calls. To leverage all these tests in v1.0 and beyond using node.js (especially needed if REST is deprecated), we must:  # Decouple the REST functions from the GO application layer, and create a well-defined API.  # Implement the node.js SDK communication interface methods, to perform the same functions as the existing REST functions.  # Provide a test environment variable for the GO application tests to choose either REST or node.js. "
Answer: 305085.0

User story: "When a connection gets (re) established, replicas exchange their latest chain state.  This allows a restarted/reconnecting replica to quickly catch up to the network without having to wait for new checkpoints that finally trigger state transfer.    From the code comment:    A reconnecting replica can play forward its blockchain to the batch listed in the hello message.  However, the currently in-flight batch will not be reflected in the Hello message, nor will all messages be present to actually commit the in-flight batch at the reconnecting replica.    Therefore we also send the most recent (pre)prepare, commit, checkpoint so that the reconnecting replica can catch up on the in-flight batch.  "
Answer: 50220.0

User story: "The consensus network should not add garbage data to the batches it produces.  Especially under byzantine assumptions, it is possible that byzantine nodes (client, primary) introduce invalid data into the batches.  To protect against this, requests proposed by a leader need to be validated for a correct signature from an authorized client.  This way a leader (or unauthorized client) can not add invalid requests.  This can be implemented as a generic component that can be shared by different consensus implementations.  In the case of bft, replicas check the batch preprepared by the primary and perform a view change when requests are invalid.  This component would be used by FAB-474 to filter requests before they get added to the fresh pool."
Answer: 102778.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: We want to prevent the primary of sBFT (but really any replica in any BFT atomic broadcast) to censor requests (i.e., drop individual requests).      Proposal: Per discussion with [~<USER>, this could be addressed by a generic component (not be part of sbft core, nor specific to sbft), which keeps track of new requests ("fresh"), in-flight requests ("pending", only at primary), and recently completed requests.  Timestamped entries are serviced infrequently (several second scale), and fresh requests will be brought to the attention of the remaining network, including the primary.  When a second, longer, timeout expires, the component signals to the atomic broadcast implementation that the leader should be changed.    Every time the atomic broadcast implementation observes a change in leader, this is communicated to the component and timeouts are adjusted to give the new leader time to act.    The leader also uses the registry of fresh requests to assemble a new batch.    This sounds deceivingly simple and probably will turn out to be more complicated than expected.
Answer: 1465874.0

User story: "create executable that will act as atomic broadcast client and use sbft as backend"
Answer: 102334.0

User story: "Use (to be) existing orderer atomic broadcast service to retrieve batches from other replicas.    process outline:  - on restart, mark as passive  - while passive, when observing a weak certificate for a seqno, ask application to sync to that batch  - start participating in consensus (i.e. mark active), also committing new batches, which might lead to holes in the ledger  - ledger component needs to be able to deal with holes  - to actively catch up to the network, exchange last checkpoint certificate when connections are re-established  - when active, hearing about a future checkpoint certificate does not necessarily trigger immediate state transfer  - while we have holes in our ledger, we do not service requests that are submitted via atomic broadcast.  This ensures that the network only progresses when there is at least one replica with a gapless ledger.    notes:  - how do we deal with (local) batches that lack signatures.  do we state transfer (signatures/batch) from elsewhere?    tests:  - rotate disconnects and reconnects so that all correct nodes have gaps in their ledgers.  state transfer finally manages to sync everybody to the latest batch."
Answer: 51666.0

User story: "Consistent reads has been implemented by using locks between readers and writers.  This task would implement consistent reads by using RocksDB snapshots, so that reads and writes can occur in parallel.  We then need to compare the two options and determine which one is better, e.g. from a performance perspective."
Answer: 1467620.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 would also help in scenarios where you don't want to trust state database, and prefer to get the data directly from the block storage (could do it for all reads/writes and not just for large data).    If we were to do this, state reads would be less efficient, and rich query would not be possible (on couchdb). These may or may not be import considerations, depending on the specific use case."
Answer: 1747398.0

User story: There are stories and tasks for Endorsers, Orderers etc. This story attempts to provide minimal scaffolding so we can incrementally build and test V1 flows. The "solo" orderer (https://jira.hyperledger.org/browse/FAB-31) will be used for this.    A beginning towards this was made with   https://gerrit.hyperledger.org/r/#/c/1057 (LCCC - lifecycle system chaincode),   https://gerrit.hyperledger.org/r/#/c/1177 (CLI driver for LCCC and Endorser)    With the above, we can send "deploy" and "invoke" proposals to an Endorser and receive a ProposalResponse back. Tasks will be attached to this story for reminder of flows  * integrating with new ledger  * sending transaction to orderer from CLI and behave tests  * committing transaction from the solo orderer to the ledger     
Answer: 272279.0

User story: "This is a overarching story involving Peer (as committer), Orderers and Gossip. "
Answer: 37418.0

User story: "We need to support authentication for event transport."
Answer: 29138.0

User story: "As a new visitor, I should be able to quickly get started and should be able to find what I need."
Answer: 89161.0

User story: "In order to support delivering batches to only a subset of peers, the atomicbroadcast API must be enhanced to allow channel creation, channel membership polling or notifications, and broadcast or delivery to one or more channels.    This will require modifications to the `atomicbroadcast/ab.proto`.  This will cascade into modification of solo to support the new API."
Answer: 89141.0

User story: "Gerrit docs should explain how to register ssh key"
Answer: 1902.0

User story: "(starting out as user story. May be changed to epic once we can discuss further)    A group of peers want to use a private channel into the ordering service such that only these peers can broadcast into the channel, have their proposals ordered with their own sequence number set and have the  batches delivered only through this channel.    From the discussions week of Sept 19, we need  # an api CreateChannel(channel_name,[]peers) for the channel creator to create the channel and list the peers in the group  # an update to Deliver() to specify which channel to send batches on and to verify which peers can connect to"
Answer: 289928.0

User story: "Per previous conversation with Bishop, as we ramp up load, we might anticipate some lost transactions. Though these might not be perfect measurements the data will still be useful, especially if its a small # of relevant transaction failures. "
Answer: 2213.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: "We'd like to be able to understand the throughput for all transactions to be committed to all peers. "
Answer: 19972.0

User story: "Enhance the clientSDK that now supports the fabric-next protocol to submit confidential proposals, and process endorsements that corresponds to confidential chaincodes."
Answer: 792710.0

User story: "Here a simple confidentiality/endorsement policy is assumed.  This issue is essentially an extension of the work needed for FAB-397."
Answer: 792712.0

User story: "This relates to implementing the part of the committing peer that checks the validity of transactions received by the ordering service, using     1. membership service interface specified in task FAB-829    2. security checks defined in task FAB-351    3. BC-CSP crypto calls (when necessary and outside item 1) as defined in task FAB-355."
Answer: 122555.0

User story: "Here, one would need to write and review the cliensdk code that does the crypto operations associated to a proposal, and of endorsement processing/transaction creation.   We need to also ensure that the non-crypto part of the code does the necessary checks, as defined in fabric-next.proto after FAB-351 concludes."
Answer: 301573.0

User story: "This issue relates    - review the code that does the parsing of a proposal to better understand it   - ensure that all the needed security checks are in place   - write  (refactoring from old code) the code to provide endorsements as required by the fabric-next protocol.  "
Answer: 116693.0

User story: "Assuming that we start with one peer (P0) and one Orderer (O0), we want to be able to add other peers (P1,P2,..., Pn) and other Orderers (O1, O2,...,On) and record these additions on the blockchain.    From current discussions:  # O0 provisioned with signing cert  # O0 public key exported to file  # file imported by P0  # P0 gather [ECert, other data for identification] using O0 public key, encrypts to file  # P0 writes its identifying data to blockchain (Note that we will need a special process as consensus is not working yet )  # P0 writes O0 identifying data to blockchain ( again note special consensus process )  # O0 imports file from P0 - P0 and O0 now have a communications channel  # Other orderers are added manually like O0 or using a new process using the O0-P0 channel  # In some cases, the orderers will have to know which other nodes are authorized orderers and when we can start the consensus protocol. Re-visit the whitelist concept from the original hyperledger fabric implementation  # Adding Pn is a proposal with a TBD endorsement policy on P0...Pn-1.  If the ordering service is up then go through consensus and commit.  When Pn starts up , it will do state transfer to sync up with the existing peers. If ordering service is not yet up, fall back on special process same as for P0"
Answer: 299682.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 service uses piecemeal configuration using environment variables today.  This should be done using Viper, but using the newer API which allows error on extraneous variables.    In the event that the newer version of Viper is not available, the similar but older version of the call can be used temporarily.    This should be re-usable across Solo, Kafka, and the RawLedger implementations."
Answer: 38828.0

User story: "The v0.5.2 and v0.6 builds should be tested in remote networks."
Answer: 325792.0

User story: "Implement a software provider implementing the interface described in FAB-354 in Golang to be used by the peer core code."
Answer: 85085.0

User story: "as an operator, I should have a cli that I can easily install that lets me interact with the various components of the fabric    The current peer commands are entangled with the validating peer capability, which means that building and installing a peer for Mac and Windows is complicated by the need to have RocksDB etc installed.    We can extract the peer commands into a separate component that is not dependent on the internals of the peer node, that can be simply installed as a platform-specific binary."
Answer: 307836.0

User story: "Efforts to debug customer issues have uncovered a need for additional capabilities in order to support the product.    Members of our support team could use a tool to change the settings of the logging levels in any or all of the peers, on the fly in a live running network.    This would require a change to fabric code to make these values dynamic, since today an image must be rebuilt with new values for parameters such as CORE_LOGGING_LEVEL.  It would also require a pulldown menu or a link on the BlueMix interface, or some sort of hidden access method or tool, to turn on or off the detailed debugging.  An alternative (undesirable) would be to run in the most detailed logging mode possible, and store huge amounts of logs for every peer in every network.  "
Answer: 1133169.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: "Hi folks, I am new to the community and I started this issue to have a discussion over the consensus design & planning in Fabric. Hopefully people can share some insights, in any form, so that I (as well as other potential readers) could have a better view about the consensus in Fabric.  My colleagues and I, we are trying to build a blockchain system with Fabric. Our business scenario requires the TPS to be at least 10k/s, however our current test on Fabric shows that it only supports a TPS of around 100/s (built-in pbft, 4 nodes). I know that there are some consensus algorithms that are able to reach several k/s TPS or even higher, e.g. Tendermint, Ripple, Aliph (in “The Next 700 BFT Protocols”), XFT (in “XFT: Practical Fault Tolerance Beyond Crashes”), to name a few. Here is my question:    *How the Fabric community thinks about improving the throughput of the consensus algorithm?*    To be more specific, it would be great if people could discuss about the following (or just give me some links/refs):  1. Are we going to adopt other high performance consensus protocols in Fabric’s community version? If yes, which protocols? Is there a milestone?  2. If there is no plan to adopt high performance consensus protocols in the community version, is there going to be a commercial version that adopts them? There is rumor saying that IBM has an internal consensus protocol which reaches over 100k/s. Given the many publications done by IBM researchers, I’d personally think this rumor is not far from reality.  3. Any other insights are welcome as well, including but not limited to those like, “100k/s is a lie, not theoretically possible”, “I’d like to hear other’s options” and so on. Or just giving me some other references is great!    FWIW, I have read the issue [Consensus endorsing, consenting, and committing model](https://jira.hyperledger.org/browse/FAB-37?jql=text%20~%20%22consensus%22), and I have read a doc of “Next-Consensus-Architecure-Proposal” when Fabric was hosted at Github, but I cannot find it anymore. It said that Fabric is going to adopt XFT and Aliph, but since I cannot find it, I am not sure if it still counts.    Thanks for reading the post, please leave your comments.  "
Answer: 37720.0

User story: This will help with creating a cleaner workspace for node.js developers working on the node.js SDK, and eliminate sub-optimal parts that are prone to breaks:  - build scripts that does -g installs  - reliance on vagrant  - "make" based build scripts are not best suited for node.js development
Answer: 6873.0

User story: "Story captures the work on providing high level design documentation describing relationship and interactions between different components such as discovery, membership and communication layer. Furthermore the actual implementation of the gossip protocol."
Answer: 138373.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 each node participating in the gossip protocol to maintain updated membership there is a need to provide discovery capabilities. Therefore story will gather tasks and work items to define gossip discovery API and interaction with membership service    https://gerrit.hyperledger.org/r/#/c/1181/  9c2ecfc266b3732aece962cb8e2a76a205d25bf5 "
Answer: 37495.0

User story: "Due to the nature of the gossip protocol there is a need to provide membership capabilities in order to reflect the presence of each node participating in the gossip and allowing node to pick neighbors to disseminate the message across the network.     https://gerrit.hyperledger.org/r/#/c/1181/  9c2ecfc266b3732aece962cb8e2a76a205d25bf5 "
Answer: 37505.0

User story: "As part of the work on gossip protocol there is a need to define communication layer API which will cover basic functionality of message transmission between different network entities. The story aims to capture the work on decoupling the communication layer from actual gossip protocol, providing APIs and high-level design document which describes interaction and possible use cases.      https://gerrit.hyperledger.org/r/#/c/1181/  9c2ecfc266b3732aece962cb8e2a76a205d25bf5 "
Answer: 37511.0

User story: "i suggest to put all deployment transactions in a dedicated column family,  i think this can speed up searching chaincodes when find a chaincode deployment spec or iterator all chaincodes because the amount of deployment transactions is much less than that of all the transactions.   for example:  blockchain.go func (blockchain *blockchain) addPersistenceChangesForNewBlock:  ......  writeBatch.PutCF(db.GetDBHandle().BlockchainCF, encodeBlockNumberDBKey(blockNumber), blockBytes)  writeBatch.PutCF(db.GetDBHandle().BlockchainCF, blockCountKey, encodeUint64(blockNumber+1))   //if Transaction is a deployment tx, write (TxID,Tx) to ChaincodeCF   for _, tx := range block.GetTransactions() {    if tx.Type == protos.Transaction_CHAINCODE_DEPLOY {     data, err := tx.Bytes()     if err == nil {      writeBatch.PutCF(db.GetDBHandle().ChaincodeCF, []byte(tx.Uuid), data)     }    }   }  "
Answer: 1504896.0

User story: "Now in the fabric before deploying your own chaincode, firstly you must summit the chaincode to the $GOPATH of the peer.  If an error occurs, the step will be repeated over and over again.  ---> add support to summit our chaincode to the peer when we deploy chaincode.  such as:  peer chaincode deploy -p $GOPATH/src/myChaincode...  The operation above can also copy local chaincode to peers implicitly."
Answer: 121350.0

User story: Enable "node-sdk" unit tests in Jenkins CI process.
Answer: 5094.0

User story: "Peer currently can deploy/invoke/query a chaincode , but can not get all chaincodes deployed in the ledger. i suggest to add a subcommand to list all chaincodes deployed in the ledger.  "
Answer: 1507569.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 many config.go in several packages and exist some duplicate code, could we unify them? I note a comment mentioned circular import issue, could we reconstruct the directories?    ./events/config.go  ./core/peer/config.go  ./core/container/config.go  ./core/config/config.go  ./core/ledger/statemgmt/buckettree/config.go  ./core/ledger/statemgmt/state/config.go  ./core/system_chaincode/config.go  ./core/chaincode/config.go  ./core/config.go  ./core/comm/config.go  "
Answer: 994007.0

User story: "The 'devops' REST interface has been deprecated for months. There's no reason to continue to expose it. The code is little more than potential technical debt."
Answer: 17444.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: We really need a component for deployment considerations.       ----  (Migrating issue from GH, Write paper on deploying hyperledger #1024)     <USER>commented on Apr 8    <USER>and <USER>to write one-page "whitepaper" for the April 30 weekend "hackathon" with business partners and competitors.    The whitepaper will describe in detail how to deploy hyperledger on Azure.    A second goal is for the whitepaper to describe how to deploy hyperledger on ANY platform - any "bare metal softlayer" deployment of hyperledger. But the immediate goal for the paper and confirmation / testing is to provide the deploy to Azure procedure for the hackathon.  @<USER><USER>changed the title from Write paper on deploying hyperledger to Azure to Write paper on deploying hyperledger on Apr 8  @hannibalhuang  Hyperledger Project member  hannibalhuang commented on Apr 9    Hi @<USER>, I'm interested in the "any platform" concept, would be glad to participate in the discussion  @srderson srderson added the documentation label on Apr 10  @stanacton  stanacton commented on Apr 17 • edited    Hi, I'm very interested in the "any platform" concept too. VM is great for development, it would be nice to have a 'anywhere' client built in GO. Can anyone help me find this information on setting up independent nodes that talk to each other? The "Setting up a network" example does it within the Vagrant machine.  @joequant  joequant commented on Apr 19    Yes. Look at  https://github.com/joequant/hyperledger  These are scripts that are derived from scripts written by yeasy.    ./startnet.sh should download the docker images from docker hub and spin them off.  @stanacton  stanacton commented on Apr 19  Thank you very much!  This looks life what I need.  …  @yeasy  Hyperledger Project member  yeasy commented on Apr 19    Thanks joequant.  @stanacton  I highly recommend u to have a look at https://github.com/yeasy/docker-compose-files#hyperledger and  https://github.com/yeasy/docker-hyperledger-peer.    Which will help you quickly boot up a hyperledger cluster without any local configuration and vagrant layer.  @joequant  joequant commented on May 2    Yes. I'll take a look at using docker compose.  @wangbin767  wangbin767 commented 9 hours ago    I am interested in whether this paper finished?  @<USER> Hyperledger Project member  <USER>commented 41 minutes ago    Investigating, this was dependent on some test results, TBA.  @christo4ferris  Hyperledger Project member  christo4ferris commented 26 minutes ago    can we please open this in Jira? Thanks.  
Answer: 828119.0

User story: Now that we have more than 1 unit-test in fabric;-), we might as well be able to call *make unit-tests*, that is (more seriously) “‘make unit-tests’ should be plural to more naturally describe the intended action"    This task involves a small fix in the make target of {{hyperledger/fabric/Makefile}} and making sure that the CIs make the right call(s) to run the tests.  
Answer: 30188.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: "see discussion in GH issue here [https://github.com/hyperledger/fabric/issues/752]."
Answer: 333225.0

User story: "Add support for  table APIs in JAVA shim layer. This will enable Java chaincode developers to use the table functionality supported by fabric.  "
Answer: 40896.0

User story: I am now  reading the peer chaincode deploy sourcecode .I  find we may add -a  attributes to the  CLI command when   CORE_PEER_ADDRESS=172.17.0.2:30303 peer chaincode deploy -n mycc -u jim -c '{"Function":"init", "Args": ["a","100", "b", "200"]}'  And I just don't know what is  attributes?Does it really work in the fabric.If yes,how ?  Thanks!
Answer: 118.0

User story: "as a developer, I can find the hyperledger fabric documentation easily so that I can develop chaincode and applications.    Ideally, the documentation for all hyperledger projects can be easily found at hyperledger.org."
Answer: 10371.0

User story: "Querying for full history of keys will require a new history database. See attached slides for details."
Answer: 195997.0

User story: "Create query system chaincode layer to execute queries against ledger."
Answer: 214607.0

User story: "- Ledger APIs have been implemented and need to be exposed to SDK:    -- GetBlockchainInfo    -- GetBlocksByNumber    -- GetBlockByNumber    -- GetBlockByHash    -- GetTransactionById    -- ExecuteQuery    "
Answer: 214607.0

User story: "Call Committer System Chaincode (CSCC) to check Block Commit Policy. Gossip among Committers to collect agreements according to the BCP. If satisfied, commit the block; otherwise, discard the block  "
Answer: 1800449.0

User story: "Implement RemoveInvalidTransactions()    - Implement MVCC check"
Answer: 66184.0

User story: "- Implement QueryExecutor.GetStateRangeScanIterator()    - Implement QueryExecutor.GetStateMultipleKeys()    - Implement TxSimulator.DeleteState()    - Implement TxSimulator.SetStateMultipleKeys()"
Answer: 196041.0

User story: "We need to establish a package domain for hyperledger fabric so that developers can use go tools to import, get and govendor hyperledger/fabirc."
Answer: 985627.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: "Validation policy is implemented by validator system chaincode (VSCC), which is associated with 1 or more chaincodes and called by Peer before committing transactions. VSCC works with ESCC (endorser system chaincode) to ensure a transaction is valid.     We want to implement following default policies:  # At least 1 valid signature from those participating on the chain  # Explicit list of signatures; advanced implementation may allow boolean expressions including AND, OR. For example, (a AND b) OR c  # Percent of valid signatures (eg 80%) of those participating on the chain. This could be complex in counting the total of the endorsers at the time of validation which could lead to none determinism since each peer might have a different total due to gossip network.    Note that we want the policy to be consistent per chaincode deployment. If a chaincode is bound to a percentage policy, then it will always be using that same policy. To change the validation policy, the chaincode would have to be redeployed. Therefore, when a chaincode is deployed, it needs to specify ESCC/VSCC and the validation policy to enforce during the life-cycle of the chaincode.    We also need a function `CheckEndorsementPolicy(Transaction)` to allow app to optionally check endorsement policy correctness prior to submitting the transaction to the network. This same function is called during validation."
Answer: 216901.0

User story: "Every peer is potentially an endorser for the chaincodes deployed to it (the application may choose not to send a proposal to an Endorser).  {quote}The following diagram provides a overview of the process as far as the interactions between the application and the Endorser goes. The process's loop is completed when the transaction related to the proposal is fed back to the Committer (Endorser is also a committer). This part is not shown below.{quote}      !TxProposalFlow.png|thumbnail! "
Answer: 31640.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: "An application can upgrade a chaincode to a Peer by sending a Proposal to a Peer to upgrade a chaincode. In particular, this Proposal is targetted at a special *system chaincode* called *Life Cycle Chaincode*. The life cycle chaincode manages all chaincodes deployed to a peer.   Upgrade is similar to a deploy. The difference is that it increments version of the chaincode. At commit time, the version will be in place and all transactions will begin using the upgraded chaincode.  The chaincode might be associated with an Endorser System Chaincode and/or a Validation System Chaincode to provide custom exists for chaincode specific policies to be used when the chaincode simulates transactions (when processing Proposals) and when the chaincode commits transactions respectively. The fabric provides default ESCC and VSCC.    {quote}Fig 1 provides a overview of the process as far as the interactions between the application and the Endorser goes. The process's loop is completed when the transaction related to the proposal is fed back to the Committer (Endorser is also a committer) as shown in Fig 2 (LCCC_VSCC in the figure is the Validation System Chaincode for Lifcycle Chaincode) {quote}     !UpgradeFlow.png|thumbnail!   *Fig 1*       !UpgradeCommitFlow.png|thumbnail!   *Fig 2*"
Answer: 359668.0

User story: "An application can deploy a chaincode to a Peer by sending a Proposal to a Peer to deploy a chaincode. In particular, this Proposal is targetted at a special *system chaincode* called *Life Cycle Chaincode*. The life cycle chaincode manages all chaincodes deployed to a peer.     The chaincode might be associated with an Endorser System Chaincode and/or a Validation System Chaincode to provide custom exists for chaincode specific policies to be used when the chaincode simulates transactions (when processing Proposals) and when the chaincode commits transactions respectively. The fabric provides default ESCC and VSCC.    When deploy a chaincode, an endorsement validation policy may be submitted in the deployment transaction. The  validation policy is evaluated by VSCC prior to committing the transaction to the ledger.    {quote}The following diagram provides a overview of the process as far as the interactions between the application and the Endorser goes. The process's loop is completed when the transaction related to the proposal is fed back to the Committer (Endorser is also a committer) as shown in Fig 2 (LCCC_VSCC in the figure is the Validation System Chaincode for Lifcycle Chaincode) {quote}     !AdvancedDeployFlow.png|thumbnail!   *Fig 1*     !DeployCommitFlow.png|thumbnail!   *Fig 2*"
Answer: 1416843.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: "An application can deploy a chaincode to a Peer by sending a Proposal to a Peer to deploy a chaincode. In particular, this Proposal is targetted at a special *system chaincode* called *Life Cycle Chaincode*. The life cycle chaincode manages all chaincodes deployed to a peer.    {quote}Fig 1provides a overview of the process as far as the interactions between the application and the Endorser goes.  The process's loop is completed when the transaction related to the proposal is fed back to the Committer (Endorser is also a committer) as shown in Fig 2 (LCCC_VSCC in the figure is the Validation System Chaincode for Lifcycle Chaincode) {quote}{quote}     !BasicDeployFlow.png|thumbnail!   *Fig 1*     !BasicDeployCommitFlow.png|thumbnail!   *Fig 2*"
Answer: 31635.0

User story: "We need the ability in Node JS SDK to register for block events and retrieve block information and transactions in the block."
Answer: 24281.0

User story: There are many reasons for needing a system clock which returns a consistent time across all peers and in all chaincode.    The design proposal for implementing this is to implement this as a system chaincode called *clockSCC* as follows.    clockSCC has the following functions:  * init - simply calls private tick()  * query getTime() - simply returns the value of the $time variable  * invoke setTime(time) - described below  * private tick() - issues an invoke transaction of setTime(time.Now()) against itself    The *setTime(time)* function does the following:  {code:java}  // The 'time' argument is the current time from the submitting peer's clock    // Reject this update if the time is not moving forward according to the submitting peer's clock  globalTime = stub.GetValue("time")   if (time <= globalTime) return    // Reject this update if the difference between the submitting peer's clock and the local peer's clock is too large  // PROBLEM: This is going to be non-deterministic  delta = time - time.Now()  if (math.Abs(delta) > MAX_DELTA) return    // Update the time   stub.SetValue("time",time)    // Reset the timer   Cancel current timer if set  Set a timer to invoke *tick()* in a random time within a range (e.g. between 60 and 70 secs)  This randomness prevents all peers from submitting transactions at the same time  {code}    Time can never go backwards with this chaincode and a peer with an invalid time, out of the acceptable range of other peers, will be rejected    Another architectural design which may fit better than using system chaincode is to build it into consensus.  This seems to be the case with swirlds (http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf).    Or a 3rd design is to support a chaincode API which allows all chaincodes to compute their own value for something but the resulting value which is actually stored is some deterministic function across all values (e.g. average).
Answer: 1803064.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 is a document explaining the interface of the gossip network component and its way of operation in high level:     [^gossipArch.pdf]      [^gossipArch.md]   "
Answer: 125212.0

User story: "Hi,     I got to know from multiple slack channels that the REST interface hosted by the VP/NVP is going to be deprecated. My request is to retain it.    We are in Banking software business. And our goal is to use HL Fabric as the Blockchain framework to which different participants would be connected.   We defined a plugin which can talk as below   Banking App < == Plugin == > Fabric  This way we were able to handle everything   1. Custom chaincode deployment  ( Go lang) ,   2. Invoke   3. Queries    Now if this REST interface is taken out, I don't know how to go about implementing these.  In my opinion, REST is the best way to implement a decoupled interface. And this way any application would be able to connect to Fabric without much of a programming interface change on the Banking S/w end.   "
Answer: 301073.0

User story: Build should be building the Node SDK API docs (generated by "typedoc" command) and publishing them such that they will be available online    This should be done on the v0.6 branch. the new project fabric-sdk-node has its own doc generation so this set up will need to be re-done for v1.0 later on. But that'll not be for another couple of months, so let's worry about publishing v0.6 now.
Answer: 315813.0

User story: "Implement TLS for the communication between peer and java shim layer"
Answer: 211959.0

User story: "*Description*    Java chaincode development currently only supports gradle as the build tool. This issue is to add Maven support.      _Maven is currently not supported._  "
Answer: 46747.0

User story: "BFT orderers have to provide signatures so that validator peers can use the set of signatures to accept validity of a batch without having to connect to f+1 orderers.    All orderers already sign with their own key."
Answer: 1420007.0

User story: "The orderer network needs to be reconfigurable.  Possibly this is specific to the orderer network implementation."
Answer: 161827.0

User story: "Make sure that users cannot work with expired TCerts, ECerts, or obtain TCerts that out-live the ECert expiration."
Answer: 206345.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: Original issue was [2110|https://github.com/hyperledger/fabric/issues/2110]    Various services in Membership Services have the public *NewXXXX( name string )* or the private *createYYYY ( name string )* method expecting the string parameter `name`, which is later on being used for creating/writing and reading various (temporary?) files.    However, diving into the implementation(s), some of these has code which relies on some "secret magic" both underneath the services and their tests, e.g.,     {quote}err = ioutil.WriteFile(ca.path+"/" + *name* + *".priv"*, cooked, 0644)  err = ioutil.WriteFile(ca.path+"/" + *name* + *".pub"*, cooked, 0644){quote}    Or when creating the ("server") objects/entities, for example:  {quote} eca := &ECA{CA:NewCA( "*eca*" , initializeECATables) {quote}      h3. Proposed Solution    # Define these at the very least as constants/parameters (if not have them completely configurable, at this point - sill much better than hard-coding, inline). Plus, while we are at it (and I will mention that I'm not a fan of storing private keys in plaintext/files), we should use standard extensions:  # We should probably use the more industry-standard file extensions (for `PEM, DER, CRT, CER, KEY, ...`)
Answer: 417903.0

User story: "Run the COP server in a cluster sharing the same DB.  Will test with HAProxy fronting the cluster, though any load balancer should do.  No session affinity should be required."
Answer: 165383.0

User story: "As a developer I need the ability to access a state cache so that we can help submitters quickly build the rw-set. This will also lead to better performance. "
Answer: 1884582.0

User story: "As Solution architect, I would confidentiality based invocation access control capabilities"
Answer: 342885.0

User story: "Add Jenkins build status markdown view URL in index.md. Below is the URL to add index.md    [![Build Status](https://jenkins.hyperledger.org/buildStatus/icon?job=fabric-merge-x86_64)](https://jenkins.hyperledger.org/job/fabric-merge-x86_64)  "
Answer: 10069.0

User story: "as a developer, I can find the Hyperledger Fabric code on GitHub so that I can explore it without needing access to Gerrit"
Answer: 17350.0

User story: "Today you can only run a single instance of membership services.  We need to be able to run multiple instances in a cluster for HA."
Answer: 351344.0

User story: "Membership services runs as a single process today.  We must be able to run multiple instances of it in a cluster so that if one process fails, others are available.  This should work both in the same geographic location as well as across multiple geos."
Answer: 351352.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: "Some user information in membersrvc.yaml is duplicated because it is spread across the ECA and ACA sections.  This file would be simpler if there was a single user section that contains a combination of the data.    Also, it should not be in table format for each user because doing so requires putting values for all fields when some/many may be optional.    Each field should have also have more complete comments to describe it's use and refer to section of documentation for fuller descriptions. "
Answer: 346948.0

User story: "Implement {{ExecuteQuery(query string) (ResultsIterator, error)}} in the {{QueryExecutor}} interface    Implemented in FAB-1395."
Answer: 206969.0

User story: "STORY: Application developers require the SDK to have the ability to listen to events triggered from the chain, so that they can continue to process events within their application once received.     Original issue (1116)[https://github.com/hyperledger/fabric/issues/1116]"
Answer: 38511.0

User story: "This issue is a transfer from GitHub https://github.com/hyperledger/fabric/issues/1309  I'm broadening the description because although the original issue was raised against the peer command specifically the discussion that followed brought to light the fact that the issue is more general.    Indeed, Fabric's configuration is currently handled via yaml files and Viper which provides no validation mechanism.    Several people have expressed interest in ditching Viper for that reason. Several possibilities were mentioned:    <USER>commented on May 24:    Relevant SO post: http://stackoverflow.com/questions/16465705/how-to-handle-configuration-in-go    I think we should not limit ourselves to yaml if other packages provide obvious benefits. Transitioning config file structure is painful, but only once. Generally, people on go-nuts seem to dislike yaml, because it is a very complex format.    Options I can see:        https://github.com/BurntSushi/toml ini-like, uses reflection, can express complex data (arrays, time)      https://godoc.org/gopkg.in/gcfg.v1 ini, uses reflection, can express multi-section and multi-values      https://golang.org/pkg/encoding/json/ json, standard go package, uses reflection, complex data, no comments      https://github.com/vharitonsky/iniflags ini, ties into standard go flags package, allows overrides via command line      "
Answer: 348512.0