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 chaincode stub interface has the following API to allow an Invoke to set an emitted event payload upon commit of the transaction.     // SetEvent saves the event to be sent when a transaction is made part of a block   SetEvent(name string, payload []byte) error    The problem with having only a setter is that this appears as a one time operation, which in fact it would be much more useful to build up data in the payload as time goes by. So, for example, our iot contract platform can emit three items today: success code, failure with error string, and alerts status is success.    But customers are asking for us to emit complete state so that there applications can operate on changes without requiring a fast polling solution. Slow polling as backup may be used, but responsiveness is valued.    Our contracts are complex enough that state changes are spread out, but funnelled through a common state writer at the last moment. This state writer would be able to add the state to the emitted event (if configured that way declaratively) by calling GetEvent, unmarshalling the JSON object, then marshalling and calling SetEvent again. This would be a magnificent mechanism for building up the event as a complex process proceeds.    The addition of GetEvent seems like it should be a trivial extension, yet its impact will be huge for our customers. Please consider its inclusion in v1."
Answer: 709806.0

User story: Add in fabric/core/scc/vscc/validator_onevalidsignature.go two following methods:  1) ValidateBlockByTxID  2) ValidateLast100Blocks  --  I have patch with this changes and I solve this task, can I make pull request?  --  Description.  1) ValidateBlockByTxID    Call: peer chaincode query -n 'vscc' -c '{\"Args\":[\"ValidateBlockByTxID\", \"$chainid\",\"$transactionId\"]}'    where $transactionId and $chainid custom argument    By function ValidateBlockByTxID we validate block and validate all transaction in the block and return information about transaction.    2) ValidateLast100Blocks    Call: peer chaincode query -n 'vscc' -c '{\"Args\":[\"ValidateLast100Blocks\", \"testchainid\"]}'    By function ValidateLast100Blocks we validate block and validate all transaction in the block and return information about blocks.    add proto file for results methods    message BlockInfo {      uint64 number = 1;      repeated Signature signatures = 2;      string previousHash = 3;      string dataHash = 4;      repeated string transactionIDs = 5;  }    message Signature {      string CommonName = 1;      bytes signature = 2;  }    message TransactionInfo {      string TxID = 1;      string ChainID = 2;      google.protobuf.Timestamp timestamp = 3;      string CreatorCertCommonName = 4;      repeated string EndorsementCertCommonNameList = 5;      repeated bytes ProposalHashList = 6;      string Data = 7;  }    message ValidateInfo {      BlockInfo BlockInfo = 1;      TransactionInfo TransactionInfo = 2;  }    message ValidateLedgerInfo {      repeated BlockInfo blockInfoList = 1;  }
Answer: 71435.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 `deliver_stdout` client is useful for debugging. This changeset allows us to seek to oldest, newest, or extract a single block."
Answer: 3363.0

User story: 1. Ledgers were maintained as directories inside a "blocks" directory. Semantically speaking, this doesn't quite make sense -- you'd expect to find blocks under a "blocks" directory.    2. The name of this directory should be an exported constant so that other packages can access it programmatically. The orderer package for instance, needs this info in order to construct the proper directories for its ledger.    This changeset addresses both of these issues.
Answer: 3479.0

User story: The purpose of this feature is to provide a greater degree of integration between fabric-ca and fabric.  In particular, it is meant to hide the structure of the MSP directory for those who are using the fabric-ca.    This is done by adding support for the "-m" option as follows to the enroll (and reenroll) commands:  {code}  fabric-ca-client enroll -u http://user:pass@host:7054 -M <msp-directory>  {code}    This command will store artifacts as follows:  1) the ecert key at <msp-directory>/keystore/<enrollment-ID>.pem  2) the ecert cert at <msp-directory>/signcerts/<enrollment-ID>.pem  3) the root cert at <msp-directory>/cacerts/<root-CA-name>.pem    #1 and #2 are already part of the enroll command.  For #3, the fabric-ca-server will support a new GET /info endpoint which returns server public info including the root CA name and root CA cert.   The GET /info call will not require an authorization header.   The root CA name is a unique name given to each root CA in a blockchain network.   The default root CA name is the domain name of the host where the root fabric-ca-server is started.    Also add support for another fabric-ca-client command as follows:  {code}  fabric-ca-client getcacert -u http://host:7054 -M <msp-directory>  {code}  This will do only #3 above.    As an example of the use of these commands, consider a blockchain network with 3 root fabric-ca-servers: fca1, fca2, and fca3.  In other words, there are 3 members in the network and they are all using fabric-ca.  In order to initialize the local MSP for peer1 that is associated with fca1, you may do as follows:  {code}  fabric-ca-client enroll -u http://peer1:peer1secret@fca1:7054 -M <mspdir>  fabric-ca-client getcacert -u http://fca2:7054 -M <mspdir>  fabric-ca-client getcacert -u http://fca3:7054 -M <mspdir>  {code}  The resulting MSP directory would contain 3 certs in cacerts (e.g. fca1.pem, fca2.pem, and fca3.pem), peer1's ecert at signcerts/peer1.pem and peer1's ecert key at keystore/peer1.pem.
Answer: 15718.0

