udaykiran19491/user-stories-from-tawos-for-llm-fine-tuning huggingface dataset:
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "This includes the research on the items that need to be configured on multiple components of the system :   - protobuf crypto algorithms, e.g., hash function   - used MSPs, e.g., what are the parameters one would need to set per MSP   - MSPManager, e.g., policies that govern addition or removal of an MSP/Member  Doing this will help us identify the content of respective configuration transactions."
Answer: 149444.0

User story: "Get a working version of fabric v1.0 testbed running on our laptops on vagrant environment.  0edd927 or git checkout -b <branch> 182a867  Ensure the correct readme instructions are available: bugs were created for the older readme file: 1026 1027 1028  However, memberservices is gone from more recent commit levels in fabric. A new readme will be written once reimplemented, and new steps."
Answer: 17355.0

User story: "We no longer need Query interface in the chaincode, so we should remove it and fix up the examples so that developers can follow"
Answer: 43281.0

User story: "The committer currently only works with solo to support the skeleton path. We need to generalize it with the following:    # As an object to be instantiated by the gossip to handle incoming blocks on a channel (1 committer object per channel)  # Process block of transactions, where each transaction type associated with a system chaincode, call the system chaincode to process the transaction (the association is declared in the yaml system chaincode section)  # For CHAINCODE type, call the chaincode's VSCC to validate the transaction  # Handle invalid transactions (have a policy on whether to store or not;  default is not to store)  # Commit block to ledger  # Emit events if any    We probably need a queue here to hold the blocks to be processed."
Answer: 120727.0

User story: "Consistent reads has been implemented by using locks between readers and writers.  This task would implement consistent reads by using block height approach, so that reads and writes can occur in parallel."
Answer: 1684843.0

User story: "Creating this issue and (adding myself as a watcher) so that I don't have to bug Ry to see when the upgrade will happen.    I'd like to see the CI getting upgraded for two reasons:    # t.Run: support for sub-tests was added in 1.7 (and I'm using it for the Kafka orderer)  # context: the location of the package changed from 1.6 to 1.7"
Answer: 23760.0

User story: "A transaction type can be handled by a system chaincode so that a custom type may be associated with a system chaincode to be called when the transaction is to be validated and committed to the ledger. The association is defined as part of the system chaincode configuration data (call this chaincode for this transaction type).    Example is the Configuration System Chaincode (CSCC), which is called for every CONFIGURATION transaction."
Answer: 1406201.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 need to process CONFIGURATION transactions from orderer (not from client as in transaction proposals). We need to convert configuration items into a write-set for ledger to commit to the datastore. The configuration data will be cached in the state db.    This chaincode also provides query functions to access configuration. It also process join channel request from client."
Answer: 56382.0

User story: "Add unit tests to example.go application in ledger examples."
Answer: 876769.0

User story: "There are a number of cases where the peer is able to create chaincode containers and then attempts to start them.  However, if the chaincode container fails to communicate with the peer within a specified timeout, the peer considers the deployment to be a failure and will actually attempt to delete the container.   When this happens, access to the container logs is lost and it is difficult to debug what cause the communication error.    It should be possible to use the remote API to retrieve the logs (if they exist) prior to deleting a container.  This would greatly improve usability and help with operations"
Answer: 489918.0

User story: "For Fabric v1, the artist known as membership services is now in its own repository (fabric-cop).  Need to remove membership services from the master branch of the fabric repository"
Answer: 4059.0

User story: "This is for testing the fabric ledgers both for performance and functionally with the peers and orderers.    (Edit: The LTE tests added as tasks here are Ledger-component specific only)"
Answer: 876799.0

User story: "From the list of Orderer test scenarios, each will be used to detail specific steps when generating behave tests.    The orderer scenarios (both happy path and failure) should be added. (version 1.0)    *Output:* A list of scenario test cases/possible scenarios that will be discussed with a developer/owner, and identify test utilities needed. These test scenarios will be saved (and possibly reformatted) for use as the feature files."
Answer: 252316.0

User story: "Write/borrow/port and merge code tool to detect if a chaincode is non-deterministic.  Create tests using non-deterministic chaincode to verify endorser behavior rejects transactions generated using said chaincode.  "
Answer: 498092.0

