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 documentation is in really bad shape. Some of it is not consistent with the code, or completely outdated, and much is just plain missing.    The table of contents is impossible to navigate and there is actually much more in the source tree that is not reflected in the TOC and therefore doesn't exist.    I've said previously that we need a less complicated TOC that can fit in a single view. Not some tome that people need to scroll through.    Look at other examples of open source (not product) documentation. Docker is a good example: https://docs.docker.com/    The TOC expands, but here's the gist:  Get Docker  Get Started  User Guide  Admin Guide  Troubleshooting  Manage a swarm  Secure Engine  Extend Engine    Docker isn't alone. This is how most are organized. I checked hadoop, cloud foundry, openstack, kubernetes, they are all roughly organized like this, and this is what I had previously been recommending.    As someone coming to the documentation page, I want to easily find where I need/want to dig in. First, I need to get X. Then, I probably want to get started. Of course, if I am an operations guy, I might want to skip right to the admin/operations guide. Or, if I am a developer, I can dive right into the user guide or a tutorial. My point is that we need to make it THAT simple for people to find what they want.    Now, I do think that we need something that tells people what Fabric is and what its capabilities are.    So, I recommend the following outline:    Introduction to Fabric  - Features  - Use cases  - Glossary  - Architecture  Get Fabric  - v1.0 (coming soon)  - v1.0-alpha  - v0.6 (deprecated) (link to v0.6 docs)  Get Started  - Deploy your first peer cluster  - Sample apps  User Guide  - Tutorial  - CLI  - Node SDK  - Java SDK  - Developing Chaincode  -- Golang  -- Java  Operations Guide  - Setting up a network  - Manage a peer cluster  - Manage a Kafka orderer  - Managing peers with CouchDB  - Managing fabric-ca  -- with ldap  -- with an alternate provider  -- cluster operations with haproxy  Troubleshooting  Fabric Developer Guide  - Setup development environment  - Building Fabric components  - Contributing  - Maintainers    Again, only the top level are exposed unless the user toggles a top level to expose the next level.  "
Answer: 507005.0

User story: "The current interface stub.GetCreator returns the serialized identity, which is not useful for chaincode wanting to access the internal representation of identity. For example, if the MSP is configured with x.509, then the chaincode would need access to the x.509 certificate. "
Answer: 1462915.0

User story: "Rename {{org.hyperledger.java}} package to {{org.hyperledger.fabric.shim}}."
Answer: 8970.0

User story: "Allow user to specify the name of the orgs rather than just the number of orgs.  This is for peer orgs and orderer orgs."
Answer: 11591.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: "Assume we use kubernetes or swarm to manage blockchain networks in production. We deploy all peers, orderers, ca using containers/pods, kafka, couchdb as well. After initial deployment, it is better to have a mechanism to detect and recovery failed components.    For fabric e2e example, we have two peer orgs and each org has two peers(one anchor). In normal we will have four containers/pods running. However unfortunate one peer(not anchor) failed, but the container which include it is still running. In this case, only through kubernetes we can not found this problem ASAP so that we can not automatic recover. But I think gossip should get that fail info and update the membership for other peers.     Now that I think if we can expose some APIs to let external side know the membership update. For this case, if i can get the infomation, i can find out actually one container need restart or remove and add a new one.    [~<USER>suggest may add some methods in SCC can help  [~<USER>suggest we can expose API to request an anchor peer to return the peers that it gossips with within its org  [~<USER>said it need carefully consider security and privacy    Hope we could discuss here and make sure if it can be implemented and how can do it    "
Answer: 670122.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: "h3. Go:  {code}  type Chaincode interface {   // Init is called during Deploy transaction after the container has been   // established, allowing the chaincode to initialize its internal data   Init(stub ChaincodeStubInterface) pb.Response   // Invoke is called for every Invoke transactions. The chaincode may change   // its state variables   Invoke(stub ChaincodeStubInterface) pb.Response  }  {code}  h3. Java:  {code}  /**   * Defines methods that all chaincodes must implement.   */  public interface Chaincode {      /**       * Called during an instantiate transaction after the container       * has been established, allowing the chaincode to initialize       * its internal data.       */      public Response init(ChaincodeStub stub);      /**       * Called for every Invoke transaction. The chaincode may change        * its state variables.       */      public Response invoke(ChaincodeStub stub);  }  {code}"
Answer: 10686.0

User story: "We should be much more forceful in requiring a JIRA identifier in every change request title to link the commit with the corresponding JIRA item in a git log."
Answer: 3406.0

