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: "A peer that is stopped and later restarted will come up as another org leader in a channel if the peer is unable to contact a bootstrap peer.    Expected Behavior: we expected the peer to persist the list of peers with which it had been gossiping, so it could contact them and rejoin them when it restarts.    Consider this scenario, with delays and invokes between each step. Assume all peers mentioned are in same org.  ```  1. create peer0 ; peer0 elects self as leader  2. create peer1 with CORE_PEER_GOSSIP_BOOTSTRAP=peer0 ; peer1 contacts peer0, and becomes a nonLeader  3. create peer2 with CORE_PEER_GOSSIP_BOOTSTRAP=peer0,peer1 ; peer2 contacts peer0, and becomes a nonLeader  4. stop peer0 ; assume peer1 is elected new leader, and peer2 is still nonLeader  5. stop peer1  6. start peer1 ; peer1 elects self as leader, since it is isolated because peer0 (BOOTSTRAP peer) is unavailable. It would be helpful if the peer had persisted a list of peers in its org/channel, so it could contact peer2 now (and become a nonLeader - which is more appropriate since its ledger is likely lagging peer2)  ```    Another option to consider might be to provide an API for the administrator to modify the peer's internal representation of the BOOTSTRAP env variable. I am not certain, but I think that could allow (in step 3) adding peer2 to the bootstrap list of peer1, and thus peer1 would find peer2 via bootstrap list when peer1 recovers in step 6. I believe that would require the peer to dynamically reread the BOOTSTRAP peer list - as well as USE the list after being restarted. Honestly I don't know if this design option could work, but it is just an idea that we brainstormed"
Answer: 473421.0

User story: In fabric-samples/balance-transfer/app/query.js, "queryChaincode" fails to select peer.  "queryChaincode" has “peer“ as an args to select a target peer to get ledger's data.  "queryChaincode" calls channel.queryByChaincode like the below. Target peer is not included in request object.    {code:java}  return channel.queryByChaincode(request, target);  {code}    channel.queryByChaincode accepts target peer as a var in request object. As a result, target peer designated like the above is ignored and transaction proposal is sent to default peers (i.e. peer1 & peer2).  Target peer should be put into request object.    In addition, "queryChaincode" doesn’t output responses from all peers in log message. It exits the loop processing after outputting the first response like the below.  We should print all responses from all peers. Also, we should return a response (e.g. the response_payloads[0]) after the loop.    {code:java}  for (let i = 0; i < response_payloads.length; i++) {                  logger.info(args[0]+' now has ' + response_payloads[i].toString('utf8') +                                  ' after the move');                  return args[0]+' now has ' + response_payloads[i].toString('utf8') +                                  ' after the move';  }  {code}  
Answer: 228847.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "It is desirable to have a single easy way to deploy a network. All external users and many internal users could benefit from cello, instead of maintaining their own startup scripts which require an ongoing cost to maintain as fabric evolves. Cello is recommended by fabric team as the supported way to spin up a network. If the Cello team incorporates fabric changes to certs, directories, setup sequences, etc, then many other teams would not have to duplicate their efforts. By incorporating cello within automated tests run daily, it will support cello team by proving in their work, and will enable other teams to focus on their application work. And it would be a huge benefit to external user community, who is currently struggling with setting up networks.    Set up a submodule for cello inside fabric-test repo.    Define default network configuraiton yaml file and provide Readme file explanation how to use it, including how to choose singlehost or multihost, and and how to set config variables defined in core.yaml and configtx.yaml etc.    And revise automated tests as needed to use this cello-initiated network for:   * e2e tests and other CI tests in daily test suite   * behave tests   * performance system tests   * other integration tests and peer tests from the v1.0 SVT which require a full network"
Answer: 1014240.0

User story: "Existing code is too long (over 100 lines).    Separate those check, validation related code into another func of preProcess().     "
Answer: 265304.0

User story: "When an MSP identity is validated, its validity can be cached until an event does require the MSP to be updated. Before that, if the a validation is requested again on the same identity, the result stored in the cache can be return directly.    The same reasoning can be applied to MSP identity deserialisation and to MSP principals.    [~<USER>,[~<USER>,[~<USER>,[~<USER>,[~<USER>, please have your say,"
Answer: 72988.0

User story: "Implement a collection store based on the interface defined by FAB-5868.  The collection store (formerly policy store) serves collection objects based on collection criteria."
Answer: 98020.0

User story: "Integrate collection configuration with chaincode instantiation   * Enhance chaincode deploy arguments to include collection configuration   * Update the lscc instantiate validation with custom validation (Modification of ValidateLSCCInvocation)"
Answer: 174822.0