User story: "Logrus is currently vendored as it is used by the go-dockerclient (I believe).  The vendoring is a bit messed up (some odd files) and the version in there does not compile natively on OSX.    As an aside, I am also going to propose moving to using this package for logging in general, so will be good to update it"
Answer: 201.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 Kafka orderer, the routine sendBlocks() in client_deliver.go is implemented as a "hot idle" loop. Every client that connects to the orderer for delivery service will spawn a goroutine that executes this loop, and as long as the client has "push tokens", this loop will never terminate. I've attached a screenshot of "top" showing that an "idle" Kafka orderer - that is, one that is not actually delivering any blocks - is consuming 11.24 HW thread-equivalents on this POWER8 system when serving 100 delivery clients.    Also interesting is that 47.8% of the CPU is reported as "waiting" by the OS. This is why we are not seeing even higher CPU utilization here, and is also pointing to a potential problem. The problem is that each delivery client shares a common `cd.deadChan`. When Go executes a `select`, it operates in a critical section that begins by locking every channel named in the select.  What is happening here is that every goroutine is simultaneously competing for the lock on `cd.deadChan`. Unable to immediately get the lock, the goroutines block (sleep) until it is their turn, and the OS is marking this sleep as I/O wait time. If the `cd.deadChan` case is commented out, CPU utilization can go as high as 100% of the entire machine if enough clients are connected (even though no actual work is being done).    I've attached a proposed patch idea for the first problem. Go allows `select` cases to be NIL. So instead of the 2-level scheme currently used, we can simply select on a variable that is NIL when the client has no tokens, and is set to the Kafka message channel when the client has tokens.    I have not yet looked for evidence of the global lock being an issue if this loop is event-driven. It's something to be aware of though, especially given the way that the Go runtime implements `select`.
Answer: 403438.0

User story: "How can I query chaincodes that have been deployed, such as `peer chaincode ls`  "
Answer: 1153495.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: PREFACE:  In this description, "peers" refers to the peers in a v0.6 network. In v1.0, the "peer" will include the concept of endorser and committer - everything EXCEPT the orderer nodes which are actually used for consensus to order batches. So, when implementing this story for v1.0, use the term "orderer node" instead of peer.      We should measure scalability : measure network throughput rates and timings (durations to deploy or process transactions) or other performance characteristics, for different sized networks.    STEP 0:   First modify tests as needed to run with different sized networks. Devise smarter tests that can run, take down a peer, and rerun, and compare differences in throughput, etc.     STEP 1:  We can run specific existing performance measurement tests on different size networks, for example, 4, 7, 10, 16 peers (when F is 1, 2, 3, 5). At first, tests may need to be run in separate networks, statically created, because fabric does not allow dynamically changing the number of peers in the network (or the number of peers required for consensus).    STEP 2:  Another thought is to measure performance of the same network when some peers are not operating. For example, using a network of 6 peers (N=6, F=2), we could create a network and run the tests to collect performance measurements while all 6 nodes are running, then stop one peer and collect measurements, and then stop a 2nd peer and collect measurements. (Stopping a third peer would leave only 3 running, and the network would halt processing.)    STEP 3:  Once fabric is enhanced to allow dynamically adding a peer to a network (and change both N and F), then we could extend the tests in STEP2 for example to run in a network with N=10 and F=3, and stop a peer, rerun, stop another to reduce to 8, rerun, 7, rerun, ..., 4, rerun.  
Answer: 462084.0

User story: "A user/org may or may not be able to modify the orderer policy being used in the orderer (PBFT, Kafta, SOLO, etc.). The same is true for endorsement policies. These scenarios should be tested.    1.What is the default and what happens if and when this is changed?  2. At what point in the process are these permissions set?   3. How should this look when setting the genesis block? How does one update it?"
Answer: 1446322.0

User story: "An admin would bootstrap the network and would need the following:  * users and certs for each peer  * orderer certs and URL/IP address for the network  * any possible subchannel information if network will be configured with such    The output is:  * the genesis block that contains cert info for all peers in the network  * a hash that is sent to each peer for determining if the genesis block that they receive from the network is genuine.  "
Answer: 418940.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "With removal of PBFT watermarks, sBFT replicas (consenters) now process one batch at the time. For instance, a replica will not process a pre-prepare for seqno n+1 until it has committed (or even weak checkpointed) batch with seqno n. Whereas this is not a performance issue when the network is simulated on a single machine, it is certainly an issue for WAN deployments, with any non-negligible network latency.     To fix this, a new protocol alternative to simplebft (sBFT) is needed (sBFT may stay for use in clusters).     The goal is to implement a BFT protocol based on sBFT with pipelining-enabled replicas, Pipelining involves processing of a BFT protocol message (e.g., pre-prepare, prepare, commit, checkpoint) for batch n+1 as soon as the same message type was processed for batch n. Notice that this does not mean introduction of PBFT watermarks which can create holes. Pipelining does not create holes for a given msg type."
Answer: 1316288.0