User story: "Fabric needs to provide the chaincode developer appropriate tools to perform chaincode-level access control. Currently, the cc dev can access the binary blob of the creator; however this is insufficient because the cc dev doesn't have access to the chain msp infrastructure and can't therefore reason in terms of the organizations that make the channel.    We propose to add a system chaincode for access control, exposing two functions  * *SatisfiesPrincipal*  * *EvaluatePolicy*    *SatisfiesPrincipal* takes two arguments  * a serialized identity  * a serialized MSPPrincipal  The function returns a success code if the identity has the requested attributes (e.g. membership to an MSP or a specific OU) as described in the MSPPrincipal (and an error code otherwise).    *EvaluatePolicy* takes three arguments  * a serialized policy object (to be specific a SignaturePolicyEnvelope)  * a message  * an array of serialized identities  * an array of signatures  The function returns a success code if the array of signatures from the serialized identities properly sign the supplied message and if they match the description in the serialized policy (for instance the SignaturePolicyEnvelope requires signatures from 3 principals out of 5 described in the SignaturePolicyEnvelope object, EvaluatePolicy will return true if there are 3 signatures from 3 of the 5 principals)."
Answer: 1464958.0

User story: "I've observed that https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/download-dockerimages.sh downloads x86_64 images on ppc64le & s390x platforms.    I will be putting up a patch that would pull relevant docker images from docker-hub ."
Answer: 25552.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 project has not adopted a pattern for documenting release notes. We have some alternatives we can use. We need to come to agreement on an approach and then institutionalize and automate to the extent possible.    examples:  k8s   https://github.com/kubernetes/kubernetes/releases  https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md    docker  https://github.com/docker/docker/releases    cloud foundry  https://github.com/cloudfoundry/cf-release/releases"
Answer: 86163.0

User story: "Part of FAB-2400.    This item relates to the extension of the OU definition inside an MSP and outside an MSP to  bind it to the specific chain of certificate authorities that handle the OU.  This item consists of three sub-tasks:    A) Define FabricOUIdentifier as an additionally defined message in common package defined as follows     - byte[]/string certifiersIdentiifer // hash of certificate chain to the root     - string OrganizationalUnit // current organizational unit identifier    B) Update the MSP GetOrganizationalUnit function implementation to return FabricOUIdentifiers. Computation of the FabricOUIdentifier.certifiersIdentifier is to be computed as follows:       - 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    C) Modify MSP Principals for OU to accommodate FabricOUIdentifiers.  "
Answer: 4130.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "As an organization that participates in a channel, I would like the channel to independently confirm the validity certificates issued by a Fabric CA so that I can reduce my trust requirements on the CA.    Currently an organization would need to run its own Fabric CA to control the issuance of certificates. This requirement adds complexity for that organization's participation. There is also a level of sophistication needed to securely run a CA. To mitigate, it would be good to allow certs to be issued by a provider who has the operational controls for issuing certificates and operating a CA, but also allow an organization to independently confirm the validity of those issued certificates (if they wish).    *Goals*   * Validate certificate, as usual, against trust root.   * Check certificate fingerprint against organization-provided & controlled list (when the organization has opted-in).    *General background information*   * OWASP on [Certificate and Public Key Pinning|https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning]    *Example Implementations*    The implementation considerations for this ticket have similarities to implementing a revocation list. However, we should try to reduce complexity for the organization where possible.   * +Certificate fingerprints hosted by organization+. Have endorsers pull a certificate fingerprint list from a registered domain of that participant. The channel needs to be configured with the root CA list & the optional endpoints of the fingerprint list for each root CA.   ** Note: with this mechanism, the fingerprints can only be checked _at endorsement time,_ otherwise there could be non-determinism on commit. FAB-3678 contains a related discussion.   ** It is possible that two endorsers have different fingerprint lists (fingerprint list host was down, fingerprint list changed between calls, ...). In these situations, the client could retry if they have sufficient knowledge of the error.   ** Seems plausible that this mechanism could be contained into an Auth Handler (FAB-4207)   * +Load certificate fingerprint list into the channel+. The participant needs to control a key that signs their fingerprint list. The channel needs to be configured with the root CA list & the optional signing keys of the fingerprint list for each root CA. This implementations similar to revocation lists.   ** This mechanism avoids the _endorsement time_ limitation above, but increases the complexity on the participant. In fact, this approach has some of the complexities of running the CA software ... but still allows for dual controls (the CA issues the cert & the org issues the list).   ** Need to deal with key rollover and loses."
Answer: 1469183.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: "Just like the fabric-ca project, the fabric-orderer is individual from peer nodes in functionalities.    Using a separate project will improve maintenance with more pluggable consensus implementations, and the deployment architecture would be more clear.    I temporarily mark this to target 1.1, and we can certainly discuss if this would be included in 1.0 release.    Thanks!"
Answer: 1469276.0

