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: "The envelope header contains a timestamp and epoch both of which are ignored by the ordering service today. But, these should be leveraged for message replay prevention.    This will require synchronizing with the SDK/peer team to make sure these parameters are correctly set."
Answer: 1630299.0

User story: "Proposal is to add a setInfo() on the simulator, for the chaincode to pass some transaction context that is to be used later for validation in VSCC, without anything getting written to permanent state (therefore don't want to use WriteSet).  This information would get included in the simulation results in the transaction, and VSCC would be able to reference it when performing custom validation logic.    (Murali, please fill in your immediate use case for it)."
Answer: 1631433.0

User story: "Per discussion with [~<USER> [~adecaro] and [~<USER> the MSP managers would like to provide their own policy evaluation options.  This would be in addition to the NOutOf policies, but would exist within the current framework.    This story is to make the existing policy manager pluggable with different policy providers, so that the MSP manager may provide a policy provider for MSP type policies."
Answer: 42087.0

User story: "The gossip components uses the MessageCryptoService interface to verify the validity of ledger blocks and signatures.  Ledger blocks carry information about the chain/channel they are related to and so an implementation of MessageCryptoService can access the information related to the specific chain in order to validate a given block.    Standalone signatures refer to GossipMessages that might or might not be chain-dependent. In the case a GossipMessage is chain-dependant, the signature should be verified against the chain MSP. Therefore MessageCryptoService should be enhanced to have a verify signature method that takes in consideration also the channel.     For non-channel related messages, the validation strategy can demand validation against any chain the gossip node belongs to.    [~<USER> [~<USER> [~<USER> [~<USER> [~<USER>, please have your take on this. Thanks all :)  "
Answer: 98942.0