User story: node.js SDK needs to expose the following events from the Peer to notify client applications of transaction processing results (protots/peer/events.proto):    ```  enum EventType {          REGISTER = 0;          BLOCK = 1;   CHAINCODE = 2;   REJECTION = 3;  }  ```  - BLOCK: notified when a block has been committed by the Peer in the ledger. event payload has the entire raw block content  - CHAINCODE: also known as "custom events", which is defined by chaincode and is also notified when a Block containing transaction(s) processed by that chaincode is committed to the ledger  - REJECTION: notified when a transaction is rejected by the Peer validator (eg. failed endorsement policy in VSCC)  - REGISTER: not needed for applications, this looks like an internal event to notify the registration of a event by a consumer    The SDK should:  - allow application to register listeners to events of the above types, plus a synthetic "Transaction Completed" event with a transaction ID  - connect to the event stream (persistent grpc stream) and on receiving an event, decide whether it is of interest to the application based on the event listener registration  - when an event of interest to the application has been received from the event stream, produce a JavaScript event object that encapsulates the useful payload (transaction, or error message) and emit to trigger the application event listeners    The event registration and triggering should be per-chain/channel, such that events by the same name (customer events produced by the identical chaincodes deployed to different chain/channels) don't get mixed up across chains.
Answer: 251906.0

User story: "The orderer/shim needs to check that the peer's certificate links back to a CA that's referenced in the channel's genesis/reconfiguration block."
Answer: 48601.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Here's a way of going at it:    1. Modify the Docker image so that it spawns three Kafka brokers instead of one.  2. Use a replication factor 3 for created topics.  3. Have the Producers and Deliverers use the Metadata API to find out which broker is the partition leader replica for the given partition, and have the route their requests to it.  4. Verify that everything works.  5. Kill the broker process that owns this replica.  6. Verify that the Producers and Deliverers are using the Metadata API correctly and are rerouting their requests to the new leader.    (That flow may be edited - it is just a suggestion kick things off.)    Let's create linked tasks for the individual work items if necessary, but I would suggest using this story for all related comments, so that we have a single point of reference."
Answer: 48106.0

User story: To those of us looking at the Hyperledger fabric (HLF) from a hardware point  of view, the current default of using SHA-3 for block hashing, and in other  HLF proposals has been confusing for several reasons:    1. According to NIST:        "NIST encourages application and protocol designers to implement SHA-256      at a minimum for any applications of hash functions requiring      interoperability."        "Currently there is no reason to transition applications from SHA-2 to      SHA-3"        http://csrc.nist.gov/groups/ST/hash/policy.html     (Updated September 14, 2016)    2. Current Intel, IBM and ARM server processors provide instruction set  support for accelerating SHA256.    3. Multiple vendors offer low-cost, low-power ASICs with validated  implementations for accelerating current internet security standards that  include SHA256. Components like these might also prove useful for accelerating  HLF applications.    4. Although it is not my area of expertise, I am not aware of any network  security standards that require SHA-3. I do know that the latest draft of the  TLSv1.3 specification does not mention SHA-3:           https://tools.ietf.org/html/draft-ietf-tls-tls13-18               (Updated October 26, 2016)    We can speculate on whether or not we will see widespread hardware support for  SHA-3 acceleration until or unless SHA-3 becomes part of such a standard.    Given the above, it seems premature for the HLF to default to the use of  SHA-3, which use is pervasive throughout the HLF codebase. I would suggest that  all HLF components of the V1 architecture be immediately modified to default  to the use of the recommended SHA-2 family of hash functions. I consider this a "bug" because it impacts interoperability, and it is important to correct the default behavior prior to the V1 code release.  
Answer: 767124.0

User story: "Experimental changes to simulate concurrent transactions for Fabric 1.0.  This task is to support the actual work described here : https://jira.hyperledger.org/browse/FAB-799.  Once the changes are available, need to measure the performance withe these changes"
Answer: 112653.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: "Everyone should add a detailed writeup on what their test does and why it is important to be included in the daily test. "
Answer: 263731.0

User story: "The purpose of this topic is to provide a home for continued discussion and refinement of the overall architecture document that appears here:   https://github.com/hyperledger/fabric/blob/master/proposals/r1/Next-Consensus-Architecture-Proposal.md    An earlier version of this architecture document is still available here:    https://github.com/hyperledger-archives/fabric/wiki/Next-Consensus-Architecture-Proposal  The related discussion, which precedes the discussion intended for this topic, appears also under hyperledger-archives on github:    https://github.com/hyperledger-archives/fabric/issues/1631  "
Answer: 1424019.0