User story: "This changeset allows the user to choose the file ledger, introduced in a previous changeset."
Answer: 6618.0

User story: "This changeset introduces a getLedgerDir function that returns the path of the ledger directory. It also places this and all the other utility functions of the main package into a separate file."
Answer: 2174.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: 1. Switch all panic calls to their logging-enabled equivalents.  2. For simplicity's sake all logger calls that take a format specifier but just print a single argument at the end of the string have been converted to their no-format equivalents. There is no reason to say `logger.Errorf("Failed to listen: %s", err)`. `logger.Error("Failed to listen:", err)` returns the _exact_ same output (including an automatically inserted space before the argument).  3. Remove unnecessary log-level setting call. If the call to `InitFromSpec` is fed with junk, it will default to the INFO level anyway.
Answer: 6349.0

User story: "Following the instructions for installation of chaincode onto peer leads to this cli command:    docker exec -it cli bash    And later to this cli command:    CORE_PEER_ADDRESS=peer0:7051 peer chaincode install -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -v v0    The problem I see is that /opt/gopath is mapped into the cli container, but as with vagrant it only maps the hyperledger project. I am always forced to add /local-dev to the vagrant environment so that I can build my own chaincode.    But with the cli container, local-dev is not mapped at all, and so this trick cannot even be attempted.    The philosophy of having all cli instruction based on chaincode that resides in the fabric project itself creates a barrier to entry for those of us building and deploying chaincode from other github projects. Each new feature seems to create the same roadblock.    It would be very useful to use a separate hyperledger project for samples to force developers to accommodate the most common development and production path. Even though there are other ways to perform these tasks, the loss of REST in v1 leaves only the CLI as a reasonably short path to testing chaincode without a significant barrier. "
Answer: 489978.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: "Ability to read a restricted subset of the local peer configuration from a user chaincode.    *+Motivation+*    In the context of the use case described by FAB-2440, the user CC processing the client request is invoked on the channel specified by the client. Typically, it's a channel that is shared among multiple Organizations - potential service providers. To determine whether or not it can fulfill the request, the user CC queries the Organization's local sub-ledger. As the chains must have unique names within a network, local sub-ledgers belonging to different Organizations must have different names. In order to perform a query on the Organization's local sub-ledger, a user CC needs to know the sub-ledger name. The local sub-ledger name could be stored in the local peer as a configuration parameter which name has been agreed upon among the Organizations (service providers) for that type of service. User CC is able to access the local peer's configuration parameters via the Peer Configuration Reader System Chaincode (PCRSCC).    *+Configuration Access Restrictions+*    PCRSCC must allow a deployer to limit user CC's access to the local peer's configuration to a specific subset of the peer's configuration parameters."
Answer: 1241765.0

User story: "A set of if blocks end with return statements in `deliver_test.go`, meaning there's no reason for a corresponding else block."
Answer: 6692.0

User story: "`NewTestChain` --an exported function-- would return `ramLedger`, an unexported type. This changeset fixes that by changing the function to its unexported equivalent."
Answer: 6693.0

User story: 1. Remove the stuttering that was prevalent in filenames and package names throughout the package.  2. Updates function definitions where appropriate  3. Makes the layout of "ram" and "json" implementation consistent with the "file" one by moving the relevant functions to `factory.go`  4. Switches all panic calls to their logger-equivalents. (We will be doing this for all packages inside `orderer`.)
Answer: 6695.0