User story: "We need to change the definition of common.Header to ensure that each of the two headers is serialized as bytes. This way proposalHash can be computed over each of the two byte arrays as opposed to the serialization of common.Header. This is required because at transaction time, the headers are split in two (ActionHeader has a SignatureHeader and the Transaction has a ChainHeader) and the two need to be assembled before computing the hash. If protobuf serialization is not deterministic, then we might have a problem when reconstructing the proposalHash"
Answer: 102464.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 was suggested by [~<USER> in CR (https://gerrit.hyperledger.org/r/#/c/3259/) related to FAB-1384    {quote}  The other thing I wanted to mention, is that with this changeset, the committer's ledger is no longer a 'ValidatedLedger' (invalid tx removed). Rather it is now a raw ledger (with invalid tx marked). Therefore instead of keeping the names RawLedger and ValidatedLedger in ledger_interface.go, I think the more accurate names would now be OrdererLedger and CommitterLedger, respectively. These names would be more expressive for their intended use. Let's see if Manish agrees.  {quote}    and according to [~<USER>    {quote}  Yes, I'm fine with the new names proposed by Dave. But, I think that we can change that later in a separate commit - in order to keep the  conflicts with the refactoring to low.  {quote}    Creating new story to follow up on that and eventually refactor interfaces names."
Answer: 49244.0

User story: "Current GetRows function returns rows which matches the key (Key could be composite key). There is no provision to obtain rows between range of keys. I would like to see API to fetch range. The code should look like below. (Note: this is not tested code)  Due to formatting issues, code is removed and chaincode.go file is attached. Please look for functions GetRows, GetRowsRange and getRowsInternal"
Answer: 174563.0

User story: "When log level is set to debug, the orderer write the entire contents of the blocks it prepares and sends twice to the log file. These blocks can get rather large and make the log file less useful. Invoking the lifecycle system chain code, for example, results in a 7MB block. The entire block is added to the log file twice, encoded in 2 different formats, for a total of about 50MB written to the log for a single Block.    These are the log entries that contain the dumps of the Blocks:    orderer_1  | [18:57:32.260]    broadcast.go:98: [DEBUG] Prepared block 1 with 1 messages  orderer_1  | [18:57:37.380] client_deliver.go:140: [DEBUG] Sent block 1 to client  "
Answer: 151303.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: "Per some performance testing feedback from [~<USER> it's much more efficient if we allow HTTP2/gRPC to handle the connection data windowing rather than attempting to implement it ourselves at a higher layer.    In order to remove windowing from deliver, there must be some other mechanism supplied to allow a client to retrieve a specific number of blocks.  This means that the Deliver API must also be enhanced to allow range specification."
Answer: 31836.0

User story: "Part of an orderer's bootstrap configuration is the certificate and private key to be used by the orderer for TLS authentication between it and Kafka.    Normally, the private key is stored in a file that is passed in to the orderer.    We need to see what to do for HSM or other scheme where the private key is stored in hardware. "
Answer: 1635827.0

User story: "In Gossip we have 2 types of entities that are sent around:  1) Entities that never change after their creation, like blocks and certificates  2) Entities that change with time, like AliveMessages (contain timestamp, that changes on a timely basis) and StateInfo (contains both timestamp and metadata what encapsulate block sequence number that change)    I did some work to generalize the pull mechanism for type-I entities:  https://jira.hyperledger.org/browse/FAB-1292  https://gerrit.hyperledger.org/r/#/c/3023/    I think it's a good idea to consolidate the mechanism that are used for type-II entities into a single mechanism.    Basically the mechanism is very simple and roughly goes like this:  A peer selects periodically a set of remote peers and sends them a request for a snapshot of all their known entities.   It gets back a full snapshot of all entities.    Note: any work should *not* be started on this until multi-channel support in gossip is finished, as it touches the same files."
Answer: 1636027.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Currently gossip interface is defined as follows    {code}    // Gossip is the interface of the gossip component  type Gossip interface {     // GetPeers returns a mapping of endpoint --> []discovery.NetworkMember   GetPeers() []discovery.NetworkMember     // UpdateMetadata updates the self metadata of the discovery layer   UpdateMetadata([]byte)     // Gossip sends a message to other peers to the network   Gossip(msg *proto.GossipMessage)     // Accept returns a channel that outputs messages from other peers   Accept(common.MessageAcceptor) <-chan *proto.GossipMessage     // Stop stops the gossip component   Stop()  }  {code}    Whereas functions    {code}   // GetPeers returns a mapping of endpoint --> []discovery.NetworkMember   GetPeers() []discovery.NetworkMember     // UpdateMetadata updates the self metadata of the discovery layer   UpdateMetadata([]byte)  {code}    Doesn't really relate to the message dissemination, therefore current gossip interface should be abstracted out in two separate interfaces:    1. Broadcast/Gossiping taking care of message delivery and reception.   2. Discovery/Metadata managing current gossip view of available nodes/peers.    Moreover GossipService interface currently aligned with Gossip above and serves as adaptor for initialized gossip instance and encapsulates also state management. Because one of the goals for GossipService interface is to expose capabilities of disseminating messages externally, the interface which takes care of messaging and communication should be refactored to decouple the API from protobuf defined messages.     {code}  // GossipService encapsulates gossip and state capabilities into single interface  type GossipService interface {   gossip.Gossip     // JoinChannel joins new chain given the configuration block and initialized committer service   JoinChannel(committer committer.Committer, block *common.Block) error   // GetBlock returns block for given chain   GetBlock(chainID string, index uint64) *common.Block   // AddPayload appends message payload to for given chain   AddPayload(chainID string, payload *proto.Payload) error  }  {code}     and signature of Gossip method is    {code}           Gossip(msg *proto.GossipMessage)  {code}    Now it should be refactored to generalize usage of gossip API and not to bound it with proto.GossipMessage."
Answer: 1637014.0

User story: "In CR 2697 introduced new functionality to extract chain id from configuration block, need to make sure to switching using it, once it get merged. This item created to track comment from 3175."
Answer: 5864.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Currently GossipStateProvider expose following APIs    {code}  type GossipStateProvider interface {     // Retrieve block with sequence number equal to index   GetBlock(index uint64) *common.Block     AddPayload(payload *proto.Payload) error     // Stop terminates state transfer object   Stop()  }  {code}    Where method   {code}  AddPayload(payload *proto.Payload) error  {code}    is used to populate local state with new block arrived, while AddPayload is not very descriptive name, moreover it enforce following usage during submission:    {code}   payload := createPayload(seqNum, block)   // Use payload to create gossip message   gossipMsg := createGossipMsg(payload)     // Add payload to local state payloads buffer   state.AddPayload(payload)  {code}    meaning creating gossiping payload and gossip message, while it's much cleaner to simply submit new block in following way:    {code}   payload := createPayload(seqNum, block)   // Use payload to create gossip message   gossipMsg := createGossipMsg(payload)       // Add payload to local state payloads buffer     state.AddPayload(block)  {code}    Therefore interface should be refactored into:    {code}  type GossipStateProvider interface {     // Retrieve block with sequence number equal to index   GetBlock(index uint64) *common.Block     SubmitBlock(block *common.Block) error     // Stop terminates state transfer object   Stop()  }  {code}    And also need to make sure GossipService interface will be aligned and will look as following:    {code}  // GossipService encapsulates gossip and state capabilities into single interface  type GossipService interface {   gossip.Gossip     // JoinChannel joins new chain given the configuration block and initialized committer service   JoinChannel(committer committer.Committer, block *common.Block) error   // GetBlock returns block for given chain   GetBlock(chainID string, index uint64) *common.Block   // SubmitBlock submit block into local ledger   SubmitBlock(chainID string, block *common.Block) error  }  {code}"
Answer: 1274280.0

User story: "In the version that was rebased on top of the common components, this option was kept out in order to minimize the complexity of the changeset. The deliverable of this story is a Kafka consenter that respects the BatchTimeout config option.    "
Answer: 49447.0

User story: "As things stand right now, the config it posts only works for solo. The client should have an extra flag that allows us to specify the consenter type, and then, by using the provisional bootstrapper, it should create the appropriate config."
Answer: 12916.0

User story: "Per [~<USER> comment in https://gerrit.hyperledger.org/r/#/c/3169    {quote}can you add a general error check that the block number requested is lower than the highest available block. This is not specific to getLastBlock but somehow just noticed this now.{quote}"
Answer: 1638589.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 is motivated by the fact that Kafka imposes restrictions on the allowed topic names:  https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/common/Topic.scala#L29    Regardless of that, we should adopt similar restrictions.    Ideally, these will be a superset of the Kafka restriction set so that we don't have to add any extra code for the Kafka consenter case."
Answer: 80296.0

User story: "When a committer receives a transaction that contains conflicting endorsements, we should consider dropping it before it reaches VSCC. If we determine that this is not necessary because VSCC should do it, we should ensure that VSCC expressly checks for this condition (and add unit tests that verify this fact)."
Answer: 190008.0

User story: "as a potential Fabric application developer, I want to have up-to-date documentation while v1.0 is under development. Specifically, I want to be directed to v0.6 if I am looking for stable operational platform, and I want to have documentation about how to use the v1.0 Fabric as it is being developed."
Answer: 177174.0

User story: "fabric , corda , sawtooth , iroha"
Answer: 96818.0

User story: "Today, the orderer is using the functions defined in `fabric/protos/common/block.go` for hashing the block header and data.    These functions are _definitely_ wrong, and were never intended to be long term solutions.  These functions need to be fixed to use a hashing algorithm and marshalling scheme (and possibly using a wide Merkle Tree for the BlockData).    This was discussed somewhat extensively in https://gerrit.hyperledger.org/r/#/c/1361/ but no conclusion was reached."
Answer: 82544.0

User story: "Today, the orderer initializes loggers in almost every package, and statically sets their logging levels.  This was easy to speed development along, but this really needs to be configurable for the whole ordering process in a sane way, ideally lifted from the peer flogging stuff."
Answer: 50721.0

User story: "Develop scripts to be used in connectathon activities Dec 17th, that must work on all hyperledger-supported-versions of required tools docker, docker-compose, bash, yaml file versions, etc. Work with Mihir and others to use Marbles as the chaincode deployed in this workitem.  * create a script to start a simple hyperledger-fabric v1.0 network with cop, orderer, and first peer and deploy chaincode.  * create a script and instructions for any friendly partner to download and create their own peer on their own machine and join the network  * instructions should explain as necessary how to exercise the network functions    Also, all the team is helping test this solution before the connectathon..."
Answer: 10727.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 is a work item aiming to explore alternatives for MSP identifiers within Fabric and finalize the ones supported by the default MSP provider.   Current alternatives    - Use a dedicated field inside the identity structure that is checked by the related MSP at identity import/deserialization/creation time.    - Use an existing field of the identity structure, e.g.,        * the OU field inside the X.509 certificates       * a subset of the OU field inside the X.509 certificate  "
Answer: 106874.0

User story: "This is to setup and confirm that P11 csp on Java SDK works. "
Answer: 1640623.0

User story: "This epic includes two groups of issues mainly given that a BCCSP factory has already been built in nodejs:    1) building a BCCSP for PKCS11 (leveraging the nodejs P11 bindings)   2) ensuring that crypto calls within the client infrastrucure are all routed through the BCCSP    Item (2) we can do in two steps:    2.1) refactor the code in the client to expose an application MSP interface as the one defined in FAB- ..., and   2.2.) enforce that the refactored code's crypto operations leverage BCCSP       "
Answer: 1382732.0

User story: "Chain MSPs are setup using a chain's genesis block that contains a configuration transaction.  Hence, MSPs (or MSP Manager) takes as input a configuration block, and instantiates the MSPs associated to the chain according to the content of the configuration block.    Chain MSPs are re-configured in a similar manner. Re-configuration blocks (containing configuration transactions) are announced through the blockchain. MSPManager Reconfig function would need to take as input such a block, check authorization of the creators of this signatures, and then apply the changes imposed therein."
Answer: 56107.0

User story: "Write stress tests to measure open file handle and memory usage, with variable number of databases and transaction sets."
Answer: 176722.0

User story: "I need an API to get a list of chains of which a MSP is a member.  COP requires this in order to manage the CRL list in the chain's MSP configuration."
Answer: 192352.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Currently only two modes are available when using CouchDB - completely open (no user security) and completely locked down (user security enabled).  Production environments utilize the locked down configuration, while development environments may decide to skip user security in order to allow direct access.    If user security is enabled, only the peer's admin user can read/write to CouchDB.  No other 'external' users can access CouchDB - access is locked down and all requests must go through the peer's CouchDB user.    If it is desired to have 'external' users be able to read (only) CouchDB directly, two changes would be required:    1) Add the 'external' users to the CouchDB database security object as members.  See http://docs.couchdb.org/en/2.2.0/api/database/security.html .  Currently peer writes the database security object with just the peer's admin user upon each startup (allowing for the ability to change the username).  Note - it may be possible to use a server admin instead of setting the admins role on each database, and only populate the members role.     2) Any database 'member' would have both read and write access.  To lock it down for read access only, a CouchDB 'validation function' (deployed as a design document to CouchDB) would be required, it could enforce that only the peer's admin user could perform writes."
Answer: 1641812.0

User story: "The orderer currently relies on its own rawledger implementations, a simple ram based ledger (which does not persist anything to disk) and a simple file based ledger which uses a very naive JSON encoding with 1 block per file.    Neither of these are likely to scale well for real systems and have always been intended to be testing tools while the real ledger is developed.    A shim needs to be written between the orderer rawledger API and the fabric ledger api to support deploying with the fabric backing ledger for production deployments."
Answer: 132390.0

User story: "Today, chain creation requests are only validated based on the fact that they are well formed, and signed according to the policy for chain creation.    There is no checking to make sure that the orderers are specified correctly, that the orderer MSPs are included, etc.    What these checks are need to be determined as part of this story, as well as their implementation.  There is a plug point in the multichain systemChain.go code which is meant to handle this, but it currently is mostly a no-op."
Answer: 201476.0

User story: "In order to assess the health of the ordering service, we should expose basic metrics about the state of the ordering network like number of clients connected, transaction rates, chains and chain heights, etc."
Answer: 1059501.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 multichain work introduced a significant amount of state tracking and updating on a per chain basis.  This state needs to be stored in such a way that when the orderer restarts, it can restart all of the chains which were created and do so with their correct config.    This should additionally support whatever metadata that a consenter needs for restart, such as in the kafka case the last offset committed."
Answer: 53379.0

User story: "The broadcast API suffers from a deficiency today, that it immediately returns success/failure before the request has actually entered consensus.    The desired behavior would be to return success only after the request has entered consensus, but, this poses a problem when the broadcast queue overflows.  In the event that the broadcast queue overflows, incoming requests should be rejected to alert the client to slow down.    This results in the situation of:  1. Wait until after the queue drains to return the failure (which will not throttle the client and not provide immediate feedback, this is bad)  2. Return the success before the queue drains (which will not inform the client if for whatever reason the consensus system never actually accepts the request)    Since these options both have drawbacks and are mutually exclusive, a different solution is required.    This story is to add windowing to the broadcast API to mirror the deliver API.  If the client knows how big the buffer is at the server, then the client can delay sending new messages until it receives the success/failure after processing the queue.  If the client violates the protocol and overflows the queue, the client can be dismissed as malicious and hung-up on."
Answer: 38737.0

User story: "BDD tests make assumptions about networking the that prevent them from running successfully outside of the Vagrant environment.    Update the BDD tests to allow them to be run natively without Vagrant on any Linux/macOS environment."
Answer: 56412.0

User story: "Need to consolidate all gossip protobuf related files under project protos folder."
Answer: 90525.0

User story: "Gossip & Leader election layer has to expose the API to provide chain code with ability to ask whenever current peer is chosen to be a leader."
Answer: 851155.0

User story: "In order to allow chain code to leverage gossip capabilities, we need to expose and design API for system chain code usages. Such that it will allow to broadcast messages and receive messages from gossip communication layer."
Answer: 48669.0

User story: "In order to make clear what are the guaranties leader election based on the gossip will provide and to communicate the actual algorithm need to provide high level description plus pseudo code of the proposed solution.    Document will include assumption it requires from gossip layer and also will clarify expectations and guaranties leader election will provide. "
Answer: 90750.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: "Because nature of the new gossip leader election message is not immutable there is additional logic has to be added to provide support for dissemination of leader election message type."
Answer: 80870.0

User story: "Since leader election process will run on top of gossip communication layer to make decision which peers within organization has to connect to the ordering service, there is a need to broadcast customized message which indicate leadership decision of concrete peer. Message should include following information:    1. Information about peer which decided to become a leader  2. timestamp  3. Signature of the peer    Leader election mechanism need to make sure that *leader* peer will take care to periodically send this message to make rest of the peers aware of its aliveness."
Answer: 7393.0

User story: "The orderer has some common code which is of broader use to the fabric at large, not just the orderer.    In particularly, the configuration block parsing, and the policy parsing and evaluation are prime candidates for being shared in a modular way between the orderer and peer (and possibly other components).    This is being created in part by the request of [~<USER> to faciliate some VSCC ESCC work."
Answer: 41267.0

User story: "Because every consensus type (Kafka, SBFT, Solo) will need to handle chain creation and management, it makes sense to write this as a layer outside of the actual consensus implementation.    This should include intercepting chain creation requests and routing them to the ordering system channel, and invoking the constructors for the backing resources once the request has been ordered."
Answer: 41320.0

User story: "For the impending chain creation work, a second type of transaction will need to be 'executed' beyond a configuration transaction. This store is to generalizes the old configuration specific code paths into a re-usable path.    In particular, the broadcast filters must be generalized to be a more generic filtering mechanism.  Instead of replying with the matched rule type, and then having the invoker make decisions based on the match, the filters should return a Committer which can perform those actions with no specific knowledge from the caller."
Answer: 41332.0

User story: "Placeholder user story until [~adc] comes back with the JIRA issue he's using for MSP/orderer work.    This involves:  # passing configuration to MSP component  # using MSP to authenticate peers and verifying blocks on Broadcast() and Deliver() calls  # handling responses when authentication/authorization fails"
Answer: 90948.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: "At new chain setup time, a peer is requested to parse a JoinChannel request that contains a chain genesis block. The peer then needs to process this genesis block, and use configuration items listed within it to setup the security context of that chain:    - the MSPManager of the chain consisting of the VerifierMSPs of all the organizations of the chain   - the chain readers/writers and admins of the chain to enforce chain access control"
Answer: 50594.0

User story: "This is associated to the peer-setup phase, where all components of the peers are initialized. Peers take as input during their setup local config data, that requires the parsing and setup of SignerMSP info (including orderer's signing identity).     This is to consume config files defined within FAB-1063.  More info to follow here.    "
Answer: 115729.0

User story: "This is associated to the orderer-setup phase, where all components of the orderers are initialized. Orderers take as input during their setup, local config data, and the orderer channel bootstrap information.     Security setup of the orderer relates to the parsing and setup of SignerMSP info (including orderer's signing identity), as well as the parsing and setup of orderer channel VerifierMSPs / channel readers/writer/admin policies.     More info to follow here.    "
Answer: 157918.0

User story: "Remove Table API from Hyperleger Fabric in v1.  * The v0.5/v0.6 Pseedo-table API does not map well to current or next generation Fabric capabilities   * Project teams have been confused and frustrated with table API limitations    Encourage all new chaincode to use JSON-based data structures  * Additional query benefits when using CouchDB state database  * Provide JSON-based samples to help community update table-based chaincode  * Initial sample: https://github.com/<USER>table_to_json/blob/master/chaincode/table_to_json_chaincode.go    In the future Fabric may add support for relational state databases  * At that time it will make sense to introduce a ‘real’ table API without the limitations of the current pseudo-table API  "
Answer: 64369.0

User story: "Both the peer and the orderer shims leverage GRPC.  Given that we will need to do a number of things like handle root certificates which will be stored in per chain config, it makes sense to create a common server component similar to the client which already exists in the comm package"
Answer: 267699.0

User story: "Ledger has APIs for GetStateMultipleKeys() and SetStateMultipleKeys().  These APIs could be used by chaincode to more efficiently get or set multiple keys in one API call."
Answer: 1651798.0

User story: When a peer starts up it will come up without a chain or ledger. The "join" chain command to the peer will set up the chain (ie, ledger, MSP Manager, config block).    This story is about the initialization of the chaincode framework that follows the creation of the ledger for the chain.  
Answer: 97789.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: "Implement gossip protocol to transfer secret data value from a given key in the secret data store."
Answer: 187242.0

User story: "In v1.0, Admin service API can be used to accommodate more operational commands to pass and get back the operational statistics and configurations. "
Answer: 1399862.0

User story: "Resolve the secret data from the write set and store it in the secret data store."
Answer: 1654614.0

User story: "Policy to keep log or limited amount of time (day or couple of days) on the OS, and peers would have to communicate to each other to get the data (Kafka can prune or remove if older than x time). Work around is to configure Kafka to prune. "
Answer: 1654641.0

User story: "In order to provide better testability of gossip components there is a need to implement very basic mockup for communication layer which will not involve real gRPC communication. Gossip component which may require communication mock for example are: state transfer and leader election."
Answer: 10093.0

User story: "Similar to FAB-1065, the only difference is that it has to elect the leader per channel and not per org.    Implement peer leader election within a channel gossip group, such that, at any moment, we may call Peer.IsLeader(chainID) to learn whether the peer is the leader or not (true|false result). Consider cases such as leader dies, network partitions."
Answer: 1655689.0

User story: "I would like to be able to point to documentation notes/videos/etc that describes v1.0 architecture and behavior. Submit v1.0 (beta) documentation to gerrit readme, videos or other as needed."
Answer: 217095.0

User story: "As a hyperledger fabric project representative, I would like to explain and show with visual aids and scripts to collaborators and potential customers the present architecture and behavior of fabric v1.0 (as of the end of Nov, approx sprint 6)."
Answer: 20226.0

User story: "As a developer, I want to fix the other portions in the ledger code and ledger tests that still use old block structure. This did not get caught in https://gerrit.hyperledger.org/r/#/c/2581 because, the construction of transaction for tests was also being done with in ledger tests.    I also want to remove the explicit dependency of ledger unit test on msp security related stuff."
Answer: 206235.0

User story: "Everywhere on the NodeSDK source code, i see that GOLANG is hard coded for all requests.  Can you add the possibility to specify the language, then to use this for all request relative to this chaincode deployed ?"
Answer: 140486.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 V1 consensus network has the potential to become the bottleneck in V1 deployments, since by definition it must serialize transactions on a channel.  The "deliver" side of consensus is probably the most straightforward application in the entire V1 architecture: Binary blobs are simply pulled from ordered storage and then transmitted to multiple clients using token-based flow control.    Profiling the current Kafka orderer in deliver-only contexts shows almost nothing but serialization overhead, generically malloc()/memset()/memcpy(). Serialization and deserialization is pure overhead, adding no value to the data other than allowing it to be transmitted on the wire. For example the curent Kafka orderer stores blocks as the serialized form of the "Block" proto. To transmit a block:    1. The block is deserialized from Kafka storage (malloc()/memset()/memcpy())  2. Trivally converted to a DeliverResponse  3. Serialized again during gRPC transmission (malloc()/memset()/memcpy())  4. Copied yet again by the gRPC implementation in order to add a 5-byte header  to the serialized proto (malloc()/memset()/memcpy()).    The overhead of Steps 1 and 3 can be eliminated by storing and transmitting pre-serialized DeliverResponse objects. This is possible by modifying the DeliverResponse proto to implement a 3rd recursive type. This recursive type stores a pre-serialized DeliverResponse as a byte vector.    {code:java}  message DeliverResponse {      oneof Type {          common.Status Error = 1;          common.Block Block = 2;   bytes SerializedDeliverResponse = 3;      }  }  {code}    Servers can take advantage of this type by using a custom grpc.Codec for the DeliverResponse server. This Codec recognizes the recursive type and simply returns the pre-serialized response:    {code:java}  type Codec struct{}    func (Codec) Marshal(v interface{}) ([]byte, error) {   switch t := v.(type) {   case *DeliverResponse:    switch x := t.Type.(type) {    case *DeliverResponse_SerializedDeliverResponse:     return x.SerializedDeliverResponse, nil    default:     return proto.Marshal(v.(proto.Message))    }   default:    return proto.Marshal(v.(proto.Message))   }  }    func (Codec) Unmarshal(data []byte, v interface{}) error {   return proto.Unmarshal(data, v.(proto.Message))  }    func (Codec) String() string {   return "proto"  }  {code}    Now, deliver servers can transmit pre-serialized responses without the overhead of 1 and 3. _Note that absolutely no change to the client is required, and this behavior is completely optional on the server side as well_.    I have modfied the Kafka orderer to store serialized DeliverResponse objects (instead of Block objects), and to then transmit them directly with the custom Codec. The results of these experiments appear in the attached slide.    My argument is that we should go ahead and modify the DeliverResponse proto and add the custom codec in order to support the most efficient delivery services possible.      
Answer: 1665717.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: "create a fame work of creating orderor/peers/transactions etc for v1.0 "
Answer: 14307.0

User story: "Using the protobuf files for fabric, setup a Wireshark config such that Fabric traffic can be easily viewed and debugged in Wireshark."
Answer: 1386062.0

User story: "I have been doing some benchmarking of the Kafka orderer, and as part of this I did a rough parameter sweep to find the best number of transactions-per-block under various conditions. I was surprised to find that the best way to cut blocks is based on the size of the block (in bytes), not based on the number of transactions in the block. This result held in 2 different system configurations, with varying numbers of simultaneous clients and different blob sizes. The attachments show that the highest throughput for System 1 is always obtained with a block size around 400KB. For System 2, a block size of about 800KB is best. (Note - I did not go above 800KB for System 2 because the Kafka configuration has a limit of 1MB messages).    Based on these results I would suggest that all orderers implement a block-size target in addition to or in lieu of the current transactions-per-block target.  One nice thing about a size target vs. the current number-of-transactions target is that it allows a system administrator to tune throughput of an ordering service without having to run the actual blockchain application.    Note: This issue is related to https://jira.hyperledger.org/browse/FAB-904. Since the Kafka orderer _requires_ a block size limit, this limit should at least be documented as a way to optimize throughput as well."
Answer: 81668.0

User story: "Currently anti entropy is highly coupled together with gossip state transfer, to increase maintainability and testability of this unit the anti entropy need to be extracted into separate interface and structure."
Answer: 1666283.0

User story: "Gossip state transfer layer need to provide support for multi chain architecture."
Answer: 102191.0

User story: "Current gossip state transfer test is too brittle which cause many false positive failure on CI, hence need to be refactored and revisited."
Answer: 200560.0

User story: "Gossip layer should expose capability to indicate which of the organization nodes suppose to connect to the ordering service and use delivery protocol to pull out new blocks. In order to enable gossip to choose the peer which will maintain connection with consensus service and take care of its high availability new leader election layer should be implemented on top of current gossip infrastructure."
Answer: 93654.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 ability to have endorsements from peers that are not part of the target channel.    +*Rationale*+    * There may be a channel where there are a limited number of peers.  * There is a need to require more endorsements than there are reliably peers in the channel.  * There are other peers that may see the data, but should not store it.    +*Restrictions*+    * The writes are append only (no updates, and no deletes to existing data).  * If there is a version problem (2 transactions attempt to append the same key value) then it would fail at commit time.    +*Changes to the Client SDK*+    The client needs a way to request append-only endorsement for a channel that is different than the endorsement channel.    +*Changes to the Endorser+*    The endorser should be able to create a write set without having access to the target ledger.    +*Changes to the Committer*+    The committer should raise exception if an attempt to commit fails due to a duplicate key.  "
Answer: 270104.0

User story: "Define and implement a custom transaction type WORKFLOW. This includes a system chaincode WSCC to orchestrate transaction flow and event handling."
Answer: 1390240.0

User story: "A chaincode developer needs the ability to clean up old chaincode by delete or 'undeploy' so that unneeded or unwanted chaincode no longer is using up system resources"
Answer: 1670233.0

User story: "In the comm package, it exist a struct 'RemotePeer' which already take endpoint and PKIID properties. It match the input arguments in the Probe method and could be replaced."
Answer: 1483.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: creating a demo that coordinates the accomplished work in Sprint 5:  - use CouchDB for ledger and SDK keystore and enrollment storage  - mention that LevelDB now replaces RocksDB  - use Kafka orderer  - use COP server for acquiring ECerts  - sign proposals and transactions in node.js SDK with ECerts  - verify signatures in proposal responses in node.js SDK (run-at)  - use Java SDK to show end-to-end flow without sign or verify    *From Ledger perspective, here are the instructions to demonstrate CouchDB with Marbles chaincode:*  1) Start CouchDB in Vagrant by doing "couchdb start" from fabric directory.  This will also download the CouchDB docker the first time it is done.    2) Switch ledger to use CouchDB instead of LevelDB in /fabric/peer/core.yaml by setting "stateDatabase" to "CouchDB"    3) start orderer  ./orderer    4) start peer  CORE_PEER_COMMITTER_LEDGER_ORDERER=0.0.0.0:5151 CORE_LOGGING_LEVEL=DEBUG peer node start    5) Deploy chaincode  CORE_PEER_COMMITTER_LEDGER_ORDERER=0.0.0.0:5151 peer chaincode deploy -p https://github.com/<USER>marbles/chaincode -n marbles -c '{"Args":["init","1"]}'    6) Invoke chaincode to create marble owned by ‘tom’  CORE_LOGGING_LEVEL=debug CORE_PEER_COMMITTER_LEDGER_ORDERER=0.0.0.0:5151 peer chaincode invoke -n marbles -c '{"Args":["init_marble","marble1","blue","35","tom"]}'    7) Invoke chaincode to transfer marble to ‘jerry’  CORE_LOGGING_LEVEL=debug CORE_PEER_COMMITTER_LEDGER_ORDERER=0.0.0.0:5151 peer chaincode invoke -n marbles -c '{"Args":["set_owner","marble1","jerry"]}'    8) See state variables (JSON documents) in CouchDB UI by going to http://localhost:5984/_utils  Databases --> system --> All Documents    9) Query data using a REST client, for example to query for all marbles owned by Jerry, perform this query:  POST http://127.0.0.1:5984/system/_find  Header: Content-Type:application/json  {"selector":{"docType":"Marble","owner":"jerry"}}
Answer: 14791.0