User story: " Define collection configuration proto (passed at chaincode deploy time) to define:     - peers who should be allowed to access private data associated to the collection     - collection namespace within the chaincode     - mim numbers of peers that a transient DB update associated to the collection should be communicated to at endorsement time     "
Answer: 53187.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: "Implementation of base collection object, an object with the following features:   * Collection name is the same across all collection state updates   * Collection access policies and access are publicly visible and validatable"
Answer: 64614.0

User story: "We need to specify a collection interface    * (chaincode side, validator side)   * Should include initialisation function that takes as input potentially secretly distributed parameters   * Should be generic enough to cover any unlinkability property we want to add (e.g. unlinkability of a collection identifier and its members)"
Answer: 53232.0

User story: "How to conduct channel membership changes is a frequently asked question.    The tools are all there, and there is some fragmented documentation around this, but the best way to document is through example.    It should be relatively straghtforward to enhance one of the examples to define three application organizations instead of 2, then create a channel with two members, and add the third.    This is an exercise that I've gone though by hand and would be happy to walk the implementer through."
Answer: 125531.0

User story: "There're several misusages related to container/image concepts.    They are now mixed in the code with mistakes, like container/images, name/ids.    Need to fix to make the code more clear to follow."
Answer: 330452.0

User story: I did some test on changing the config file and found that no matter what value I assign to the 'Users.Count' setting, only one admin folder is found under 'users' folder of specified org.  And even more, I could remove this 'Users' key with impacting nothing.  {code:java}  # ---------------------------------------------------------------------------  # "Users"  # ---------------------------------------------------------------------------  #    Count: The number of user accounts _in addition_ to Admin  # ---------------------------------------------------------------------------  {code}    So what is this designed for?  
Answer: 9.0

User story: The charter reads: "A Contributor may become a Maintainer by a majority approval of the existing Maintainers." so the maintainers section should be aligned.
Answer: 1186.0

User story: "As a chaincode developer I want to be able to enable RYW during key retrieval optionally, so that I can access already updated keys during my transaction.         My suggestion would be to enable this via an extension of the API in the fashion of as `stub.GetTrxState(key string)`.    Having this feature would make chaincode development more appealing and explicitly enable access to data already written during the currently active transaction."
Answer: 1278726.0

User story: "Currently Fabric does not support Read-your-writes(RYW) semantics. Its was removed with change in ticket -FAB-1187-.    The MockStub has not been adapted to this behaviour. We repeatedly have encountered issues, where the tests behaved differently then the actual application."
Answer: 1278737.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 requires the following change ...    For both the enroll and reenroll request, allow the user optionally request that attributes be inserted into the ECert.  See the attr_reqs field in https://gerrit.hyperledger.org/r/#/c/12519/2/swagger/swagger-fabric-ca.json.  For each attribute requested, the "name" is required and "require" is optional.  
Answer: 1278941.0

User story: "The orderer currently simply logs messages like:  Error reading from stream: rpc error: code = canceled desc = conext canceled    It'd be beneficial to understand who is the client that is involved in these kinds of messages."
Answer: 7261.0

User story: "https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-August/001621.html"
Answer: 1280381.0

User story: "Currently the orderer does not seem to allow for changing the logging format.  This would be a highly appreciated feature."
Answer: 67450.0

User story: "In order to evaluate expiration of MSP Identity we need to introduce in MSP the concept of reference time and having the following two ingredients:  - A method to get the expiration reference time from an MSP identity  - A way to validate and MSP Identity with the respect to a reference time.    [~<USER>, [~<USER>, [~<USER>, please, add comments to better clarify the purpose of this item if you think it is needed. Thanks :)"
Answer: 1282408.0

User story: "If shim does not get automatically upgraded in 1.1 (see FAB-5676), then we will need to preserve the old 1.0 shim proto messages and create a duplicate set of proto messages for chaincode functions using private data."
Answer: 120052.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: "Gossip has an in-memory mapping from PKI-ID to peer identities.  This mapping is used to:  * Keep track of which identities are valid and which are not  * Locate the identity given a PKI-ID in order to perform verification on a message's signature, given only a PKI-ID of the message.    Since x509-based certificates (what is used currently in Fabric) - eventually expire, the procedure that the current code does to remove them once they expire is periodically (once in 24 hours) call *MessageCryptoService.Validate* on all identities.    This has the following shortcomings:   * Once per 24 hours makes it that signatures of peers that their certificates have expired can still be incorrectly validated for a maximal duration of... 24 hours.  * Validation of certificates involves with cryptography computations that are expensive, and since certificates expire only once every few months (or years) - it is almost always a redundant check.    Therefore what I want to do, is that the MessageCryptoService would have an additional method that would tell given a *PeerIdentity* - when (*time.Time*) it expires:  * A zero value would indicate it never expires  * A non zero value would indicate that it expires at a certain time.    Then, when gossip would create a new mapping between the PKI-ID and the identity - it would spawn a timer that would fire at *NotAfter + time.Millisecond \* c* for some small constant *c*, and then the mapping would be deleted.   * If the identity is deleted from memory before that time - the timer would be cancelled, to prevent stale timer contexts floating in the golang runtime.     [~<USER> [~adc] [~<USER> [~<USER>  "
Answer: 61684.0