User story: "`CreateNextBlock` and `GetBlock` are utility functions and as such, they belong to `util.go`."
Answer: 6697.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: "During retests after FAB-2259 was fixed, using Feb 27 conmit # 29d7fc035df697a68d271d628e693c556354486f, we encountered other errors.    Execute test ORD97. This includes a sequence of events while traffic is running:  docker stop kafka0 kafka1 kafka2 && sleep 20 && docker start kafka0 kafka1 kafka2    Problems observed:  1. Seven transactions are unaccounted for; they were acknowledged received by the orderer service, but never delivered in a batch  2. Although the orderer does not panic, the service never resumes as expected after KBs recover:    $ go test -run ORD97  ========== OTE testname=ORD-97 TX=50000 Channels=1 Orderers=3 ordererType=kafka kafka-brokers=3 oteSpy=OFF producersPerCh=1    Files are attached, but here are some of the key output and logs:    Total TX broadcasts Requested to Send     50000  Total TX broadcasts send success ACK      17397  Total TX broadcasts sendFailed - NACK     32603  Total Send-LOST TX (Not Ack or Nack))         0  Total Recv-LOST TX (Ack but not Recvd)        7  Total deliveries received TX on each ordrr     [  17390   17390   17390]  Total deliveries received Blocks on each ordrr [   1739    1739    1739]    2017-03-01 18:24:26.867 UTC [orderer/kafka] Send -> INFO 31744 Failed to send message to chain partition 74657374636861696e6964/0 on the Kafka cluster: kafka: client has run out of available brokers to talk to (Is your cluster reachable?)  2017-03-01 18:24:26.867 UTC [orderer/kafka] Enqueue -> ERRO 31745 Couldn't post to 74657374636861696e6964/0: kafka: client has run out of available brokers to talk to (Is your cluster reachable?)  "
Answer: 1503162.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: "Ability to send a chaincode event to client without committing a transaction.    +*Motivation*+    At the moment, the Fabric doesn't have a mechanism for delivery of an asynchronous event to a client in cases when the client doesn't know in advance which peer will deliver the event. For example, if the client requests a global query (FAB-1153, FAB-2440), it doesn't know which peer will perform the service. The result of the global query needs to be delivered somehow to the client. The solution proposed here uses the existing chaincode event mechanism in Fabric to achieve this.    Currently, to raise a chaincode event, one needs to commit a transaction to a ledger. Sometimes the overhead of the transaction commit is not desirable. This is especially true for queries, where there is no change to the system state. This solution doesn't require a transaction commit.    +*API*+    * A client uses Client SDK to register as a chaincode event listener with a peer or a set of peers on a channel dedicated to delivering such events. When registering, the client expresses its interest in an event name.  * User CC that wants to deliver an event to a client (that is unknown to it) calls the Light Chaincode Event System Chaincode (LCESCC) on a peer on the messaging channel (where the client is listening on) to create a new chaincode event and deliver it to the client. Passing the parameters required for the User CC to call the LCESCC, like the peers where the the client is listening on and the event name, is left to the application.    +*Security*+    Messages delivered by peers - service providers to clients requesting the service should be private between the service provider and the client. Some of the security measures that should be considered are:  * Prevent a client to register to listen to all chaincode events in the system. It should be possible to configure the peer to raise exception if a client attempts to register without expressing its interest in a non-empty event name.  * Data encryption at the application level.    +*Changes to the Client SDK*+    Client SDK has to allow the client to register as a listener to a named chaincode event. The Client SDK Specification currently doesn't regulate event handling. For example, Node.JS client SDK currently allows the client to listen only to block events.    +*Changes to Fabric Core*+    Implement a configuration option to prevent a client to register for listening of all chaincode events. When this new feature is turned on, a client would have to express interest in a non-empty event name.  "
Answer: 1522249.0

User story: To my knowledge, the behave tests still do not work in all circumstances and they are generally sensitive to the host environment's prerequisites.  Therefore, lets remove behave as an implicit target.  Note that the explicit targets e.g. "make behave" will continue to function, and we can always add it back to 'all' when it makes sense to do so.
Answer: 540679.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "There are a number of artifacts which are required in order to bootstrap a fabric network and be able to test features such as membership, channels, endorsement policies, etc.    Some of these artifacts can be generated by BDD, some from various CLIs and tools, but it's pretty hard to get things going.    This tool will attempt to bring together as many pieces as possible"
Answer: 64947.0

User story: "  {code}  Creating a channel    The tool can also output a channel creation tx by executing    configtxgen -profile <profile_name> -outputCreateChannelTx <output.txname>    This will output a marshaled Envelope message which may be sent to broadcast to create a channel.  {code}    For generating channel configuration transaction, must supply *-channelID <channelID-name>* flag as well, which would be used while creating the channel.    "
Answer: 79528.0