User story: I want to point a specific path on a tag in Github to deploy my chaincode.    Today I can only point to the root repository not a specific tag or branch    Please add this feature for :  - a tag : i.e a zip or .tar.gz file URL  - a branch : add a way to include "branch" parameter if a git pull is done from the repo 
Answer: 11598.0

User story: "This is in conjunction with design and fabric/chaincode development for v1; also with the Design team.      Need to describe at a high level the functional changes to the fabric - e.g. query is now encapsulated within the invoke function, how to bootstrap a peer, how to remove a peer, how to plug into an ordering service, how the event sender works in conjunction with SDK, what's the basic flow of a transaction, what's the structure of a proposal, how to customize endorsement policies, how to customize validation policies, etc..."
Answer: 882340.0

User story: "Port performance Node SDK from v0.6 to v1.0"
Answer: 75030.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: "done via - https://gerrit.hyperledger.org/r/#/c/6119/    Synchronized with 2321 and [~<USER> work .      With the new build based on docker, there is a simplification that can happen for fabric development - fabric/devenv.  This is correlated with the deprecation/de-emphasize approach being applied toward vagrant.      Only need basic support for git, make, docker and docker-compose.    Also need to articulate that this is optional.  Need to confirm - does an OSX env with homebrew satisfy the above requirements.      Must have gnu-tar for archiving purposes.      "
Answer: 138300.0