User story: "Ensure that gossiping network will be able to support multi channel policy restriction and provide clear and secure separation between different channels. "
Answer: 108540.0

User story: As was discussed, gossip component will run some flavor of leader election to decide on dedicated ("first-order") peers. These dedicated peers will open connection to the ordering service to receive block via "deliver" protocol and initiate gossip of those block over the peers gossip network.
Answer: 66390.0

User story: "The fabric-next protos were recently merged ( https://gerrit.hyperledger.org/r/#/c/1977/2 ) so now all of the temporary protos defined for atomicbroadcast, especially for configuration must be abandoned in favor of the generic set."
Answer: 19228.0

User story: "In fabric v1, the various clients SDKs have been moved (or created as) separate repositories.  We need to remove the SDK from the core fabric repo"
Answer: 3955.0

User story: "# Move peer to peerold and peernext to peer.  # Rename ledger to ledgerold and ledgernext to ledger.  "
Answer: 2721.0

User story: "The new model requires multiple changes to the current CLI, including:  # Chaincode life-cycle  supports like deploy, invoke, query, upgrade  # Additional admin commands such as logging, status of peer and orderer    We no longer technically require deploy, invoke, query transactions since all are handled by the life-cycle system chaincode, so these various transactions are just function calls on the life-cycle system chaincode.  However, for clarity at the user level, the CLI should provide explicit specification for each deploy, invoke, query, and update."
Answer: 1321861.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 issue is created for v1.0, to provide an API as suggested (gRPC) for the peers to provide as many details as possible about their replica state. This should help a network manager determine whether the peer is participating in the network, or is byzantine or not.    Reference FAB-707 for more details.  After VP3 restarted, it missed some sequence numbers for transactions that occurred while it was down, so it advanced its view requested a viewchange - but the network had not advanced its view. So VP3 ledger lags behind, and VP3 sends repeated viewchange requests, until the rest of the network decides on a viewchange. At this point, VP3 is a "spare" validating peer node, that could participate if other working nodes stop - but there is not a good way to tell if it is in this state or is intentionally byzantine.    > As a Network Operations Manager/Observer, how can I determine the health of the network? Can I tell how many peer nodes that can be counted on, at any given moment? That would be the sum of the number of valid nodes plus any such as VP3. Or it might the the sum of functional nodes minus the number of byzantines. Let me rephrase: a network management tool could ping all the peers in the network to see which are functioning. It could also query them all to see their chainheights or chaincode data values. It would observe VP3 is lagging. Is it considered byzantine? Or, could the tool determine whether VP3 is "giving an honest effort" and is in such a state that it could help the network (eventually) if it becomes necessary due to other node faults? How could it distinguish between an OK node like this and a truly faulty/byzantine node?    Under true byzantine conditions, you can always be assured the there are f+1 correct peers actively participating in the network. You may be able to identify replicas which are not actively participating by examining their chain heights, but this is not foolproof. It's essentially impossible to determine byzantine from best effort, the best you could hope for is for the replica to report that it knows it is out of sync. For future work, I think it would be a good idea to include a gRPC call to get replica state (whether its view is active, what view, what seqno, etc.), but in v0.5/0.6 there is nothing of this sort.  
Answer: 223248.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: Reference FAB-707 for more details.  After VP3 restarted, it missed some sequence numbers for transactions that occurred while it was down, so it advanced its view requested a viewchange - but the network had not advanced its view. So VP3 ledger lags behind, and VP3 sends repeated viewchange requests, until the rest of the network decides on a viewchange. At this point, VP3 is a "spare" validating peer node, that could participate if other working nodes stop - but there is not a good way to tell if it is in this state or is intentionally byzantine.    This issue is for implementing an optimization to stop VP3 and other "spare" nodes  from forever sending viewchange requests every 2 seconds, in this situation. As many as "F" nodes could broadcast these wasteful, confusing, useless messages into the network.   
Answer: 237711.0

User story: "We've designed this out in the open, and all the logic is written down in the various JIRA issues that belong to FAB-32, and in #fabric-consensus-dev.    However, it's necessary to wrap everything up in a single document that acts as a point of reference."
Answer: 44723.0

User story: "This relates to fabric application security, and aims to define and implement an interface of a library that an application developer can use to enhance proposals/transactions with certain encryption-based confidentiality mechanisms."
Answer: 533121.0