User story: The goal is to make access control decisions in chaincode based on "client attributes".  I am using the term "client attributes" in its most general sense.  They could be arbitrary name/value pairs such as "admin=true" or "bank-account=1234", or predicates such as "I am over 21".  Sometimes these attributes need not be private.  For example, it may be fine for everyone to know that I have an identity with "admin=true".  In other cases such as the "bank-acount=1234" example, I may need to keep the attribute secret from everyone except the client, the fabic-ca-server, and the chaincode.  This story focuses on the last case in which I want to keep an attribute as private as possible.    
Answer: 1287663.0

User story: "The submodules will need to be updated to the latest commits. This should eventually be apart of CI integration."
Answer: 5805.0

User story: "The logs for policy evaluation can be quite unintuitive to the uninitiated.    This CR is to evaluate this logging and attempt to improve it to be less opaque."
Answer: 33194.0

User story: "See:    https://jira.hyperledger.org/browse/FAB-5504    [https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-August/001579.html]     "
Answer: 903028.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 items refers to access control enforcement mechanism during the dissemination of private data to peers.    Partitions are configured with access policies for that channel that peers would need to respect. This comes in conjunction also with some peer-related access control configuration initiated in FAB-3621."
Answer: 125289.0

User story: "When MSPPrincipal is set to represent an identity, the full identity is included in the description. However, this would result into large sizes of policies that include such principals.    We suggest the replacement of the content of the principal (MSPPrincipal.principal) with IdentityIdentifier structure including MPSid and the identifier of the identity in targed."
Answer: 1288129.0

User story: "Create docs for the Identity Mixer MSP implementation describing the contribution and providing the references"
Answer: 47949.0

User story: "Golang pointers are word size, and therefore read/write operations across go routines are guaranteed to be consistent (ie, the previous, or the current value will be returned, not some mixture of the two).    However, there is still a risk due to out of order execution when a writer go routine writes a set of pointers, and a reader go routine reads that set of pointers, the reader go routine may not get what would be considered a consistent view of the system.    Although there have been no bug reports surrounding this sort of error, it is largely theoretical at the moment, an audit for these sorts of errors should be conducted, any instances of this potential fixed."
Answer: 36620.0