User story: "Will need a readme on GitHub that explains how to   - write chaincode  - connect to testnet lite  - use cert to connect (TBD: we may be able to automate this)    *Documentation:*  - There is a question of how much we can support with documentation in HF Docs  - we need to add at a minimum a way to get started with HF v1.0 december alpha  - We’ll want Jim to document the SDK updates. If need be put placeholders that can be added to. We’ll look to see what we can support with the Java SDK  - We won't be able to submit queries through REST API.  - We'll need to notify users of the REST compatibility and how it won't work with V1  - Need to hook up latest SDK to marbles for this demo and update documentation  - Have the leads on each squad start to document what the sprints are releasing at a high level/outline. Then Josh + Nick can smooth it out so humans can understand it.    *Before Dec 16, Gari will cut the code that will go into the Dec. 17th Birthday release. Most likely we'll cut it for the 15th, which is a Thursday (Gari likes Thursday releases).*    _Next steps:_ Develop a delivery schedule for the birthday extravanza, including a demo of the code working.  - *We'll shoot for Dec. 2nd for a demo of the testnet lite. This will also be a go/no go indicator.*"
Answer: 221588.0

User story: "Compose new story for the full flow of a v1 transaction.  proposal chaincode deployment.  LCCC, transaction proposal.  -> endorsement -> ESCC -> SDK -> orderer -> validation -> VSCC -> commitment -> BCP.      This is in conjunction with the new animation video being done by Design.  "
Answer: 135679.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 sbft implementation currently creates gaps in its raw ledger.  The system as a whole needs to handle this situation.  There are several options to achieve this:    # committer connects to all consensus peers.  Deliver() receives a "only report headers" option (probably needed anyways for FAB-1095), and the committer retrieves batches selectively from different atomic broadcast services so that the committer assembles one contiguous block chain.  # sbft orderers use their established grpc connections to actively fill gaps in their own raw ledger.  This implementation would live outside of sbft.  # committer gossip automatically propagates missing batches so that the atomic broadcast client can advance its window beyond the gap in the atomic broadcast server's raw ledger.  Does this only work probabilistically?  What happens if no atomic broadcast client is connected to those replicas that have a batch which can fill the gap of all connected atomic broadcast servers?
Answer: 1396700.0