User story: "This item reflects the work needed to design an interface for membership services operations (issuing/managing certificates, and authentication mechanisms using those certificates) in a way that that interface does not depend on the exact implementation/cryptographic primitives that the membership service uses.   This interface is to be integrated to core operations of the fabric, such that a fabric deployer who wishes to substitute only membership service component of the system, is able to do so without affecting the code of fabric core/transaction processing.   Wee need to define one interface used by the infrastructure (verification MSP interface) and one for the client to construct transactions (retrieving the corresponding certificates), and signing with its secret key.  "
Answer: 130999.0

User story: "The assumption is that all chaincode will run in one CouchDB database for the system ledger, and there will be separate databases for each subledger."
Answer: 17227.0

User story: "We currently have a number of administrative API defined in server_admin.proto and devops.proto. We need to re-evaluate these, especially devops since most functions are taken care of by the life-cycle system chaincode. "
Answer: 322168.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 want to be able to send a ConfigurationEnvelope that calls for the creation of a new ChainID, and have a new chain created. I then want to be able to then broadcast and deliver on that chain.    This story will NOT cover the following: The logic that turns a new-chain ConfigurationEnvelope and creates an appropriate genesis block for that new chain. The code that will be delivered with this story will keep using the same genesis block (the one returned by the static bootstrapper)."
Answer: 79773.0

User story: "Details on the API here: https://docs.google.com/document/d/1eRNxxQ0P8yp4Wh__Vi6ddaN_vhN2RQHP-IruHNUwyhc/edit"
Answer: 148984.0

User story: "I expect a combination of FAB-593, FAB-704, FAB-705 to come handy here."
Answer: 46225.0

User story: "I expect that this is covered by the work in https://gerrit.hyperledger.org/r/#/c/1795/"
Answer: 105655.0

User story: "As a peer wishing to create a channel for private transactions with another peer (or peers), I need to know what the new-channel configuration transaction looks like (fields, values, etc.). This is essentially the transaction that the API described FAB-687 will create.    Part of this (or all of this) may be covered by: https://gerrit.hyperledger.org/r/#/c/1795/"
Answer: 68263.0

User story: "I would like to add a configuration option to enable the standard Go net/http/pprof service in the orderer. It would be configured just like the service is in the peer, with two new YAML configs options:    profile:      enabled: false      listenaddress: 0.0.0.0:6060"
Answer: 17358.0

User story: "API requires signature, so only those on chain may access. Additional members may be granted access using either attributes or individual certificate."
Answer: 276812.0

User story: "By default, only those on chain may listen to events from that chain. Additional members may be added to the ACL via individual certificates or attributes."
Answer: 276818.0

User story: "In the endorsement model, a chaincode may be called concurrently to simulate the transaction against the ledger. This doesn't require serialization since each simulation keeps track of own MVCC to be validated during commit. "
Answer: 157299.0

User story: "The ordering service has multiple ordering providers, including kafka and solo.  Because each service must implement the same ordering api, there are significant functional duplication between the codebases.    This story is intended to cover the work of identifying the common components, abstracting them out, and ensuring that both handle configuration and reconfiguration as well as transaction filtering the same way."
Answer: 107717.0

User story: "This story outlines various failure scenarios for events and methods to handle them. It also covers additional requirements for the sdk and peer."
Answer: 1327709.0

User story: "Initial assessment is complete.  Senthil please attach a community-friendly copy of the performance assessment to this work item."
Answer: 45993.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: "RocksDB has a patent infringement license in it from Facebook. The legal team is therefore not comfortable with using it. For details read: https://github.com/facebook/rocksdb/blob/master/PATENTS    The alternatives include  1. LevelDB (https://github.com/google/leveldb) with a go wrapper (https://github.com/jmhodges/levigo),  2. *goleveldb* (https://github.com/syndtr/goleveldb) - a porting of leveldb in golang  3. BoltDB (https://github.com/boltdb/bolt)    BoltDB is suitable for read heavy workloads (e.g., LDAP) but has a relatively poor performance for read-write workloads.  Of the other two options, *goleveldb* is chosen because it is implemented in golang and hence easy to intergate and maintain.  In addition, as a precedent, ethereum go implementation also uses this package (https://github.com/ethereum/go-ethereum/blob/master/ethdb/database.go)"
Answer: 37287.0

User story: "Modify our node.js SDK tests, to eliminate copy of entire Fabric, and instead the tests should dynamically retrieve. (The required actual modifications will depend on the solution offered by FAB-11, upon which this issue is blocked). We can significantly reduce the space required in every copy of the tests saved in the release-criteria repository, or in Fabric itself, and reduce the time to deploy as well.  "
Answer: 515594.0

User story: "We need to add chain id to the protocol for endorsement and transaction so that the peer knows which chain to operate against."
Answer: 8785.0