User story: "`orderer.yaml` should default to the file ledger and have it stored in a directory outside the `/tmp` path"
Answer: 32958.0

User story: "Composer includes a generic chaincode that is used for the deployment of a all business networks.  The business network definition that contains the model files, script files, and ACL rules (which describe a business network), are passed into the generic chaincode and stored in the world state.    Currently for v1.0 we have to install and instantiate the generic chaincode for every business network with a chaincode ID that matches the business network ID (for example org.acme.carauction).    It would be ideal if we could install the generic chaincode once, with an ID of something like hyperledger.composer, and then instantiate it multiple times within the same channel or across multiple channels with the business network ID. The business network definition is passed in via the chaincode Init() function during instantiate.    For example:  # Install hyperledger.composer chaincode onto each peer.  # Instantiate car auction business network as org.acme.carauction by instantiating hyperledger.composer chaincode with the car auction business network definition.  # Instantiate truck auction business network as org.acme.truckauction by instantiating hyperledger.composer chaincode with the truck auction business network definition."
Answer: 1470564.0

User story: "Currently, we cannot specify the configtx.yaml file path for the tool.    It would be more flexible to use if can support as cmd parameter."
Answer: 8830.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: "Related [FAB-60|https://jira.hyperledger.org/browse/FAB-60]     Currently Fabric has a pluggable database used to cache the state of the ledger to provide quick queries. The built-in database is LevelDB, which provides limited queries based on keys. The framework enables plugging in a database by implementing some interfaces. An example provided is CouchDB, a JSON database that allows much richer queries using CouchDB native query language. However there are issues with this approach that we should discuss and find resolutions for.  # Once a chaincode uses native query language, wherever the chaincode runs, the supporting database must be present. It could force the entire network to install and support the database.  # The result of the query is not guaranteed to be stable between endorsement and validation/commit time, potentially causing phantom reads (e.g. item inserted by another tran that should have been considered in current tran).  # The database (like CouchDB) runs in a separate process from the Peer, so additional security considerations must be observed to satisfy the security policies configured on the blockchain network.    So the question is should we define a common abstraction layer (like JDBC) to allow portable OLTP in chaincodes, pick an existing ORM/DAL, or stay with what we have which is DB vendor specific?"
Answer: 1471866.0

User story: A nit, but rename the software "keystore" field to "dir" to make it more intuitive, so that config looks like:  {code}  filekeystore:      dir:  {code}    rather than    {code}  filekeystore:       keystore:  {code}  
Answer: 1472122.0

User story: "This task refers to a check that needs to be performed by an orderer each time a channel creation request is submitted to the system ledger. In this case orderers need to check that MSPs included in the new channel, are consistent in configuration with the MSP configuration in the system ledger.     That is an msp with id ID in system ledger, has the same configuration as the msp with the same id in the new channel. Orderers should reject channel creation requests if this check is not validated.    *Problem* associated here relates to the addition of new MSPs. How can the orderers check that consistently since after a channel's genesis there is no ordering of the new channel's transactions w.r.t. system channel transactions..."
Answer: 1473170.0

User story: "Build and publish native binaries like configtxgen, cryptogen etc.. to support chaincode development on windows systems. Build binaries as part of CI release process and push them to nexus3 repository."
Answer: 128000.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: "https://gerrit.hyperledger.org/r/#/c/7221/ added QueryResult structures to chaincode shim.  Need to switch these golang structs to protobuf messages to keep them language agnostic, so that Java chaincode can reference the QueryResults."
Answer: 24571.0

User story: "There would be great to have an ability to use local cryptographic standarts, like russian GOST. As far as i know, the most convnient way to do it - plug through OpenSSL. Maybe there are other ways with Go, but i am not informed enough. Anyway, this feature will be a real enabler or vice versa a huge problem in promoting Fabric if not implemented."
Answer: 1474781.0

User story: "https://gerrit.hyperledger.org/r/#/c/7221/ has updated the query iterator approach for go chaincode.  Need Java chaincode to add similar support for the following query APIs:  GetStateByRange()  GetStateByPartialCompositeKey()  GetQueryResult()  GetHistoryForKey()"
Answer: 65067.0

User story: "we need to check that the following are covered:      a) chainless QSCC - discus with Murali what needs to be put there; simple answer peer MSP admin.      b) chain-full QSCC - check READ policy of the chain in corresponds to (some issues we may want to discuss here)       c) chainless CSCC - this is for join channel essentially, where we check that the proposal comes from MSP admin      d) chain-full LCCC - function dependent:          -> chaincode instantiation one would need to check that invoker is within the instantiators, and owners of the chaincode          -> listing chaincodes on a channel: one would need to check that the invoker has read access to the channel info or is the peer’s msp admin          -> others?       e) chainless LCCC - again can be function dependent, but in the simplest case we can require that proposals invoking LCCC chainless functions need to be created by the peer’s MSP admin.       f) Chain creation operation, we need to check channel creation authorization.  "
Answer: 29207.0