User story: "For both crash fault tolerance and byzantine fault tolerance, a committer needs to connect to more than one single atomic broadcast server to ensure being up to date."
Answer: 33632.0

User story: "As an owner of a peer on the BC network, I need the ability to upgrade the peer if there is a change in the protocol without loss of data.     With lifecycle chaincode, I can upgrade the chaincode. I also have the ability to apply patches/fixes if it does not apply to the protocol change itself via the SCC. Eventually I will have to accommodate this sort of change, in case there is a security vulnerability or something else that requires a major alteration. "
Answer: 1402251.0

User story: "First major step (later can add config params and create tests):  Provide a demo to team for our functional test framework tool to be used for testing v1.0 hyperledger fabric code, specifically using simple configuration one endorser with default policy, one solo orderer, default policies, which reads in config parameters (can be default) and talks to fabric using go language and using gRPC calls."
Answer: 42032.0

User story: "  - create our own raw sdk layer in go using gRPC  - func calls direct to v1.0 fabric code in peer (endorsers/committers) and orderer (consenters)  - determine languages to use for config files, and format of config files "
Answer: 242154.0

User story: "Guide team in defining reqmts for new test framework for v1.0  - demo existing perf test framework - determine config parameters needed for testing - determine format of json or yml file, and create one for network config parms and a sedond for test config parms and teststeps (and share with team) - work with <USER>to construct the engine, which may simply build on what he is doing for FAB-1043 or FAB-1069 "
Answer: 17485.0