User story: We currently have a "one-size fits all" approach in the protocol schema for dealing with chaincode deployment and upgrade.  Part of this is a vestige from the time before upgrade, non-golang code, and the NVP/CLI architecture.    For example: "path" makes sense if you are an NVP from the old architecture and need to know where the find the source.  However, once the code is packaged, we are overloading "path" to mean "golang package".  And this doesn't make sense if you are deploying something != golang, such as CAR or JAVA.    Another thing that doesn't make sense is we include the Type of chaincode in every invoke.  This is only relevant when the chaincode is deployed/upgraded.    This became substantially worse with the advent of CR5555 and the new delineation between install() and instantiate().  We are still using a deployment-spec for instantiate/upgrade when they really should only be referring to an image that was installed by install().    There are numerous examples of this nature in the current schema that I won't outline right here.  However, the net effect of all this is that the overloading is very confusing to clients.  The result is that it's not very clear how to drive the API.  I see a combination of clients hammering fields that have no meaning because either they have to to work-around a bug, or they are unsure if its needed.  In other cases, bugs are cropping up because a field that should have not been relevant to complete the desired function still has validation checks that are enforcing its inclusion.    An overhaul of the chaincode.proto is desperately needed, and I would suggest it is important to get this part of the ABI right now rather than be stuck with it for v1.0 and beyond.
Answer: 1523760.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: "Code packages should be as lean as possible, containing only the go/c/h files necessary to compile the chaincode into a binary.  This includes the chaincode application any of its dependencies, direct or transitive.    Today, we basically copy the entire $GOPATH/src regardless of its relevance to the chaincode application.  For developers that work with go on multiple projects, this often may lead to many more dependencies being deployed than is strictly necessary.    We should be able to use the techniques outlined here:    https://dave.cheney.net/2014/09/14/go-list-your-swiss-army-knife    "
Answer: 1517256.0

User story: They layout of the `orderer` package doesn't quite make sense anymore. For instance, "kafka", "sbft", and "solo" should not be on the same level as "multichain" - they serve different purposes. There are also SBFT-related files on the top level dir that really need to go (network_test.go, sbft_test.go).    Packages and files need to be renamed and re-arranged, so as to be more expressive and convey the relationship between the modules.    We will use this issue to document how we want the new structure to look like. Once we have reached agreement on the new layout, I'll push the respective changeset.
Answer: 538543.0

User story: "We use the ### lines to signal that the maximum line width is 80 characters, but lines with more than 80 characters keep creeping in. This changeset fixes that, plus a bunch of inconsistencies of the copy-editing kind."
Answer: 1528.0

User story: "The gossip protos were moved under fabric/protos after the fabric/protos were restyled to conform to proto style guidelines.  The gossip protos need to be brought in line with this."
Answer: 61402.0

User story: "After an audit with Elli, it's been concluded that the ChannelHeader embedded in the configtx.proto Config and ConfigUpdate messages are unnecessary, that the only piece of information needed is the ChannelId.    By removing these, the messages will be simpler to construct and understand."
Answer: 20243.0

User story: "The chaincode name and channel name currently have a set of restricted characters that cannot be used. The chaincode version does not and should reject supplied chaincode versions that contain those characters. "
Answer: 58079.0

User story: "As a fabric application developer, I want the ability to deploy user chaincode in pre-built form so that each member organizations' peers do not need to build the UCC (nor need to have the source code on the peer).    Note: the controls on allowing organizations to examine the source code or build their own images is separate from the deployment issue. i.e., each channel and member organization can still make a decision on whether to deploy the UCC without requiring the source code to be built and available to the fabric peer itself.    Sufficient pre-built targets will need to be provided to handle the possible environments of a fabric network."
Answer: 239092.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 the ability where you can plug in system chaincode, this would provide the ability to add to system chaincode. This would provide another 3 types of chaincode:  1) user 2) system and 3) pluggable system"
Answer: 1293799.0

User story: "- Allow client to include transient data to TP Request.  - Signed portion of a transaction proposal created by the Client SDK should not include transient data.    "
Answer: 96595.0

User story: "Ability to customize the validation of client certificate based on deployment specific security requirements. The customized validation is a plugin (e.g., custom system chain code - FAB-2454).    Examples    * FAB-2441    +*Changes to Endorser*+    Enable using a custom logic to validate the client certificate.    +*Changes to Ordering Service*+    Enable using a custom logic to validate the client certificate.    +*Changes to Committer*+    Enable using a custom logic to validate the client certificate."
Answer: 594436.0

User story: "Docker provides the ability to label many or it resources, including images and containers. These labels can then be used as filters when managing your docker environment.    To begin with, we can add the following labels to chain code containers:  * org.hyperledger.fabric.chaincode.id.name  * org.hyperledger.fabric.chaincode.id.version  * org.hyperledger.fabric.chaincode.type  * org.hyperledger.fabric.version  * org.hyperledger.fabric.version.base    This would be helpful in a development environment to enable quickly identifying chain code containers and images."
Answer: 3589.0

User story: "In a multichannel Fabric setup, where members all have deployed the same chaincode but have sub-ledgers, the client sometimes doesn't know which subledger(s) will respond to its request (or more generally handle its message). In such cases, the client should have the ability to broadcast its request to multiple subledger(s) at once.     *+API+*    The client should be able to request delivery of a transaction proposal request to one or many channels. Once each peer receives the request, the invoked user CC will examine the request and execute (if its logic determines that responding is appropriate). Handling the results of this execution is out of scope of this ticket.    See also FAB-2585.  "
Answer: 1251890.0