User story: "We are using HTTP codes for GRPC API, and we need to document those with the API so that app/SDK may check for them"
Answer: 325336.0

User story: "In order to fully enable dynamic set of peers capability nodes should be able to communicate and make state synchronization via gossip protocol."
Answer: 68075.0

User story: "Gossip protocol has to support dynamic set of peers and provide an ability of state synchronization and missing block completion. "
Answer: 41124.0

User story: "Implement gossip communication abstraction, this should include:    * Discovery + Membership of new nodes  * Communication module  * Push/Pull mechanism  * Impersonation prevention"
Answer: 75167.0

User story: "Direct communication between consenters and peers. Have a consensus client on the peer implementing necessary logic based on the consensus algorithm (for example collect t+1 identical blocks for pbft)  "
Answer: 158563.0

User story: "Provide GRPC API for application to listen to events"
Answer: 326106.0

User story: "Provide GRPC API for application and CLI to query blockchain, including by block number, transaction by id.  Note that the API requires signature and access control"
Answer: 326125.0

User story: "Define a GRPC API for client to submit a transaction to Orderer (ie broadcast and deliver).     This is currently in ab.proto, which we need to beef up the description on error conditions."
Answer: 27632.0

User story: "Define GRPC API on Endorser Peer to allow submitting a Proposal and for app to tell a peer to join a channel"
Answer: 27487.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: "set up a version of this test suite on each machine type required; it will include a cross-section of all our automated test coverage areas; one or more long runs may be run in parallel, for each test coverage area:  - go sdk addrecs/concurrency 72 hr longrun - performance tests via behave, or node, etc. - other"
Answer: 106436.0

User story: "set up a version of this test suite on each machine type required; it will include a cross-section of all our automated test coverage areas"
Answer: 27312.0

User story: "set up a version of this test suite on each machine type required; it will include a cross-section of all our automated test coverage areas"
Answer: 280838.0

User story: "Modify tests as needed for automation, and submit to correct repo/branch: master, v0.6  This is for tests that more comprehensive than those Behave tests and unit tests that are run with each code submission.    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: 15925.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: 280831.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: 280692.0

User story: Define a long-running (10-72 hrs?) automation test suite, for weekly or bi-weekly test runs during development and testing phases of hyperledger/fabric v1,0 (and v0.6), using the latest successfully built images (which passed unit tests and behave, per existing guidelines for code submissions).=  (Another epic 516 will handle actually running and displaying results.)    Long Run Test Suite: (10-72 hrs) - DIFFERENT tests from Daily Suite  *                 GO SDK - Consensus CRT*, LargeNetwks    (uses REST) scott  *                 GO SDK - Ledger Long LST*               (uses REST) scott/nishi  *                 Node.js Concurrency with Auction        (uses Node) nishi  *                 Complex Transactions with Auction       (uses Node) nishi  *                 Performance engine tests                (uses Node) <USER> **                  - verify can handle fixed-rate "supported" number of Tx per sec  **                  - repeat for various durations, 1 or 10 or 60 minutes  **                  - measure for variable traffic rates, and burstiness  **                  - find the max Tx per sec that can be handled in 1 or 10 or 60 minutes  **                  - sequential and concurrency  
Answer: 281010.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: "Define a daily (6-8 hrs?) automation test suite.  This could be run daily with the latest successfully built images (which passed unit tests and behave, per existing guidelines for code submissions).  This will include a few tests for functionality and APIs in each test area.  (Another epic 516 will handle actually running and displaying results.)    Daily Test Suite: (up to 22 hrs; jenkins could use a few parallel machines)  *                 GO SDK - Consensus CAT*                 (uses REST) scott  *                 GO SDK - Ledger LST*                    (uses REST) scott  *                 GO SDK - Concurrency/Ledger             (uses REST) scott/nishi  *                 Node.js Concurrency with Auction        (uses Node) <USER> *                 Complex Transactions with Auction       (uses Node) nishi  *                 Performance engine Baseline tests       (uses Node) <USER>"
Answer: 281012.0

User story: "Create a short (1-2 hrs?) automation test suite to execute tests that are submitted to community hyperledger fabric.  This could serve as a preliminary smoke test, before kicking off longer test suites.  This will include a few tests for basic functionality and APIs in each test area.  (Another epic 516 will handle actually running and displaying results.)    When code is merged:  # Run First: Smoke Test Suite (15 minutes maximum)  *                 REST    API one-time tests, bring up network, deploy, invoke/query all 4 peers.  Also? Stop 2 peers to confirm network halts, restart 1 to confirm it resumes. Drive from Behave (Latitia)  *                 node    API one-time tests, bring up network, deploy, invoke/query all 4 peers. (nishi)  *                 Performance engine quick test: time for 1000 Tx (<USER>    # Run Second, if Smoke Test passes: make all Unit Tests:  *                 same as today, includes all current and new Behave tests (Latitia), plus  *                 all the Node UT being submitted this month (Allen, Janet)  "
Answer: 281015.0