User story: # Create a channel say, 'mychannel' using "Org1"   # Add a new admincert (admincertB) to the consortium on system channel for "Org1"   # Use the private key for adminCertB to instantiate chaincode on 'mychannel'    This fails because mychannel isn't aware pf adminCertB even thought I updated the MSP definition for Org1 in system channel.    My assumption was when I update the MSP definition on system channel, they get propagated to the channels that have the MSP and they are kept in sync.    (Workaround is to update ALL the channels using private key that was used in the original definition. But this is not practical since you might have a lot of channels and you also need to have the private key of the cert that was originally on the channel)
Answer: 1289065.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: Fabric at the moment have a deficit in samples for the financial industry. work is needed to study how Fabric may be used in financial markets for different types of assets and securities.    Some of the scenarios in consideration:   * Fixed income assets: Commercial paper   * Equity assets: private equity   * Derivatives: Interest Rate Swap    h1. Design Details  h2. Interest Rate Swap (IRS)    Company A and B sets up an IRS contract with the following terms:  {quote}(Source: [https://academlib.com/14298/economics/pricing_interest_rate_swap])   Party A and Party B agree to exchange an interest rate that varies from period to period, specifically 3-month LIBOR (hence, it's the “floating” rate), for a fixed rate of 3.40% on a quarterly basis for two years. Net settlement payments are in arrears, meaning 3-month LIBOR is determined at the beginning of the period and then a payment for the rate difference, times the _*notional principal*_, times the fraction of the year, is made at the end of the period. Importantly, there is no exchange of principal at initiation or at maturity. That's why the principal is merely “notional” – it's the scale factor for the transaction. In this case, the notional principle is set at $60 million.    !https://academlib.com/imag/econom/smith_bondm/image303.jpg!    *FIGURE* Two-Year, Quarterly Net Settlement, Interest Rate Swap 3.40% Fixed versus 3-Month LIBOR  {quote}  The entire lifecycle of the trade will be executed with the following transactions:   - the general terms of the IRS contracts are modeled by chaincode (written with Hyperledger Composer)   - admins of A and B each install the chaincode on their peers   - admins from either of A or B creates a channel dedicated to trading activities b/w the two parties, or selects one from an existing channel b/w A and B   - admins from either A or B submits a transaction to instantiate the chaincode, which gets endorsed by peers from both parties and recorded in the channel's ledger, during the instantiation, the following specific terms of the IRS trade are configured:   ** identity the payer of the fixed interest rate (Party A in the example above) and receiver (Party B)   ** fixed interest rate is set to 3.4%   ** notional principle amount is set to $60 million   ** payment intervals are set to 3 months   ** maturity is set to 2 years   - at this point the trade has been executed and the terms are in effect   - at each net settlement, which is the end of the month 3, 6, 9, 12, 15, 18, 21, 24, LIBOR rate is taken (from a standard oracle service, but in our case we'll simply call the LIBOR API and pass the historical timestamp for the rate). note that we don't use an oracle service because the LIBOR API is deterministic, the same rate already returned for the same historical timestamp   - once the settlement is performed at month 24, the chaincode is marked as "COMPLETED" and will not perform any further settlements
Answer: 1289119.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Add a clarification that additional channels can be configured by repeating the steps in the building your first network tutorial."
Answer: 323055.0

User story: "All event types (chaincode/txid etc) should be derived from the block event by unmarshalling the block contents and calling back interested registrants. Event consumer should support this model and the tests based on it should be changed to reflect the new model."
Answer: 1289359.0

User story: "Transaction retrieval based on some index or metadata. This might be useful for the organizations to retrieve their transaction history instead of going through the entire chain."
Answer: 1289537.0

User story: "This is one of the major concerns, since , to make the project customization according to the need of the user. For example, I am deploying Fabric-1.0 over K8s, but there are few things like IP-Addresses of all Pods are needed as environment variables for the chaincode container. I have to hardcode somethings which is not a preferable way . "
Answer: 1289765.0

User story: "The current event framework found in fabric/events registers clients for events at the peer level and not at the channel level. This means that a client receives all events from the peer (that they are interested in). Adding ACL checks to this framework in addition to being unwieldy would also create a processing overhead, as we'd have to cycle through every client for every event whether they are interested in the channel or not.  A better approach would be to have clients register on events on a channel basis. While this could be done by extending the event framework, adding a channel level context  with ACL support on the peer wide framework is clugy.    A new channel service could be implemented on the peer endpoint to prepare for future ACL on events. A client would register with a peer for events from a specific channel. ACL policies will then determine if the client should be given access to events (and which type of events)."
Answer: 172559.0

User story: "A new, SYSTEM_EXT execution environment will be defined, in addition to the existing DOCKER and SYSTEM.    To support the SYSTEM_EXT execution environment, we will add a new implementation of the VM interface, extcontroller (alongside the existing VM implementations).     "
Answer: 113704.0

User story: "We should avail ourselves of using Docker's support for multi-architectures in the registry. This would make the image tag names more manageable.     e.g. instead of:  ppc64le-1.0.0    88 MB     a month ago  x86_64-1.0.0     72 MB     a month ago  s390x-1.0.0       76 MB     a month ago  ppc64le-1.0.0-rc1     88  MB     2 months ago  x86_64-1.0.0-rc1      72 MB      2 months ago  s390x-1.0.0-rc1        76 MB      2 months ago     We could simply have:  1.0.0     88 MB     a month ago  1.0.1     88 MB     a week ago     and `docker pull` would pull down the correct architecture image   "
Answer: 496778.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: "Upon upgrade of peer, in order for shim in chaincode container to get the latest fixes and be compatible with peer, the chaincode docker image should get rebuilt based on upgraded shim code.  Otherwise you will be running an outdated shim against an upgraded peer.    - Would need to add Delete of container images. Note - could get ancestor of container to check version, and delete image accordingly.  - This would fix things if you don’t vendor shim in chaincode.  - If you vendor shim into chaicode, you have to upgrade chaincode regardless."
Answer: 1290911.0

User story: "This is one of the Identity Mixer contributions to the fabric for privacy-preserving transaction signing.    It consists of the Identity Mixer crypto package (in Go lang) that provides the following functionality:   * generating the issuer (CA) keys,   * issuing certificates in a form of Identity Mixer credentials,   * signing messages and selectively disclosing attributes from the certificates in a fully unlinkable manner, and   * verifying such signatures."
Answer: 7817.0

User story: "TBA"
Answer: 575504.0

User story: "This is the first task in the context of FAB-5664. To be able to tell apart clients from peers from orderers, we plan to leverage the organisational units of an MSP identity. Of course, each fabric network instance might have its own way to identify clients, peers and orderers therefore we plan to enhance the FabricMSPConfig adding a new structure called FabricNodeOUs. An instance of FabricNodeOUs allows to define the organisational unit names for clients, peers and orderers. An MSP identity will be considered valid only if it can be identified as a client, peer or orderer. FabricNodeOUs also allows to disable this check, if needed."
Answer: 104807.0

User story: "MSPPrincipal definition is enhanced to express system entity roles. "
Answer: 162392.0

User story: "Fabric does not utilize couchdb document replication or old document revisions. As such, the number of revisions that couchdb maintains should be reduced. This can be done with a combination of automatic compaction and reducing _revs_limit.    References:    [https://eclipsesource.com/blogs/2012/07/11/reducing-couchdb-disk-space-consumption/]    *[http://docs.couchdb.org/en/2.0.0/maintenance/compaction.html]*    [http://docs.couchdb.org/en/2.0.0/config/compaction.html|http://docs.couchdb.org/en/2.0.0/config/compaction.html*]     "
Answer: 64490.0

User story: "I am looking for adding new peers to existing examples like fabcar and first-network via fabric-ca. Is there a step by step document which can help me adding new peers and orgs. also, if i have to connect to two different machines/nodes where all i have make changes. It would be nice if there is document for the same."
Answer: 1292677.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 current configtx code was written under the assumption that it was managing a channel configuration.  Although there is some abstraction via the use of interfaces to make unit testing easier, it's not currently possible to use the configtx processing for something like the RSCC support.    This story is to remove the channel config specifics from the configtx package, and to factor the common components out of the channel config package into a common config package."
Answer: 20311.0

User story: "h2. Description    In order to improve abilities of unit testing, an implementation of [https://github.com/hyperledger/fabric/blob/release/core/chaincode/shim/mockstub.go#L281] is suggested.   Having possibility to indicate transaction creator, will permit to test functionality which depends on MSP ID.  h2. Implementation Details   # New *creator* field in MockStub   # New method *SetCreator*  {code:java}  SetCreator(si *msp.SerializedIdentity)  if (si == nil) => a default one will be generated.  {code}   # GetCreator will return *creator* field    h2. Deliverables   * Implement *SetCreator()*   * Implement *GetCreator()* ([github|https://github.com/hyperledger/fabric/blob/release/core/chaincode/shim/mockstub.go#L281])"
Answer: 759275.0

User story: "There are a number of things we can take advantage of in the latest release of Docker and Docker Compose:    1) Multi-stage builds in a single Dockerfile    2) Support for Docker Swarm    3) Support for Docker secrets (w/o being in swarm mode)"
Answer: 54852.0

User story: "Currently, the log level for the peer can be defined in core.yaml logging section with some additional fine grained log settings for some fixed loggers such as gossip, ledger, grpc, ... .    Those loggers are hardcoded in the peer node here:    https://github.com/hyperledger/fabric/blob/release/peer/node/start.go#L246         However, in case we want to enable debug logging for some system chaincode, e.g. vscc, currently one has to set the peer log level to debug. This results super verbose logging of the peer.     It should be possible to add any logger to the logging section of the core.yaml in order to override the peer logging settings.                "
Answer: 653890.0

User story: Add "int32 version" to SeekInfo, DeliverResponse, and ConfigEnvelope to handle compatibility.    See more detail in the story FAB-5556     
Answer: 46074.0

User story: "Rejection events were disabled in v0.6 due to the endorsement phase being a synchronous operation and the return value now determined the partial validity of the transaction. There is still potential to fail during ordering so a new tx invalid event should be created for that purpose."
Answer: 1043322.0

User story: "The sdk should now consume block events and generate the chaincode events that they carry  for the sdk clients. Using the block as the source of events should allow the relative time ordering of events to be determined and avoid a potential issue for clients."
Answer: 1297909.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 be able to tell the health of the orderer and everything it controls, including Kafka         We must have this for the update process."
Answer: 680261.0

User story: "Enable the ability to specify the filename of the block generated by the {{peer channel create}} command    Currently, there is no option to specify the location or name of the generated genesis block when running the  {{peer channel create}} command. Instead, the block is simply generated in the current working directory and named {{$CHANNEL_ID.block.}}.    It would be useful when writing scripts if the block output file name could be specified. For example, I might want it generated into a temporary directory."
Answer: 411905.0

User story: "It would be nice to have an example contract as chain code_example02 showcasing the new function getHistoryForKey() returning all the values over the time for a key.    These will give a more accurate vision of the functionality."
Answer: 505218.0

User story: "i want to add some properties of ca to generate pem,the config will show   {code:java}  PeerOrgs:    - Name: Org1      Domain: org1.example.com      CA:          Country: US          Province: California          Locality: San Francisco      #   OrganizationalUnit: Hyperledger Fabric      #   StreetAddress: address for org # default nil      #   PostalCode: postalCode for org # default nil  {code}    "
Answer: 460159.0

User story: Having an issue instantiating chaincode which vendors in go packages which include .h and .s files. Example:    [https://github.com/golang/crypto/tree/master/curve25519]         Install works fine, however when i instantiate I get the following:    {{2017-08-02 15:26:27.825 UTC [dockercontroller] deployImage -> ERRO 045 Error building images: Failed to generate platform-specific docker build: Error returned from build:}}  {{...}}  {{... testcc/vendor/golang.org/x/crypto/curve25519/mont25519_amd64.go:15: missing function body for "cswap"}}  {{...}}
Answer: 45950.0

User story: "An application written using typescript will greatly benefit from the type definitions/declarations of the fabric-client nodejs module.    Usage of typescript helps in arresting potential issues at compile time as well as enable various IDEs to provide intellisense.     The declarations will be added as per the instructions provided at https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html     "
Answer: 201583.0

User story: "Provide the byfn.sh script with a new flag, -f, to receive the name of the docker-compose file to use in the form *byfn.sh -m up -c channel -f docker-compose-couch.yaml*.    This way the testing of the different environments is easier and standardized using the same script."
Answer: 1449.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 many of the test files that are imported from the fabric repository in the hyperledger/fabric/test path, there are references to "github.com/hyperledger/fabric" but as we are using fabric as a submodule in the fabric-test repository, we need to update the test tools and scripts accordingly.     There are multiple README files in the different directories under this repo, but no overall README. 
Answer: 157483.0

User story: "We have entirely too many places where we have to change the version string in scripts and yaml files etc. These should be pulling from a single place we can update to progress a version."
Answer: 1303681.0

User story: "Orderers should be strictly enforced to boot with identical genesis file (with same hash), otherwise it would result in divergent blockchain.    Therefore, orderer should broadcast its genesis file hash when startup, and halts upon mismatch. However, we should allow at least one 'winner' in the network, so a newly joined orderer with different genesis hash won't bring down the whole network."
Answer: 1303689.0

User story: "Fix the occasional CI failures that are attributed to the orderer component.    See:    [https://jenkins.hyperledger.org/job/fabric-verify-x86_64/14573/console]    [https://jenkins.hyperledger.org/job/fabric-verify-z/10232/console]"
Answer: 7.0

User story: "Right now, the client can get the transaction info by invoking the qscc installed on peer. We think it is necessary to extend this function to chaincode side. Since currently chaincode only has access to worldstate, the transaction payload are both recorded in worldstate and blockchain in some cases, which causes redundancy. If the chaincode can extract the payload directly out of the blockchain, the data needed to be recorded to worldstate can be greatly reduced. Especially in the case of  providing tractability among transactions, with this function, the chaincode only needs to records the link of related transaction IDs and gets the payload from blockchain, instead of recording all the information. "
Answer: 194554.0

User story: "CouchDB 'views' can be used to calculate things like aggregates of on-chain data. Need the ability to create CouchDB views and query for simple on-chain analytics."
Answer: 1094758.0

User story: We keep getting questions from users who report problems without providing basic information on the environment in which they are experiencing these problems.    The documentation section on "Still have questions?" pointing people to different places where they can ask further questions ought to instruct them to provide that information.     
Answer: 44042.0

User story: "The configtx processing looks up policies by relative name, which triggers finding the right policy manager, then querying the relative name.  The problem with this however, is that the logs only show the relative name, which can make debugging challenging."
Answer: 266212.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 configtxgen code got slapped onto configtx and required some modifications within configtx.  This is really the wrong place for that work and it pollutes production path code, it should be removed."
Answer: 266378.0

User story: "Firstly, We yet to evaluate Hyperledger v1.0    Before that, in the v0.6, any version changes to the golang chain-code generates the new chain-code id and creates an another network ledger.    Due to that, our application querying on the ledger, couldn't find the references of the existing data in new ledger.    Don't know, how to handle these versioning of chain-code.    Is there any provision to append the older data to the new ledger/ to the underlying DB to query?         Thanks,    Mahendran.."
Answer: 1308145.0

User story: "It is currently not possible to create unit tests for chaincode functions calling GetHistoryForKey().     "
Answer: 1309098.0

User story: "Currently logic which implements {{Peers}} API of gossip implemented as following:    {code}  // GetPeers returns a mapping of endpoint --> []discovery.NetworkMember  func (g *gossipServiceImpl) Peers() []discovery.NetworkMember {   s := []discovery.NetworkMember{}   for _, member := range g.disc.GetMembership() {    s = append(s, member)   }   return s  }  {code}    While there is no real need to iterate and build new slice, since function could simply delegate call to the discovery instance namely to {{Getmembership}}, therefore function will become     {code}  // GetPeers returns a mapping of endpoint --> []discovery.NetworkMember  func (g *gossipServiceImpl) Peers() []discovery.NetworkMember {   return g.disc.GetMembership()  }  {code}"
Answer: 4218.0

User story: "Failing scenario:   * client calls SCC1 without channel   * SCC1 calls SCC2 without channel - this call fails    Currently when a client calls a SCC that invokes another SCC, the peer return the following error:    [chaincode] isValidTxSim -> ERRO 297 [3e126b84]No ledger context for INVOKE_CHAINCODE. Sending ERROR         But when the client calls a UCC that invokes a SCC, no error is thrown.              By digging for the root cause of the SCC to SCC invoke error, it was found that in the handler, the isValidTxSim function throws an error due to txsimulator = nil in the txContext. Obviously it is nil as SCC don't need a simulated transaction because of their nature of not writing info to the ledger.         the fix to all inter SCC invoking is to verify if ChainID is not being empty along with txsimulator != nil condition. Please comment if this fix is feasible or if it will impact current invoking."
Answer: 165458.0

User story: "Show how to use the concept of Organization Units wrt to configuring policy."
Answer: 1310629.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: "Block events deliver entire block with all the transactions and information in them. Currently only RW/sets are removed before sending out the block event. This proposal is to create another event type (FilteredBlockEvents ?) to contain only information such as    \{transactionID, chaincode event name}    as part of the minimal set. This allows clients to register and obtain the filtered information for the minimal set which they can use to do further queries to the fabric with.    Rough sketch of FilteredBlockEvent proto for protos/peer/events.proto  {code:java}  FilteredBlock     -> uint64 number     -> string channel_id     -> repeated FilteredTransaction filtered_transaction        -> string txid        -> TxValidationCode tx_validation_code        -> FilteredAction filtered_action            -> ChaincodeEvent ccevent               -> string txid               -> string ccid               -> string ccEventName               -> bytes payload - nilled out in this filtered transaction{code}  This can then be added to a SignedEvent (defined in protos/peer/events.proto) if user registers and wants signed events. We should also do the same for regular block events, which are currently sent unsigned.    ChaincodeEvent may be nil, hence the need for the txid field in the FilteredTransaction. ChaincodeEvent is reused to avoid inventing a new structure without the txid field.    "
Answer: 311758.0

User story: "clean up arch-deep-dive to include images from source rather than external links to personal URLs. "
Answer: 344488.0

User story: "Need to publish version-specific godoc content for each published version for fabric repos that employ golang and have public APIs.    godoc publishes the packages fine, but will only publish the latest released version. We need version-specific resources."
Answer: 1310951.0

User story: "http://godoc.org/github.com/hyperledger/fabric/core/chaincode/shim"
Answer: 1730.0

User story: "CouchDB usernames and passwords can be enabled by adding additional environment variables to docker compose files.    The environment variables are added without values.   This will create peer and couchdb containers without CouchDB passwords enabled.     Initializing the variables will create a CouchDB container with and admin username and password.  The peer will also be created with the CouchDB username in the ledger config."
Answer: 56431.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, the SDK needs to know beforehand the endpoints of the endorsers it uses in its chaincode invocation.    Additionally, it needs to know beforehand that the required chaincode has been installed on the peers.    On top of that, if the peers that the SDK interacts with fail or become unreachable - it cannot use Fabric at all.    The [following proposal|https://docs.google.com/document/d/1zP04PKay4FN0tKYjHUSanyfK9b94rtYvC9MDSKGeSSE/edit] describes a service discovery capability that if introduced to Hyperledger Fabric - would remove the above restrictions.    [~<USER> [~<USER> [~<USER>    [~<USER> - This item requires collaboration with the SDK."
Answer: 426331.0

User story: "Although it is explicitly not supported, starting two different orderer processes with two different genesis blocks (even if generated from the same {{configtx.yaml}} will result in a divergent blockchain at startup.    At a minimum, the orderer should log the hash of the genesis block at startup to make debugging this situation easier."
Answer: 22196.0

User story: "When combination of Endorsement, Validation, and Commit processing consistently surpasses a peer's ability to consume , peer memory consumption grows, potentially leading to an out of memory condition. How do we best preserve Peer, minimize pain to the client?         I've attached a spreadsheet showing the result of the run.  I've asked the team to confirm what happens when the peer consumes all available memory since if it keeps running that's not as big of a problem as falling over or getting OOM killed."
Answer: 1313121.0

User story: "The reconfiguration flow requires multiple signatures for most configuration updates.  However, the only way to sign those updates outside of the SDK today is the peer CLI.    The peer CLI needs to support this workflow in some manner.  The most direct is probably to simply sign but not submit, and instead write to the filesystem.  In this way, the peer CLI can be invoked multiple times with different crypto identities to form a collection of signatures over the configtx."
Answer: 9051.0

User story: "Creating this story to fix the minor issues I bump into when going through the documentation.    This will take me forever to finish, but that's OK."
Answer: 1704.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, when a message that contains a block is sent to a peer (or a peer requests a block) - we consult the [MessageCryptoService|https://github.com/hyperledger/fabric/blob/release/gossip/api/crypto.go#L28-L60] and ask it- is the given peer (that is considered to receive the block from us) among the [channel readers|https://github.com/hyperledger/fabric/blob/release/peer/gossip/mcs.go#L246].     The problem is that this operation involves verifying ECDSA signatures and it is in the critical path of the dissemination.  From tests I've run, we waste a couple of tens of milliseconds in small networks, and the computation is linear in the number of peers in the channel.    The peers that their certificate is checked, are taken from the [in-memory cache of the StateInfo messages|https://github.com/hyperledger/fabric/blob/release/gossip/gossip/channel/channel.go#L333-L344].     I propose we refactor this into the following flow that would offload the certificate verification to a step that is not in the critical path, and would also reduce the total number of certificate verifications to a minimum.    The proposed flow is the following:  * When a peer receives a StateInfo message and it is put into the channel module, the peer consults the MessageCryptoService whether the peer that signed the StateInfo message is among the channel readers.  ** If not - the message is discarded.  * The StateInfo message is put into the in-memory cache as usual  * When the peer receives a block is is requested to send a block - it just checks whether the peer has a StateInfo message in the in-memory cache. If it does - it means the peer is a channel reader and can be given the block.  * When a config update comes, the [ConfigureChannel|https://github.com/hyperledger/fabric/blob/release/gossip/gossip/channel/channel.go#L361-L381] is called as usual, but this time - the method does over all the StateInfo messages in the cache, and checks if the peer that signed a given StateInfo message is a channel reader.  ** If it is not - the message is deleted from the cache.     [~<USER>   [~<USER>   opinions?"
Answer: 29124.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're not at the point of enforcing SPDX everywhere so running "make" shouldn't fail just because of that.  {code:java}  $ make  ...  Checking committed files for SPDX-License-Identifier headers ...  The following files are missing SPDX-License-Identifier headers:  bccsp/aesopts.go  ...  test/tools/PTE/userInputs/samplecc-chan2-longrun-i.json  test/tools/PTE/userInputs/samplecc-chan2-longrun-i-TLS.json  Please replace the Apache license header comment text with:  SPDX-License-Identifier: Apache-2.0  Makefile:111: recipe for target 'license' failed  make: *** [license] Error 1  $ {code}   The simple fix is to allow the build to continue in case of such an error:  {code:java}  $ make  ...  Checking committed files for SPDX-License-Identifier headers ...  The following files are missing SPDX-License-Identifier headers:  bccsp/aesopts.go  ...  test/tools/PTE/userInputs/samplecc-chan2-longrun-i.json  test/tools/PTE/userInputs/samplecc-chan2-longrun-i-TLS.json  Please replace the Apache license header comment text with:  SPDX-License-Identifier: Apache-2.0  Makefile:111: recipe for target 'license' failed  make: [license] Error 1 (ignored)  Checking changed go files for spelling errors ...  ...  {code}        
Answer: 178101.0

User story: "see thread in RC starting here [https://chat.hyperledger.org/channel/fabric-pr-review?msg=Zx8zqvFtvn5GTyrSe]    [https://gerrit.hyperledger.org/r/#/c/11993/]     "
Answer: 23087.0

User story: "FSM was needed to serialize invokes in 0.5/0.6. In 1.0 invokes can be concurrent and the FSM can be removed entirely.    This will help  * simplify chaincode  * cleanup  * make it easier to implement other language  such as node based chaincode (see FAB-2331)  "
Answer: 337664.0

User story: we need to raise the prominence of the "Still Have Questions?" page and make clearer where people can and should go.
Answer: 3915.0

User story: "Currently, the local.ini is placed in the /etc/local.d directory.    This file should be in the /etc directory based on the documentation:    [http://docs.couchdb.org/en/2.0.0/config/intro.html]    Also, the couchdb username and password are currently placed in /etc/local.d/docker.ini.  When couchdb is started, the password is hashed and stored in the /etc/local.ini.   The password in the docker.ini is left in clear text.      Writing the username and password to the /etc/local.ini will prevent passwords being left in clear text.     "
Answer: 427874.0

User story: "This issue is created to upload a end to end application for Java SDK for Hyperledger Fabric 1.0 .. using maven JAVA SDK libraries.    The app directly uses SDK jar from maven repository."
Answer: 1317827.0

User story: "Because the fabcar sample npm install builds native modules to succeed on Window one needs to install all the required Visual C++ Build Tools.    This can easily be achieved with the command:    {{npm install --global windows-build-tools}}    But this should be added to the prerequisites.          "
Answer: 5559.0