User story: "The (system) chaincode needs to access the SignedProposal object in order to perform access control. The SignedProposal might be used for additional purposes too specific the chaincode's  logic."
Answer: 5916.0

User story: "As a user of Fabric, I should be able to d/l platform specific binaries for all tools including configtxgen fabric-chaintool, and fabric-ca (client) and any others that we currently require users to build from source."
Answer: 30102.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: After upgrading to newer version, unable to query the older version of chaincode,  using -v option in "peer chaincode query -v <version>"    Tested on Mar 31 2017 using:  commit 430c64d56eddd6365371a83e3b4ac074dbe3671d  Date:   Fri Mar 31 14:36:49 2017 +0000    1. Launched the orderer using the orderer binary      orderer  2. Launched the peer using the peer binary      peer node start -o 127.0.0.1:7050  3. Installed the chaincode_example02       peer chaincode install -o 127.0.0.1:7050 -n mycc -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02  4. Instantiated the chaincode      peer chaincode instantiate -o 127.0.0.1:7050 -n mycc -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}'  5. Queried the chaincode and obtained the value of a      peer chaincode query -o 127.0.0.1:7050 -n mycc -c '{"Args":["query","a"]}'  6. Installed the chaincode_example02 for version 2.0       peer chaincode install -o 127.0.0.1:7050 -n mycc -v 2.0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02  7. Upgraded the chaincode from version 1.0 to version 2.0      peer chaincode upgrade -o 127.0.0.1:7050 -n mycc -v 2.0 -c '{"Args":["init","c", "10", "d","20"]}'  8. Queried the chaincode version 2.0 for c value      peer chaincode query -o 127.0.0.1:7050 -n mycc -v 2.0 -c '{"Args":["query","c"]}' and successfully queried "c" value  9. Now I wanted to query the value of a on version 1.0      peer chaincode query -o 127.0.0.1:7050 -n mycc -v 1.0 -c '{"Args":["query","a"]}' and successfully queried "a" value, the query happened on chaincode version 2.0, but not the version I mentioned, version 1.0 in the command.   EXPECTED RESULT: "Peer chaincode query -v 1.0" is expected to query the chaincode version 1.0 in the appropriate container, even after the upgrade to version 2.0. However, it appears the version number option is ignored, and the latest version chaincode container handles the request.  10. Observed the logs of chaincode containers for both the versions 1.0 and 2.0, the query on step 9 is observed in verison 2.0 chaincode container logs, but not in the version 1.0 chaincode container logs.    
Answer: 934400.0

User story: "I am not sure if currently we already support disaster recovery. However I already found several tickets such as FAB-1371. I also wonder if it is worthy of doing this, though it can be done by some outside tool. However i feel it is better to have it if we want to create automatic operation program.    Refer to  https://github.com/coreos/etcd/blob/master/Documentation/op-guide/recovery.md    [~<USER>[~<USER>[~<USER>[~<USER>[~<USER>    "
Answer: 1479625.0