User story: "Dissemination layer has to provide an ability of dynamic addition for new peer members, it has to be able to recover from network partition and congestion. Moreover it has to preserve node state integrity.    New coming or lagging peers will use the capabilities of this module to synchronize their state from the neighbor peers. "
Answer: 28712.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 of 0.9, Kafka supports TLS for client/broker and inter-broker communication.    We need to enable it, and also make sure that when a shim or broker is added/removed, the ACLs are updated accordingly.    There are no APIs provided by Kafka for this, so we will have to resort to executing scripts.    https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Authorization+Command+Line+Interface  http://www.confluent.io/blog/apache-kafka-security-authorization-authentication-encryption/    Some more context here: https://hyperledgerproject.slack.com/archives/fabric-consensus-dev/p1477597906002876    Feel free to break this story into tasks, but let's use this as a point of reference for comments and discussion."
Answer: 164846.0

User story: There are times (depending on version of docker being used) that when stopping or starting a peer the resulting output returns the service name and not the container name.     There should be checks in place that will ensure that the container name is what is being saved in the context for future use. (e.g. when trying to perform "docker inspect" on a container)
Answer: 32767.0

User story: "During bootstrap, a peer may receive a list of channels to join so that it can participate in private transactions.     After having successfully completed the connection to orderer, the peer joins the channels and initiates sync for each channel/ledger.  "
Answer: 264599.0

User story: "A callee chaincode needs to run in a different context than its deploying context so that we can optimize the deployments of chaincodes. Specifically, when a chaincode deployed on system chain, it should be able to run on any chain using that chain context.    See the Epic for more info"
Answer: 1443847.0

User story: There is currently only one supported way to deploy a peer: build it from source.  This is because we currently rely on the build to produce several synthetic artifacts (baseimage:latest in older versions of the code, ccenv:latest in newer).  Going forward, we would like to support use cases where deployments may be as simple as doing something like "docker run hyperledger/fabric-peer" and all the of the correct things happen including ensuring that the peer environment has the full set resources it needs to run chaincode, etc.    Today, we formally publish baseimage, membersrvc, and peer.  We need to also add ccenv and javaenv to the mix, and ensure the peer/clients are prepared to reference them properly.  This is a task to track the basic notion of "binary deployment".  Until this task is complete, the only supported way to run the peer is from an environment that can complete "make peer" from the fabric.git sources properly.
Answer: 180056.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: "Bootstrap a peer    To start up and connect to a consensus service, a Peer requires at least the following configurations:  # An enrollment certificate to participate in the network. The certificate may come from any CA as long as the CA is part of the trusted roots on the consensus service that the Peer will connect to  # A list of the Orderer certificates and IP addresses, which the administrative CLI from the consensus service can generate  # A list of trusted roots  # An optional list of channels that the Peer should subscribe. Unless explicitly configured, the Peer does not subscribe to any channels upon starting up    Either via CLI or application using SDK API, a Peer can be instructed to subscribe to existing channels. Access control on whom may join a channel is performed by the Orderers with the information given during channel creation or reconfiguration thereafter.  "
Answer: 285135.0

User story: "given a genesis block as defined in fab-665,  start an orderer node"
Answer: 261094.0

User story: "on orderer bootstrap, verify that inputted genesis block is valid"
Answer: 261096.0

User story: "We need a tool (CLI) that accepts the necessary inputs and generate a file, which will be used by orderers and member peers on start-up."
Answer: 167665.0

User story: "Decide on who should decide the number of orderer nodes and how that information is distributed to the nodes"
Answer: 261097.0

User story: "Use this story to work with security team on how to generate the CA certs and how to distribute to the bootstrap admin"
Answer: 261090.0

User story: "Create, run, and automate tests for networks larger than the standard 4-peer pbft network. Local environment only."
Answer: 33309.0

User story: "create instructions and videos for using docker-compose to create network or dev environment with fabric-peer and fabric-membersrvc images from DockerHub..."
Answer: 41471.0