User story: "# Introduce a bare-minimum genesis profile for Kafka  # Update the Kafka-related Docker environments under `bddtests"
Answer: 5592.0

User story: "Ability to create and synchronously execute a new Fabric transaction from user ChainCode.    *+API+*    A user CC should be able to initiate creation and execution, in a similar manner to transactions created by clients using the Fabric Client SDK. The creation, signing and execution of the transaction proposal is done by the local peer on the user CC's behalf.  "
Answer: 1531850.0

User story: "Network connection failures and CouchDB error 500 status code should be retried at least once before returning error to high level components."
Answer: 9575.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 relates to setting up the CRL such that    - all the security checks on the CRL signer is done    - a link between a CA with its CRL is created such that identity validation is faster"
Answer: 1532839.0

User story: "The hashing algorithm for the system used to be fixed at SHAKE256, this was changed to SHA2-256, but additionally an option for SHA3-256 was added.  Because the block hashing is hardcoded in so many places, we cannot actually support switching this hashing algorithm currently."
Answer: 1533837.0

User story: "This is the item involving extending our default MSP implementation to include an OU specificiation in its description, and subsequently deem as valid certificates that are signed by one of the listed root / intermediate CAs and their organizational unit equals the one in the MSP configuration.  This item consists of three sub-tasks:  A) Update of fabric MSP configuration as follows:     - Root CAs (*done*)     - Intermediate CAs (*done*)     - (a list of) a list of OU identifier (*almost done*: field is there but is not used)     - Admin (*done*)     - CRL (*done*)  This is reflected to extended FabricMSPConfig to include an additional field (*done*)    - repeated FabricOUIdentifier OUs   where FabricOUIdentifier is a an additionally defined message in common package defined as follows (*done*)    - byte[]/string certifiersIdentiifer // hash of certificate chain to the root    - string OrganizationalUnit // current organizational unit identifier  B) Update the fabric MSP setup, and ValidateIdentity, GetOrganizationalUnit function implementation as follows:    - Setup is to take as input the OUs and stored within the MSP (*todo*)    - ValidateIdentity would need to check if the OUs listed within the identity match the OUs of the MSP state (*todo*: perhaps by using the satisfiesMSPPrincipal function that is already implemented :))    - GetOrganizationalUnit function needs to be changed to return FabricOUIdentifiers (*done*)  C) Computation of the FabricOUIdentifier.certifiersIdentifier is to be computed as follows (*done*):      - Get certificate's certification chain to the top (created at validation time), let it be CertChain.      - Compute the hash (CertChain), say HCertChain     - Set FabricOUIdentifier.certifiersIdentifier to HCertChain   "
Answer: 88204.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: "Ultimate goal of two jira items FAB-2362 and FAB-3296 is to work towards the following :   - retrieve hashes used within the context of a chain (proposal, txid, binding, block) from chain genesis block (*almost done - rest for post v1*)   - [subtask of FAB-2362] retrieve hashes used within a signature from a (hardcoded) MSP property (FAB-3293)   - [subtask of FAB-3296] retrieve chain-less operation hashes from local configuration of peers/orderers (FAB-3294) - post v1   - [subtask of FAB-3296] enable MSP crypto configuration be retrieved at peer setup time or channel genesis (FAB-3295) - post v1    Side change-sets needed are:   - Remove the usage of BCCSP default opts"
Answer: 558806.0

User story: This is for fixing this TODO inside /fabric/protos/msp/msp_principal.proto:    // TODO: Bring msp.SerializedIdentity from fabric/msp/identities.proto here. Reason below.  // SerializedIdentity represents an serialized version of an identity;  // this consists of an MSP-identifier this identity would correspond to  // and the bytes of the actual identity. A serialized form of  // SerializedIdentity would govern "Principal" field of a PolicyPrincipal  // of classification "ByIdentity".
Answer: 68356.0

User story: "golang 1.8 comes out, with better compiling performance.    https://blog.golang.org/go1.8    May take golang 1.8 as the default compiler."
Answer: 319576.0

User story: "Logging control - minimize and filter network logs.  Devops folks have made considerable headway on this ...."
Answer: 174649.0

User story: "Steps and tips to debug networking issues "
Answer: 1540673.0

User story: "Steps that must be completed to start a network"
Answer: 174651.0

User story: "Documentation to discuss specific sections in a planning guide, there will be many pieces. This particular story will start with :         Overview    Governance    Hosting location    Ledger"
Answer: 746952.0

User story: "sys admin info for generating and uploading certs, determining and defining policies "
Answer: 746954.0