User story: Test the performance of the "z Systems" when working "natively" (maybe even outside docker?)  for performance comparisons.
Answer: 666472.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. Remove unnecessary struct  2. Bring it inline with const/init declarations I did in `common/configtx/tool/localconfig`    (By the way, the periods in the exported comments is not OCD but actually a guideline: https://github.com/golang/go/wiki/CodeReviewComments#comment-sentences)"
Answer: 35745.0

User story: "This is the first in a series of changesets that will allow us to quickly query the state of the Kafka cluster. This is itself needed so that we can decide whether there's a point in repeating a certain request (e.g. for the creation of a channel/partition in Kafka) or not.    We're vendoring the latest version of the sarama library because it introduces the `Brokers()` method to the `Client` interface, and this allows us to easily get the list of active brokers.    This changeset also adds a relevant (and now req'd) config setting, see: https://github.com/Shopify/sarama/issues/816 for more."
Answer: 2728.0

User story: "This changeset allows the tests on the kafka package to log their output to a flogging-initialized logger.    Note that this was already the case for the non-test path."
Answer: 3752.0

User story: "There are several things on this package that could use improvement on this package.    Off the top of my head as I'm writing this, I am noting down the following:    # Asymmetry on the return types; some functions return the logging level as the string type, others as the `logging.Level` type.  # Functions whose purpose is unclear (`InitFromViper`), whose name is inaccurate (`SetLoggingFormat` does not just set the logging format), or whose logic is simply flawed (`InitFromViper` - pay attention to how the input argument is used).  # Outdated and —in some cases— nonsensical comments on the exported functions.    This is my attempt to tidy things up. I've also updated the code that used to reference the now-deprecated methods."
Answer: 3764.0

User story: "Currently the only way to create and modify channels is via protobufs.  This is complex and error prone.  The SDK needs to simplify this for users.    Suggested implementation is for the SDK to take a json object describing the channel to be created, list of members, etc and create the channel.    "
Answer: 45371.0

User story: "As some of our recent debugging sessions have shown, the channel name is a useful bit of info to have on almost every log message that the orderer writes. This changeset delivers that.    This changeset also:    1. Switches all the Panic calls to their logger-enabled equivalent, in accordance to what we're starting to do throughout the `orderer` directory.  2. Lowercases all returned error messages, following the guideline posted in [1].    [1] https://github.com/golang/go/wiki/CodeReviewComments#error-strings"
Answer: 996.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 Kafka-based orderer would base16-encode channel names as a temporary workaround for escaping illegal characters in Kafka [1].    With the filtering added in FAB-1349 [2], this kind of workaround is not longer needed.    [1] https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/common/Topic.scala#L29  [2] https://jira.hyperledger.org/browse/FAB-1349"
Answer: 760.0

User story: "Tweak the behave tests to run outside of Vagrant on a non-Linux system."
Answer: 8868.0

User story: The following is in fabric-ca/lib/client.go (around line 143).  I think this logic should be pushed into BCCSP as it is specific to the SW implementation.    {code}    if bccspConfig == nil {     bccspConfig = &factory.DefaultOpts    }      if bccspConfig.ProviderName == "SW" {     if bccspConfig.SwOpts == nil {      bccspConfig.SwOpts = factory.DefaultOpts.SwOpts     }       // Only override the KeyStorePath if it was left empty     if bccspConfig.SwOpts.FileKeystore == nil ||      bccspConfig.SwOpts.FileKeystore.KeyStorePath == "" {      bccspConfig.SwOpts.Ephemeral = false      bccspConfig.SwOpts.FileKeystore = &factory.FileKeystoreOpts{KeyStorePath: mspDir + "/keystore"}     }    }  {code}
Answer: 689725.0

User story: "First block is block0.  To be consistent when looking at transaction 'height', first transaction in each block should be transaction0.     Also, the validation array for transactions within the block starts at 0.  This causes confusion between validation array height and transaction height.  Best to use '0' for first item everywhere consistently."
Answer: 33645.0

User story: The FSM was used in the original 0.5, 0.6 chaincode where a state machine approach helped handle different types of requests with different serialization needs. In 1.0, the framework is simplified drastically   * there are no concurrent queries and serial invokes. There are only invokes and they are all concurrent  * splitting "deploy" into "install" and "instantiate" further simplifies "Init" handling where the flow resembles "Invoke"    Remove of FSM  has the following benefits  * helps to simplify by indirections and callbacks related to FSM  * this will have some performance benefit by eliminating need to streamline flows through the FSM.  * will make it much easier to add new platforms (this is probably the most important benefit)    This will be split into following tasks  * peer side cleanup  * shim side cleanup for java  * shim side cleanup for go    These are independent tasks as the FSM is an implementation detail that does not bleed component boundaries.  
Answer: 1485891.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 order to support PKCS11,  [3rd party package|https://github.com/miekg/pkcs11] which has a dependency on libtool was added.  This complicates things when trying to build native binaries locally as you now have to install a dependency (which may or may not be easily available / installable on all platforms).    Conveniently, Go supports the notion of build tags for "conditional" compilation.  In order to optionally support building without PKCS11 support, we'll add the build tag {{nopkcs11}} to the bccsp factory package and then add a GO_TAGS flag to our makefile as well as adding {{-nopkcs11}} targets for the peer and orderer.  The {{configtxgen}} target will be modified to always build without PKCS11 support since it is not required.
Answer: 12875.0

User story: "No more:    1. ```Checking for configtx.yaml at:  Checking for configtx.yaml at:  Checking for configtx.yaml at: /opt/gopath/src/github.com/hyperledger/fabric/common/configtx/tool```    2. Dumping the `TopLevel` config struct on screen. (This is what the `-inspectXYZ` flags are for.)"
Answer: 3235.0

User story: "Config Transactions are used for creating and updating channels / chains / Ledgers. The information and processing requirements are complex, recently re-architected, and not really documented (both for understanding and how-to). Understanding how to generate and manage Config Transactions and the authorization strategies surrounding them is key to understanding how to manage chains and chaincode."
Answer: 521394.0

User story: Using CouchDB rich query functionality in the current implementation introduces a potential phantom read problem. As an example if endorsing chaincode performs a rich query to determine if a transaction is a duplicate and returns no results (happy path), by the time the commit happens that same query "could" produce a different result in the situation where a prior transaction was committed between the endorsement and committing phase.    Range queries against the LevelDB protect against this by rerunning the query at commit time. Currently, the rich query is not rerun and thus the result set is not validated for the query at time of commit. Protection against phantom reads should be included for CouchDB rich queries. 
Answer: 168216.0

User story: "Currently, the indexes are created using the CURL command to couch-db and this becomes not easy to scale where the channel count can shoot to hundreds.    There is need to have SHIM interface that can create index in user-chain-code. This needs to be thought how more indexes can be added (should it be done by user-chain code upgrade?).        "
Answer: 326766.0

User story: [~<USER> could you please create/add "last updated" field in docker component nexus repository similar to docker hub repository. image references are attached here..    
Answer: 695393.0

User story: "Seed the new Go SDK repository from the master branch of https://github.com/securekey/fabric-sdk-go    "
Answer: 4859.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: "A potential future work item resulting from the private data paper (the core of the private data feature is described by FAB-1151). Message routing policies could be customized to ensure that private data only traverses organizations, as determined by the policy for the partition.    There is a short description in section 5. [https://docs.google.com/document/d/1ShrgrYPWLznZSZrl5cnvmFq9LtLJ3tYUxjv9GN6rxuI/edit]          "
Answer: 1490378.0

User story: "Conduct Ledger performance test, gather results, analyze.     1.  Using Manish's test tool, test performance with goleveldb.  2.  Run the same tests with couchDB.  3.  Add a small test to Ramesh's verify CI run to catch any major performance hit.  4.  Add the full suite to a nightly run as we build up the nightly regression run. "
Answer: 270367.0

User story: "Changes are forthcoming that will augment the current usage of ChaincCreatorsPolicy in config block."
Answer: 49316.0

User story: "Currently {{peer cli}}, has capability to execute join channel cscc proposal, while it's not possible to query peer and get the list of channels it joined in the past. Having this functionality is also beneficial to being able to validate the results of join channel command."
Answer: 14552.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: Threshold cryptography distributes a cryptographic scheme among the members of a group of peers in a resilient way, such that N peers execute the function collaboratively, while tolerating a number F of faulty and misbehaving peers.    With a threshold signature scheme, a digital signature is produced collaboratively by the group of N peers, and despite that F of them could be corrupted, no valid signature can result unless some correct peers have also consented to sign. This property is also achieved by multi-signatures, but in a different way: for multi-signatures, a verifier needs to know the list of all peers authorized to sign; a threshold signature scheme instead uses one ordinary signature verification key and produces signatures in the usual format. A threshold signature only needs one verification key and a signature represents the resilient consensus of the abstract signing group.    More precisely, a threshold signature scheme consists of the following algorithms:    (1) A key generation algorithm that generates a public-private key pair, a set of N secret key shares, one for each peer, and a set of verification keys.    (2) A signing algorithm that, given a message and a secret key share, outputs a signature share.    (3) A signature share verification algorithm. Given a message, a signature share, the public key, and a peer-specific verification key, it succeeds if the signatures share is valid.    (4) A share combination algorithm that given a set of N - F valid signature shares from distinct peers outputs the final signature.    (5) A signature verification algorithm, which is no different from ordinary digital signature schemes.    This work includes the implementation of two different threshold signature schemes:   * RSA-based threshold signatures    Shoup, Victor. "Practical threshold signatures." In International Conference on the Theory and Applications of Cryptographic Techniques, pp. 207-220. Springer Berlin Heidelberg, 2000.   * BLS-signatures (based on EC cryptography)    Boneh, Dan, Ben Lynn, and Hovav Shacham. "Short signatures from the Weil pairing." Journal of cryptology 17, no. 4 (2004): 297-319.    Threshold signatures enhance the robustness and the resilience of the blockchain system.
Answer: 1490934.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "As chris suggested, we create this jira task.    The conditional process in core/chaincode/shim/chaincode.go is complex to understand, and easy to introduce problem."
Answer: 6412.0

User story: "Too early for this, should never have let it in to begin with. See: http://hans.gerwitz.com/2004/08/12/premature-optimization-is-the-root-of-all-evil.html    Also note that a recent commit broke this environment entirely, since it gave the `orderer` service a hard-coded `container-name`."
Answer: 7937.0

User story: "Especially if couchdb is installed remote from peer, TLS connection is required to secure the communication."
Answer: 1493828.0

User story: "using examples/e2e_cli,the peer nodes have a lot of TCP connectoin. Why? BUG?  tcp        0      0 172.18.0.4:58242        172.18.0.5:7051         ESTABLISHED  tcp        0      0 172.18.0.4:40096        172.18.0.5:7051         ESTABLISHED  tcp        0      0 172.18.0.4:52170        172.18.0.5:7051         ESTABLISHED  tcp        0      0 172.18.0.4:59636        172.18.0.5:7051         ESTABLISHED  tcp        0      0 172.18.0.4:58258        172.18.0.5:7051         ESTABLISHED  tcp        0      0 172.18.0.4:40906        172.18.0.5:7051         ESTABLISHED  tcp        0      0 172.18.0.4:43598        172.18.0.5:7051         ESTABLISHED  tcp        0      0 172.18.0.4:39358        172.18.0.5:7051         ESTABLISHED  # netstat -an | wc -l  2293"
Answer: 1494240.0

User story: "The build currently assumes docker.io/hyperledger when dealing with docker images.  There may be cases such as in QA/CI or for downstream/private implementations where other registries would be desirable.  The build should make this configurable"
Answer: 27542.0

User story: "* Complete and accurate API references doc  * Easy to follow tutorials with code snippets"
Answer: 153852.0

User story: "It's pretty hard to debug GRPC connection errors (since typically bad connections end up throwing a timeout).    Investigate and hopefully implement a solution to this."
Answer: 117785.0

User story: "The read-write set of a transaction uses custom serialization/deserialization. Change this to use proto messages so that it's easier to share with other components such as SDK."
Answer: 25081.0

User story: In fabric, the logging is based on go-logging and logs indefinitely to the same file (to stdout, but I'm sure it can be configured to log to a file too somehow).     If the logging is set to DEBUG, the log file size may grow in a fast rate, eventually filling the partition the log resides in.  It would be good to have the logging framework be able to "switch" to a new file, and archive (gzip or something similar) the old log files after switching to the new file.      [~<USER> [~<USER> [~<USER> 
Answer: 1500759.0

User story: "Kafka integration into BDD with [~<USER>."
Answer: 9743.0

User story: "Enable couchDB option for peer DB in boostrap feature."
Answer: 9747.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: "From Manish:    https://github.com/gogo/protobuf acts as a protoc plugin and generates the message specific code for fast serialization.  Appears to be 2x as fast as plain protoc.    Inside `proto.Marshal()` function in golang it first checks that whether the `obj` implements `Marshal()` function and if yes then it simply invokes it.    So, we just need to install `https://github.com/gogo/protobuf` into vagrant and change in the `make protos` command in our build (from `protoc --go_out=...` ` protoc --gofast_out ...`)."
Answer: 1503344.0

User story: "Add specific couchdb query tests at the couchdb level."
Answer: 29205.0

User story: "The user should be able to impose a limit on the # of channels that can be created on a given network to prevent someone from continuously creating channels until kafka falls over or we exhaust some resource.  This limit should be able to be specified in configuration vs hard coded."
Answer: 28210.0

User story: "A startup process of a Client/SDK instance would generally be the result of the client being down for some period of time and initially on startup going into a recovery / synch mode to bring its Eventing of Blocks up to the current state. As the Client/SDK can/probably will be supporting multiple channels it would be beneficial to be able to receive the Block Events in the order generated across all authorized channels. To support this a synch Query via the SDK would need to accept the beginning Block Seq Id and channel for it. It would return all Block Events in timestamp order equal to and after that for all channels the Peer is authorized to. "
Answer: 1504714.0

User story: "This is the top story where we collect the testing configuration and set up procedure to enable TLS in Fabric 1.0.    Note that as of March 11th, from Fabric master branch, you need to cherrypick 2 additional CRs below  as they haven't been merged:  https://gerrit.hyperledger.org/r/#/c/7133/  https://gerrit.hyperledger.org/r/#/c/7127/    Create a subtask to enter your configuration and procedure."
Answer: 120578.0

User story: Now a lot of errors are printed like this:  logger.Warningf("Rejecting broadcast message because of filter error: %s", err)    But in log we can see:  [orderer/common/broadcast] Handle -> WARN 011 Rejecting broadcast message because of filter error: %!s(<nil>)    Error message is missed.
Answer: 15808.0

User story: "The configuration options need to be described in detail, core.yaml, order.yaml,  The fabric-ca documentation needs its own story.  "
Answer: 1490256.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 is a gRPC logger that is silenced by default because it logs messages when peers disconnect:  {quote}2017/03/10 20:01:22 grpc: addrConn.transportMonitor exits due to: grpc: the connection is closing  2017/03/10 20:01:22 grpc: addrConn.transportMonitor exits due to: grpc: the connection is closing  2017/03/10 20:01:22 grpc: addrConn.transportMonitor exits due to: grpc: the connection is closing{quote}    The silencing line is found in https://github.com/hyperledger/fabric/blob/master/gossip/util/logging.go#L57    Sometimes, however- this information is useful for debugging issues.  I suggest having this gRPC logger silenced upon demand by a viper configuration.    [~<USER> [~<USER> [~<USER>"
Answer: 76467.0

User story: "Enable TLS usage in the bootstrap feature wrt to Peers and Orderers as well as the behave (SDK)."
Answer: 7438.0

User story: "Interactions with CouchDB are currently done individually.  Need to switch to using bulk operations to get optimal performance from CouchDB.  Need to performance test and stress test."
Answer: 389891.0

User story: "Need to have read write sets sent with EventHub blocks  [~<USER> [~<USER> [~<USER>"
Answer: 1513507.0

User story: Currently while peer joins the channel it accepts the configuration/genesis block. Afterwards peers use this block to create the ledger and initialize the entire infrastructure, the actions of ledger creating and block commit are separated.     {code}  // CreateChainFromBlock creates a new chain from config block  func CreateChainFromBlock(cb *common.Block) error {   cid, err := utils.GetChainIDFromBlock(cb)   if err != nil {    return err   }   var ledger ledger.PeerLedger   if ledger, err = createLedger(cid); err != nil {    return err   }     if err := ledger.Commit(cb); err != nil {    peerLogger.Errorf("Unable to get genesis block committed into the ledger, chainID %v", cid)    return err   }     return createChain(cid, ledger, cb)  }  {code}        createLedger() should accept the genesis block, so that the ledger creation and commit of genesis block can atomically succeed or fail.  A ledger should only be created if the corresponding genesis block is committed.    
Answer: 70598.0

User story: "See https://gerrit.hyperledger.org/r/#/c/5929/10/orderer/ledger/file/fileledger.go@50 for context."
Answer: 191505.0

User story: "It has been suggested to change where Fabric outputs its log statements from os.Stderr to os.Stdout.     This item will be used to handle the discussion."
Answer: 3006.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: "When user execute *peer chaincode install* in peer container (not in cli container) and GOPATH is not set *panic: runtime error: index out of range is thrown*.    Expected behavior is this situation to be handled and instead of panic user to see error message explaining the reason for the error.    To reproduce execute this command in peer node without or with wrong GOPATH    CORE_PEER_ADDRESS=peer0:7051 peer chaincode install -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -v v0  "
Answer: 1515197.0

User story: As a fabric tester or support personnel, it is difficult to understand why a transaction fails validation in the VSCC, even with DEBUG logs, so debugging issues is very time-consuming. At the point of failure, it would be much more helpful to see the following information displayed (maybe at the INFO level?):  * the policy being used to validate the identified transaction  * the names of the signers (peer name, and associated org name). At one point I saw a log with the hash signature of signer(s), but that is difficult for tester to understand and trace.  * the names of signers/orgs that are lacking    For example, if the policy is "AND('OrgRedMSP.member','OrgBlueMSP.member')" then a TX must be signed/endorsed by any one member of OrgRed or any one member of OrgBlue. If peer00 is in OrgRed and peer00 endorses a transaction, and there are no other signatures, then the log could state something to the effect of the first part being satisfied (peer00 = OrgRedMSP.member) however the validation failed due to lacking signatures from any OrgBlueMSP.member.    And I would hope the same information could also be provided to the SDK or any process that registers for event failure notification.    Existing log:    peer2        | 2017-03-02 21:50:57.835 UTC [txvalidator] VSCCValidateTx -> ERRO 001 VSCC check failed for transaction txid=de8c2db2f9bce9be2ab2864339a08862ab9de8280c2c0b919930eb22fbaecf94, error VSCC error: policy evaluation failed, err Failed to authenticate policy  peer2        | 2017-03-02 21:50:57.839 UTC [txvalidator] Validate -> ERRO 002 VSCCValidateTx for transaction txId = de8c2db2f9bce9be2ab2864339a08862ab9de8280c2c0b919930eb22fbaecf94 returned error VSCC error: policy evaluation failed, err Failed to authenticate policy  
Answer: 709686.0

User story: "One use case:  Upon joinChain() the peer creates the ledger with genesis block temporarily.  And then real genesis block is delivered from orderer, and is compared with the temp genesis block. If they are not the same, we need to drop the temp ledger.    Going forward, there will also need to be normal chain/ledger cleanup capability as well."
Answer: 1519109.0