User story: "This is an issue for detailed documentation of the design of a library that features invocation access control capabilies at the application layer. It also includes the design of a library used by the client application and the chaincode to enable attribute-based client authentication."
Answer: 913210.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: "Few things need to be done to clean up the fabric post skeletal end-to-end flow to get it ready for the community to do full-fledged new architecture work.     This can be divided into three categories  * merge -  this can be done in three ways  {quote}# merge `master` to `convergence` and then clean up  # merge `convergence` to `master` and then clean up  # clean up `convergence` and cherry pick fixes from `master` (see https://gerrit.hyperledger.org/r/#/c/1633 for a WIP on this approach){quote}    * clean up -  started list laundry list of sub-tasks (again, see https://gerrit.hyperledger.org/r/#/c/1633)  {quote}* remove vestiges of `ledger` and use only `ledgernext` in chaincode framework  * remove `consensus` from 'peer` executable  * get chaincode unit tests to use ledgernext  * remove encryption / decryption from chaincode{quote}    * use protobuf definition   {quote}* finalize protobuf definition (see https://jira.hyperledger.org/browse/FAB-489)  * remove old protobuf definition (such as protos.Transaction)  * use new protobuf definition{quote}    *{color:#d04437}The first thing to decide if we are going to merge or cherry pick.{color}*"
Answer: 253450.0

User story: Remember that our goal is to make this "Kafka orderer" layer that now stands between the client and the broker as thin as possible. We want to let Kafka do most of the work, since it's a well-tested and performant solution and we don't want to replicate any of its functionality.    The Kafka orderer does two things:  # It batches transactions into blocks (which we should stop doing by the way, because Kafka can do it for us), and  # It creates a hash-chain between the blocks    In this story, we should explore the various ways with which we can create hash-chain with Kafka. Our goal is to find (a) the one that performs best (i.e. is the fastest), and (b) uses as less custom code as possible.    Suggestions:  # [~<USER> suggested that it may be worth looking into Kafka Connect.  # I haven't studied it carefully but I am wondering whether the new Kafka Streams functionality can get us there.  # Finally, there is always the option of creating a hash-chain via checkpoint messages, an idea that was first suggested by Chet Murthy: every K messages received, each client broadcasts a checkpoint message via the orderer that is the hash of this concatenation: (previous checkpoint hash + K most recent messages)
Answer: 107029.0

User story: "One of our goals with the Kafka-based orderer is to have it act as a benchmark of sorts for the throughput and latency we can achieve. We need to instrument the code so that we can derive these metrics. The Go library that we're using for Kafka has built in support for the go-metrics library: https://github.com/rcrowley/go-metrics I am not sure whether this is enough to cover our needs or whether we'll need to go deeper."
Answer: 1128724.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: " //VerifyChain will verify the integrity of the blockchain. This is accomplished   // by ensuring that the previous block hash stored in each block matches   // the actual hash of the previous block in the chain. The return value is the   // block number of lowest block in the range which can be verified as valid.    Also we need to verify that state database is correct, or have an option to rebuild it to ensure it is correct.  "
Answer: 1733965.0

User story: "From the code comment after processing the backlog:    We arrived here because either all is fine, we're with the pack.  Or we have messages in the backlog because we're connected asymmetrically, and a close replica already started talking about the next batch while we're still waiting for rounds to arrive for our current batch.  That's still fine.    We might also be here because we lost connectivity, and we either missed some messages, or our connection is bad and we should reconnect to get a working connection going again.     If a noFaultyQuorum (-1, because we're not faulty, just were disconnected) is backlogged, we know that we need to perform a state transfer.  Of course, f of these might be byzantine, and the remaining f that are not backlogged will allow us to get unstuck.  To check against that, we need to only consider backlogged replicas of which we have a hello message that talks about a future Seq.     We need to pick the highest Seq of all the hello messages we received, perform a state transfer to that Batch, and discard all backlogged messages that refer to a lower Seq.    Do we need to detect that a connection is stuck and we should reconnect?  "
Answer: 40208.0

User story: "If the backlog limit is exceeded, discard all messages with Seq before the replica's hello message (we can, because we can play forward to this batch via state transfer).  If there is no hello message, we must be really slow or the replica must be byzantine.  In this case we probably should re-establish the connection.    After the connection has been re-established, we will receive a hello, and the following messages will trigger the pruning of old messages.  If this pruning lead us not to make progress, the backlog processing algorithm as lined out below will take care of starting a state transfer, using the hello message we received on reconnect.  "
Answer: 39170.0

User story: "Ledger versioning scheme: I want to use the block/transaction height as a variable's version, instead of an incrementing version number, so that I have traceability between state data and transaction data"
Answer: 89632.0

User story: "ledgernext was initially delivered in sprint1 to quickly unblock dependent components, in this task the simulation and state management code will be hardened, for example to ensure the state index is always consistent with the blockchain ledger."
Answer: 99722.0