User story: "Links to Hyperledger Fabric youtube channel "
Answer: 97677.0

User story: "various docker-compose scenarios showing different network configs  and manipulation of environment variables "
Answer: 1286355.0

User story: "end to end example of go code showing a wide array of the available apis, methods and functions     Barath to work on this "
Answer: 1287795.0

User story: "convert CP code and document instructions to function against v1 network and new code base"
Answer: 174704.0

User story: "convert marbles and document instructions to function against v1 network and new code base"
Answer: 97734.0

User story: "convert art auction code and document instructions to function against v1 network and new code base"
Answer: 747001.0

User story: "1. Remove confusing comment on `NewChainCreationTemplate`.  2. Add comments to exported variables.  3. Extend test so that it checks policy name."
Answer: 1377.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: "convert marbles code and document instructions to function against v1 network and new code base"
Answer: 247515.0

User story: "As a developer, I need a Python SDK, so I develop application with NodeJS to interact with blockchain. "
Answer: 1734767.0

User story: "As a developer, I need a Java SDK, so I develop application with NodeJS to interact with blockchain. "
Answer: 344107.0

User story: "As a developer, I need a Node SDK, so I develop application with NodeJS to interact with blockchain. "
Answer: 195406.0

User story: "Currently chaincode handler will return 100 items to the chaincode container, even if the chaincode ends up not exhausting the list.  All 100 items will go into the RWSet phantom check results though, even though the chaincode client didnt read them.  This should be improved such that only the items that are actually read go on the RWSet phantom check results.    This can be deferred from v1."
Answer: 1541067.0

User story: Steps to improve the flow of information (not just a docs issue):     Fabric launch site - EVERYONE STARTS HERE:        Create site / splash page - Fab-2115[https://jira.hyperledger.org/browse/FAB-2115] - DONE      Link directly off HL.org - DONE      Less words, more graphics - DONE          Use icon linking - BM tile 'esk -> direct feedback from community          "If I see more than a paragraph, 2 at most, I'm just going to start clicking around"      Create some more higher level videos       Create some more technical and intermediate videos and demos      Need more sample apps & how-to on sample app creation    Current readme docs improvements:        More graphically pleasing nature          Investigate sphynx or other use of basic capabilities like hover, etc - DONE      Improve TOC flow -> DONE          Proposal put forward to community and being worked          Mark will open a thread to the community to press for other suggestions / improvements -DONE          Mark will reach out to community, starting a email thread for suggestions on improvements / gap identification. Have had good feedback, creating more discussion in #fabric-documentation channel - DONE          Use above email to also point to new #fabric-documentation channel, as well as opening Jira items for new requirements/suggestions, and issues with current doc - DONE    Updates to the HL.org site:        Feedback from community at Hackathon is hard to find proper links directly off HL.org          Can't get directly to the wiki pages          Hard to navigate      Define what is used for which purpose Wiki, email, rocketchat, etc (community issue)
Answer: 58992.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 add queries to system chaincode to:  1. list the installed chaincodes on a peer (LCCC)  2. list the instantiated chaincodes on a channel (LCCC)  3. list all the channels for a given peer (CSCC)"
Answer: 28825.0

User story: "TODO list (time-permitting for v1):   - Have OUs be represented by an enhanced data structure including OU name and the PKs that appear in the certificate's path to the root CA   - Have OUs be included as (optional) part of default MSP configuration; in which case we can define an MSP to the level of OU   - Enhance policy language to accommodate OU-based policies   - IdentityChannel   - Have options in the SatisfiesPrincipal to pass in the signer, signature, and message.   - Include in genesis the type of hash used for txid and bindings.   - Add OIDs to bccsp generated signatures   - separate clients from peers and orderers using identity roles"
Answer: 607570.0

User story: "Currently, version in stored in header for JSON data and encoded into the attachment (first few bytes) for binary data. With Data Wrapper approach, the header is distinct from JSON data or attachments and can be used to store version"
Answer: 1544353.0

User story: "Add features to the OTE, in fabric/bddtests/regression/go/ote/, for additional testing capabilities. Some ideas are:  # Verify the contents of last block that is received by the consumers on each channel  # Allow test code to select which orderer to spy on  # Allow option to defer creating and attaching masterSpy until later in the test, and a function to trigger it  # Options for changing the size of the broadcast timestamp payload, fixed or dynamic  # Add function for creating multiple producers per chnl per orderer  # Capability to run traffic for a duration, instead of specifying number of TXs to complete  # Authentication of certs of Producer TXs and Consumers invoking deliver()  # Use different chaincodes to send transactions to orderer from producer (api) - this would be a big change  # change Panics to return failure values, so CI can complete all go tests"
Answer: 735999.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 gossip, every message sent is a GossipMessage.  The gossipMessage contains an inner message and a signature:  {code}  message GossipMessage {  bytes signature = ....  oneof content {            AliveMessage aliveMsg = ...;          MembershipRequest memReq = ...          MembershipResponse memRes = ...  ....  }  {code}    The signing and verification is done in the following way:  Signing:  # Signature is nullified  # proto.Marshall is called  # the output bytes are hashed  # the hash is signed by the peer  # the signature is put into the signature field  # the message is sent    Verification:  # The signature is saved aside  # the signature field is nullified  # proto.Marshall is called on the message  # the bytes are hashed  # the signature is verified    This is a problem because protobuf's proto.Marshall doesn't guarantee equal output between different invocations on different hosts.    So the message that is sent over the wire needs to be an envelope message  that will contain the bytes of the actual message, and the signature on the message.    "
Answer: 23340.0

User story: "Feedback from solutions:    Provide basic information about deployed chain code on the chain, such as chain code ID, its deployed time, etc；For each chain code, with proper permission, provide invoke/query metrics data such as TPS, consensus latency(average, 50%, 85%), broken down into different chain code API (function)；Provide storage usage information on peer node. (@huangssh, Nov 16, 2016)"
Answer: 567492.0

User story: "GetStateMultipleKeys currently loops through GetState for each of the keys. For CouchDB this translates to individual HTTP queries. Instead we should use a $in operator and a rich JSON query"
Answer: 1551045.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "There are two aspects to the security of the new deployment model (https://jira.hyperledger.org/browse/FAB-1783)  * securing the package  * securing the instantiation of the package  * linking the secured package with the instantiation    +Securing the package+  The structure of the package would be   * Envelope  ** serialized deploymentSpec  ** creator bytes  ** policy for chaincode instantiation  ** hash of the above  ** signature over the above    +Securing the instantiation of the package+  Instantiation is a Proposal to LCCC (life cycle system chaincode) that will go through the usual Peer validation checks.   * who is the creator of the proposal ? Local MSP Admin   * who can access this chaincode ? Invoke and instantiate ?    On successful validation, an entry will be created in the LCCC on the channel's ledger  * name of the cc  * version of the cc  * hash from the package    * signature from the package    +Linking the secured package with the instantiation+  The static links between the LCCC entry (described above) and contents of the package provide means to cross check and verify the chaincode.    The LCCC entry will be checked against the chaincode every time the chaincode is launched  * on instantiation  * on bring up the chaincode for an invoke if not already running"
Answer: 1298298.0

User story: "In order to build a UI to administer the orderer we need the following APIs... ideally Node SDK, gRPC would be a good start    Add Root Cert for an Org (Config on the Membership channel?)  Get channel policy   List participants  Create Channel  List channels  Get (Genesis) Block on Channel  Submit Config transaction (add member to channel)  Submit Config transaction (update policy on channel)"
Answer: 132276.0

User story: "It would be nice to have a GUI installation of a peer node where you can graphically go through all the required steps to installing a peer on a machine and connecting to an ordering service. "
Answer: 1552477.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "There are three stories linked to this epic and associated with the items above.  1.  Creating an effective splash page.   If you go into: https://www.corda.net/.   They have some really great high level information that is easy to follow.    - this is critical as it outlines all the writing that needs done.  https://jira.hyperledger.org/browse/FAB-2115    2. Develop the technology to display the information.  I can see for the Documentation tab they dive into Sphinx.  The pages are built with Sphinx using a theme provided by Read The Doc (RTD). Our CI environment already uses RTD but not Sphinx.  Ramesh is working converting our RTD to Sphinx.  There is actually a conversion he is experimenting with for the doc formats.    The general look and feel of the main page (www.corda.net) -- it would be great to get input from some of the UX experts on what the options are to enhance the experience.  https://jira.hyperledger.org/browse/FAB-2111    3.   Writing the content.  Once everyone agrees on item 1.  Now assignments can be assigned.  Some the documents should have a writer and a technical contact that work jointly.   https://jira.hyperledger.org/browse/FAB-2116  "
Answer: 93338.0

User story: "The documentation is being over-hauled and the mkdoc.yml, which pretty much represents the build file for readthedocs has been reordered.  Things have been added, and others removed.  We need to make sure all the documentation in this file are complete by the end of the month.  "
Answer: 93017.0

User story: "Create a splash page for the documentation that provides an introduction to the fabric and guides users to our public social media sites and repos."
Answer: 70043.0

User story: "add architecture overview and deep dive. Refactor the index.md to be more oriented to users."
Answer: 1.0

User story: "Build documentation for every commit and ensure the build is successful and render the documentation properly.     Existing documentation build process works only after the patch is merged. This approach is leading to broken links, and hiding missing page configurations.    Proposed plan is to build documentation for every patch set and make sure build is successful.    "
Answer: 481897.0

User story: "In CC to CC case we need to ensure that the invoker has read-access to the callee's chain."
Answer: 106465.0

User story: "reorganize the left hand margin TOC in RTD docs to be a bit more oriented to end users coming to the platform."
Answer: 70426.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: "Assumptions we need to document:    1) Certificate expiration.   Here we decided to go for real-time being used to assess whether a certain certficate is valid or not.   The assumption is that the certificates are renewed way before they expire, e.g., a month before such that the clock skew of the committing peers will not be affected by this.  This item is here to ensure that this assumption is properly stated into the MSP document.    2) MSP Identifier.   Here we need to assume that the MSPidentifier is set upon agreement among the application participants. In the future orderers are to enforce this, via the identity channel but currently we assume that the admins of the chain have properly investigated the MSPs they allow to appear in the chain including a correctness check on the mapping between MSP identifiers and configuration. It may as well be that the MSPIdentifier is taken after an MSP's administrator.    3) Distinction between clients and peers.  This is deemed not to be critical for now but we should add to the MSP document best-practices when distinction between the two is necessary.    "
Answer: 122280.0

User story: "As per today's discussion with [~<USER>, [~<USER>, [~<USER>:    Ultimately, this issue aims at the implementation of a channel-basis access control check upon an event registration request.  Currently event infrastructure does not support per-chain requests. Therefore we can identify the following steps towards enforcing access control at event registration.    1. Treat the event registration as a chain-free request, and request that the creator of an event registration request is a member of the same organisation as the peer the request is submitted to. Limitations: (i) requires an one-to-one mapping between MSPs and organisations (also considered by current gossip protocols), (ii) cannot accommodate cases of applications that do not own their own peer.     2. Ensure that the creator of the event registration request is allowed to read all the channels the peer (the request is submitted to ) has joined. This assumes a static channel configuration and the check is needed to be repeated each time the peer joins a new channel.     3. Ensure that the creator of the event registration request is allowed to read all the channels the peer (the request is submitted to) has joined. This assumes a dynamic channel configuration, and the check needs to be repeated each time a new (valid) config block is received.     4. The creator registers on events on a per-channel basis, and read policies of the intended channel are checked. This check needs to be repeated each time that channel's is reconfigured. "
Answer: 102911.0

User story: "Peers upon receiving a proposal need to ensure that the creator of the proposal is within the channel.Writers set.    In the specific case of an lccc proposal, the peer needs to check that the creator complies with the lccc policy (chaincode creation policy).    "
Answer: 21029.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 we want to enhance the orderers with logic of checking a chain creation specific policy upon a chain creation request."
Answer: 22143.0

User story: "This work-item includes the authentication of channel-scoped messages received by the orderers against that channel's readers and writers. In particular orderers should check  - whether the message creator if broadcast, was submitted by an entity satisfying channel.writers policy  - whether the message creator if deliver, was submitted by an entity satisfying channel.readers policy  "
Answer: 22149.0

User story: "We need a way to implement access control for the lifecycle system chaincode.     We anticipate this to be split into four different sub-tasks (assuming success on sub-task 1):   1. determine if we can add a lifecycle policy to the configuration block to handle access control   2. implement the lifecycle policy and add it to the configuration block  3. figure out how to use the MSP API to validate the transaction based on the policy and identity of the caller  4. use the MSP API within the endorser system chaincode"
Answer: 94134.0

User story: "The current configuration structure is a flat list, which causes some problems, especially when attempting to differentiate between the roles of ordering organizations and peer organizations.  A hierarchical model is slightly more complex from a data structure perspective, but is more natural and expressive.    This work should be careful to ensure that the older model can be supported in the degenerate case."
Answer: 25966.0

User story: This is a proposal on how to enhance peer API to support updates to local MSP without requiring the peer to (re-)boot.    In the future this API can be extended to configure other aspects of a peer's operation.    We aim to fully support this capability via extending CSCC with an "updateMSP" function, in three stages:   # At the first stage we assume that the peer's admin is able to create in the peer's filesystem a folder to include the new msp configuration; subsequently the peer's admin would only need to request the peer to reload its local msp from this folder (FAB-6254)   # At a second stage, the peer's admin would pass to the peer the entire new msp configuration and ask from the peer to load msp updates from the request's arguments (FAB-7249)   # Adjust the way gossip advertises the gossip identifier of the peer (PKI-ID) in a way that can be renewed when the signing identity of the peer is renewed (as part of its local MSP update). This FAB design is still in progress.    In both cases, the peer would need to update its .yaml file with the updated msp information.          
Answer: 1556383.0