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: "     I had 6 peer containers running, 3 for each organisation. Out of 2 , 1 was admin and 2 were user containers. Now I had deployed a chaincode on it and the deployment was successful.    Now once the chaincode was successfully deployed, after some time, the peer through which the chaincode was deployed went down. This caused the chaincode to also go down.     Since the chaincode was deployed using composer, I tried redeploying it but the peer was giving the error :- The chaincode already exists. The chaincode was present inside the peer in /var/hyperledger/production/chaincode    Also if I tried to bring up the chaincode container up manually, the peer did not allow it and gave error that chaincode cannot be invoked externally(it can be done in dev mode).    This behaviour is not good because If the peer somehow goes down, the chaincode wont be invoked automatically. This should happen automatically.    If any more information is required, Kindly inform me. "
Answer: 917557.0

User story: "The peer codebase currently assumes that all system chaincodes are at the version of the current peer binary.  This makes backwards compatibility very difficult and generally breaks the idea of versioning system chaincode."
Answer: 694785.0

User story: Now we have basic MSP and Idemix MSP. In the future, we may have additional types of MSP. e.g. x509 certificate processing in golang doesn't support some regional standard crypto algorithms, so another MSP need to be implemented.      To avoid code invasion, we can leverage support for Go-based plugins to implement a "plugin" MSP.  Just like [FAB-6189] Implement bccsp plugin     The plugin provider will be simple:   - implement the msp interface   - config will take a path to a plugin module as well as a raw map[string]interface\{}    The provider will load the plugin and simply call the matching exported methods.
Answer: 919522.0

User story: "The end to end scenarios make use of docker networks for communication between containers but the current version of the client used in master does not contain that level of support.    It appears (from references in our doc) that we're now requiring docker-ce 17.06. That engine version corresponds to API version 1.30.    The v1.0.0 version of the fsouza docker client corresponds with API version 1.23 and contains the support needed for networking."
Answer: 1118.0

User story: "The peer CLI should provide a flag that, when enabled, allows the end user to connect to the deliver service on the peer(s) it has requested endorsements from and wait for the block containing the transaction to be committed to the peer ledger(s)."
Answer: 33395.0

User story: "# Remove the {{init}} functions  # Rename the package to {{localconfig}}, identical to the folder name that contains it"
Answer: 1748.0

User story: "As a prerequisite to doing the lifecycle work, it makes sense to remove the assorted chaincode singletons.  These singletons make development difficult and testing haphazard. "
Answer: 47026.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: # "each group is its own en " -> "each group has"   # "result was generated a different time" -> " "result was generated at different time"   # As a beginner, it confused me a little bit when I read "in phase 3, each peer will verify that the transaction has been endorsed by ..." because the transaction proposal has been endorsed at phase 1 before being sent to the orderer. After a second thought, I realize in phase 1, it is the application that determines whether to send proposal to the orderer. Application can send any transaction proposal to the orderer; so the peer must verify the transaction by applying the endorsement policy by itself.    If my understanding is correct, I think it may help the reader to understand if this could be explicitly stated.
Answer: 10936.0

User story: "{{tlsCipherSuites}} in {{core/comm}} is not exported. For symmetry's sake, consumers of this package should have access to this value, as is the case for {{keepAliveOptions}} via the {{DefaultKeepAliveOptions}} getter."
Answer: 1008.0

User story: "See details in review for [https://gerrit.hyperledger.org/r/#/c/19093]"
Answer: 927905.0

User story: "It appears that in fabric-samples folder the example high-throughput hasn't been updated since the new Fabric release. Is it compatible with the new Fabric release (Version 1.1)? "
Answer: 27222.0

User story: "* The installation link [1] in the README.md is broken.   * [https://github.com/hyperledger/fabric/blob/release-1.1/devenv/README.md] [2]    [1][http://hyperledger-fabric.readthedocs.io/en/latest/samples.html]    [2]https://github.com/hyperledger/fabric/blob/master/docs/dev-setup/devenv.md"
Answer: 6418.0

User story: "Almost everyone seems to bootstrap their orderer system channel with the terrible default name of 'testchainid'.    We should remove the default so that users are not confused or surprised by a 'testchainid'.  But first, we should deprecate the function in v1.2."
Answer: 443341.0

User story: To fix some minor grammar error found in the doc.   # "and as such, it that defines the" should be "and as such, it -that- defines the"   # "can happen fora number of" misses a space between for and a
Answer: 910320.0

User story: "There's been a request for examples in the fabric code of component level integration tests. We'll be using chaincode support and its related assets to do this work."
Answer: 206054.0

User story: "Can't load the `_static/images/` because of the incorrect relative path.      https://hyperledger-fabric.readthedocs.io/en/release-1.1/identity/identity.html"
Answer: 44568.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 filtered events don't have any indication of the chaincode name.   That is acceptable, as we don't want to leak any data other than the minimal necessary for the application to know that its transaction was validated or not.    Note: The chaincode id appears in the chaincode events, but not every chaincode has an event.  {code:java}  message ChaincodeEvent {        string chaincode_id = 1;        string tx_id = 2;        string event_name = 3;        bytes payload = 4;  }  {code}  Ideally, the SDK would be notified about endorsement policy changes so that it can immediately issue a new query for the endorsers of the chaincode from the peer(s) that act as the discovery servers, so it can have accurate information about which organizations it should or should not send endorsements to.   * When normal endorsements are involved, it is sufficient (from confidentiality point of view) to re-query the discovery service only upon a config change. This is possible right now because the filtered events have an indicator of the header type and config transactions also get sent to clients via the peer deliver service ( [~<USER> - am I correct?) and thus can be used for the application to determine whether it should re-send an endorser query (or a config query, etc.)   However, we might also want to know about endorsement policy changes, so the SDK won't send transactions that are invalid and thus waste resources and time.   * When transactions with private data are involved, we need to know whether the collection config changed or not, so the application won't send sensitive data to the peer. I see 2 ways of tackling this:   ** Have an LSCC instantiate or upgrade contain a chaincode event via *stub.SetEvent()*, which would be transferred to the SDK.   ** Add a new oneof type to the *Data* field and have it indicate an LSCC write.  {code:java}  message FilteredTransaction {      string txid = 1;      common.HeaderType type = 2;      TxValidationCode tx_validation_code = 3;      oneof Data {          FilteredTransactionActions transaction_actions = 4;      }  }  {code}    Would like to hear opinions about:   # What approach should we take   # What version should this be targeted for?    [~<USER> , [~<USER> , [~<USER> , [~<USER> [~<USER>"
Answer: 14144.0

User story: "In FAB-9211 the title of the page was renamed from 'Hyperleger Fabric Samples' to 'Install Samples, Binaries and Images'.    So now 'Install Samples and Binaries...' occurs twice in the getting started toc which is confusing.     "
Answer: 5657.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 Stack Overflow 4/14    What is an artifact?    I see the word everywhere in building a Hyperledger network, but I don't exactly know what it is and the Hyperledger docs don't return a definition when I query them.   Maybe it's a dumb question because the docs don't define it and assume you should know, but I don't and can't find a precise answer to it.       Artifacts in Hyperledger are channel configuration files which are required for the Hyperledger Fabric network. They are generated at the time of network creation.    These include:   # Genesis.block: First block of a chain, that initializes a block chain   # Channel.tx: Channel configuration transaction   # Org1MSPanchors.tx: Anchor Peer update (Defining a peer from Org1 as an anchor peer)    configtxgen command is used to create the above channel config artifacts."
Answer: 930848.0

User story: "The document has both American and British spelling (organization/organisation, etc.).    Since labels in configuration file (configtx.yaml), standard configuration directory (crypto-config/peerOrganizations) and many identifiers in source codes use American spelling, it would be kind to a reader if the document use American spelling consistently."
Answer: 1719.0

User story: "The core/comm package contains some anti-patterns, for example   * TLSEnabled() is a package scoped function which returns parsed config   * There are vars which have matching packages functions which should be public constants"
Answer: 548461.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 MSP cache, caches the invocation of *SatisfiesPrincipal*, however - many of the invocations of *SatisfiesPrincipal* are invoked indirectly via the identities that the MSP returns via *DeserializeIdentity()*, and these invocations are *not* cached, because the bccsp msp's identity simply invokes the bccsp MSP's *SatisfiesPrincipal()* which bypasses the cache.  {code:java}  func (id *identity) SatisfiesPrincipal(principal *msp.MSPPrincipal) error {   return id.msp.SatisfiesPrincipal(id, principal)  }  {code}  The following test:  {code:java}  func TestSatisfiesPrincipalIndirectCall(t *testing.T) {   mockMSP := &mocks.MockMSP{}   mockMSPPrincipal := &msp2.MSPPrincipal{PrincipalClassification: msp2.MSPPrincipal_IDENTITY, Principal: []byte{1, 2, 3}}     mockIdentity := &mocks.MockIdentity{ID: "Alice"}   mockIdentity.On("SatisfiesPrincipal", mockMSPPrincipal).Run(func(_ mock.Arguments) {    panic("shouldn't have invoked the identity method")   })   mockIdentity.On("GetIdentifier").Return(&msp.IdentityIdentifier{Mspid: "MSP", Id: "Alice"})   mockMSP.On("SatisfiesPrincipal", mockIdentity, mockMSPPrincipal).Return(nil).Once()   mockMSP.On("DeserializeIdentity", mock.Anything).Return(mockIdentity, nil).Once()     cache, err := New(mockMSP)   assert.NoError(t, err)     cache.SatisfiesPrincipal(mockIdentity, mockMSPPrincipal)   identity, err := cache.DeserializeIdentity([]byte{1,2,3})   assert.NoError(t, err)   identity.SatisfiesPrincipal(mockMSPPrincipal)  }  {code}  fails, and demonstrates this. Had the *SatisfiesPrincipal*() method been cached for the identity, it would not have run the method of the identity.  {code:java}  --- FAIL: TestSatisfiesPrincipalIndirectCall (0.00s)  panic: shouldn't have invoked the identity method [recovered]  {code}
Answer: 6620.0

User story: "In the Contributions Welcome! section it would be nice if we provided class diagrams/overview on the code structure - see HyperLedger Fabric e-mail below:    https://lists.hyperledger.org/pipermail/hyperledger-fabric/2018-April/003353.html    Hello Everyone, I have started going through source code of fabric and followed the contribution guide to set up a dev environment along with other prerequisites like linux foundation ID. I have been able to understand little bit of code structure but going through all the code, my progress seems to be slow. It would be helpful if anyone can provide any documentation or class diagrams. Thanks Sushil Paneru"
Answer: 934690.0

User story: "The current couchdb image sets the user:group to couchdb:couchdb but does not explicitly set the UID and GID.  This results in the UID and GID being chosen and can conflict with UID/GID already present on the host system.  Normally this is not a problem but in order to allow persistence you need to mount an external volume and want to make sure that you don't accidentally pick up the privileges of an existing user.    The industry seems to be moving towards using the listen port as the UID and GID so we'll do that here as well."
Answer: 263157.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: "Developers should be able to construct strings corresponding to valid policies by using the allowed operators from the {{cauthdsl}} package. This is not possible today because the gates and principal roles are not exported. The fix should address just that, i.e. group and export the allowed gate and principal values."
Answer: 143.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: Many applications of blockchains require data confidentiality. In   particular, financial transactions, voting on the blockchain, sealed-bid   auctions, and many more applications come with strong requirements in   terms of privacy and correctness. A voting system, for instance, must   protect the confidentiality of every vote cast and must provide means to   verify that every submitted vote has been considered in the final voting   result. The latter can be achieved by using blockchain technologies,   where every vote is a transaction stored on the ledger. However,   maintaining confidentiality in an open and verifiable blockchain is a   difficult problem (also in a permissioned, consortium blockchain). For   example, an application for voting running on Fabric would be implemented   by a chaincode that receives encrypted votes, records them, and decrypts   them later, in order to compute the final voting result and take further   actions. This system would need to keep the decryption key for the   encrypted votes secret, since the chaincode is executed by all endorsing   peers. Or it would need to trust all endorsers, which reduces the   benefits of the blockchain model.    The design should work with only one Fabric channel. Apart from using   advanced cryptographic protocols, such as Zero-knowledge Proofs or Secure   Multiparty Computation, no solution is available for this within Fabric   today. In other words, maintaining confidentiality of secrets manipulated   by a chaincode requires trust in the endorsing peers. Thus, a single   corrupted endorsing peer may violate the confidentiality of the   application.    To overcome this issue trusted execution environments such as Intel SGX   have been proposed. This document starts the design for adding support   to securely execute chaincode using Intel SGX in Fabric. With Intel SGX,   a peer executes chaincode in a trusted execution environment, also called   an enclave. SGX enforces confidentiality and integrity of the chaincode   even when the peer system is misbehaving. In order words, using SGX, a   voting chaincode may evaluate the voting results without revealing the   encrypted votes to the executing peer.    However, simply running "the chaincode" in an enclave is not enough, as   steps for ensuring consistency between the execution and the ledger state   and for verification of the outputs by the clients are needed.    The design document describing the model:   [https://docs.google.com/document/d/1-4BQpBOnFs7ijj2iirbO38FNJU5F7DLdpXJ1GQqboAM/edit?usp=sharing]    A detailed design and a research prototype for this function are described in a paper released on arxiv in May 2018:  [https://arxiv.org/abs/1805.08541]    Comments should be discussed here.    The prototype code is available as a Hyperledger labs.  https://github.com/hyperledger-labs/fabric-secure-chaincode
Answer: 935086.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 software-based implementation of the BCCSP interface already provide a modular implementation that allows to plug multiple algorithm wrappers to perform the BCCSP operations. Currently, this modular approach cannot be fully exploited because methods are missing to allow this customisation.    This FAB proposes to refactor the software-based implementation to expose this additional customisation helper functions.  In the context of FAB-8930, this would allow to reuse the software-based BCCSP to implement a new BCCSP supporting the idemix options."
Answer: 141601.0

User story: "Currently there is no standardized mechanism to provide an interface definition for chaincode.  This is somewhat amazing given 20-30 years of recognizing the value of defining an interface.  Fabric should provide a mechanism to allow chaincode developers to define the interface to their chaincode and that interface definition should be provided at deployment time.  As well it should be possible to query the chaincode to determine its interface."
Answer: 937718.0

User story: "The chaincode package is currently initialized via side-effect with factories being passed by init functions and singletons, plus many stateful package scoped functions.  All of this should be cleaned up."
Answer: 937781.0

User story: "I think it will be better to check the legality of a channel name when creating the configuration via _configtxgen.sh_. Because it is too late to check it when creating a new channel with this configuration containing an unlegal channel name. "
Answer: 144227.0

User story: "There is no version option in the query api. This needs to be removed."
Answer: 9763.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "In the current implementation, the chaincode life-cycle related events are synchronized and when a condition 'installed AND deployed' becomes true for a tuple <channel, chaincode>, the event is passed on to the handlers that want to do some processing for the tuple <channel, chaincode>.    Two such handlers currently in use are - 1) handler for creating indices for couchdb and 2) handler for updating the service discovery metadata.    However, they differ in the need slightly. The first handler in the list above, prefers to receive the events before the state is committed because otherwise, there may be a peer crash immediately after commit (before handler gets invoked) and this will not give the handler a chance to create the indices. On the other hand, the second handler in the above list, wants to receive the events when the state is committed so that the information is published in discovery only after the commit.         In order to accommodate both the above cases, enhance the chaincode event listener such the listener receives a call back after the commit (for deploy trans) or install (cc install)."
Answer: 5497.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: "[~<USER> Can you confirm this is correct?    [https://github.com/hyperledger/fabric/tree/master/docs/README.md]         1. Remove the setup steps which refer to creating our own staging repo as this is no longer recommended.         There are two possible setups you can use to do so: setting up your own staging repo and publication website, or building the docs on your machine. The following sections cover both options:  h3. [|https://github.com/hyperledger/fabric/tree/master/docs#setting-up-your-own-staging-repo-and-publication-website]Setting up your own staging repo and publication website    You can easily build your own staging repo following these steps:   # Fork [fabric on github|https://github.com/hyperledger/fabric]   # From your fork, go to {{settings}} in the upper right portion of the screen,   # click {{Integration & services}},   # click {{Add service}} dropdown,   # and scroll down to ReadTheDocs.   # Next, go to [http://readthedocs.org|http://readthedocs.org/] and sign up for an account. One of the first prompts will offer to link to github. Elect this then,   # click import a project,   # navigate through the options to your fork (e.g. yourgithubid/fabric),   # it will ask for a name for this project. Choose something intuitive. Your name will preface the URL and you may want to append {{-fabric}} to ensure that you can distinguish between this and other docs that you need to create for other projects. So for example: {{yourgithubid-fabric.readthedocs.io/en/latest}}    Now anytime you modify or add documentation content to your fork, this URL will automatically get updated with your changes!              2.In order to get the following command to work on our macs:    {{sudo pip install Sphinx}}    Both joe and I had to first run:    sudo pip install six --ignore-installed six  sudo pip install pyparsing --ignore-installed pyparsing         Do we need to mention this in the instructions?    Do we need to mention that you might have to upgrade your version of pip for these commands to run?     "
Answer: 923268.0

User story: "Currently Jenkins build for {{fabric-chaincode-java}} configured to read JoCoCo report files from {{$WORKSPACE/shim/build/reports/tests/test}}, while since recent change the new path should be {{$WORKSPACE/fabric-chaincode-shim/build/reports/tests/test}}.    There is a need to updated Jenkins job properties for new path to stop it from failing."
Answer: 519.0

User story: "On [here|[https://github.com/hyperledger/fabric/blob/release-1.1/README.md#documentation-getting-started-and-developer-guides],]    'release branch (typically the latest patch for the current release)' has a typo. That page does not exist. [http://hyperledger-fabric.readthedocs.io/en/release/]."
Answer: 11168.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: "For administrative operations, such as install chaincode and join channel, no channel is yet available to perform a channel-specific discovery. By adding the ability to query for peers on an  empty channel, it makes it possible for an org to discover its own peers in order to perform such administrative operations and not requiring modification of config files.  "
Answer: 12465.0

User story: "Fabric Release - 1.0.6    Hyperledger Fabric provided Couch DB image is build in a way that it executes the ENTRYPOINT as root user and then it drops the privileges to username:groupname (couchdb:couchdb) to run CMD. couchdb:couchdb is created as part of the dockerfile and this maps (almost always) to an host UID:GID (1000:999).    Couch db process running inside the container are run as 1000:999 and this causes all its data persistence files to be created on the host mounted volume by that UID:GID identity.    Now - in our LDAP infrastructure, 1000:999 is already mapped to some user and hence this becomes a security issueo.    These are suggestion that can be explored -   * By refactoring the couch db dockerfile so that it can seamlessly allow uses of `--user` option to be used during `docker run`. This is on the same line where hyperledger peer or orderer can be run using non-root user.    This was the security finding on this subject  {code:java}  Typically, the user ID of a process running within a Docker container is the same as if it were outside the container. Should one of these processes be able to break out of the container onto the host, it would be running as the root user and would have complete control over the host.{code}   * Enhance the hyperledger fabric couch db image such that it supports accepting UID:GID as a docker environment variable. This will allow passing the preferred host UID:GID rather currently assigned 1000:999.   There is similar patch added to apache maintained couchdb dockerfile for similar reason via [https://github.com/apache/couchdb-docker/issues/53]     "
Answer: 509260.0

User story: "Fabric-Release 1.0.6    Hyperledger Fabric Peer Docker Image can be run as a non-root user. However the chaincode container created by non-root running peer container is with root privileges.    This is logged as a security finding:  {code:java}  Typically, the user ID of a process running within a Docker container is the same as if it were outside the container. Should one of these processes be able to break out of the container onto the host, it would be running as the root user and would have complete control over the host.{code}"
Answer: 489632.0

User story: We need to add or modify one of the smoke tests to use the explicit steps in the behave framework instead of the "setup" or "deploy" steps that takes care of multiple fabric steps in 2 behave test steps. This will help to ensure that our test steps don't miss a fabric step during execution.
Answer: 15944.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: "While the peer does indeed require the ccenv docker image to run, it does not require it to build.  We should therefore finally fix this."
Answer: 3998.0

User story: "In the Documentation Readme located here:    [https://github.com/hyperledger/fabric/tree/master/docs]    the steps for building locally have changed (per Ramesh)         Change the steps from    {{sudo pip install Sphinx }}    {{sudo pip install sphinx_rtd_theme }}    {{cd fabric/docs # Be in this directory. Makefile sits there. }}    {{make html }}         {{to }}    {{sudo pip install Sphinx }}    {{sudo pip install sphinx_rtd_theme }}    {{sudo pip install recommonmark==0.4.0}}    {{cd fabric/docs # Be in this directory. Makefile sits there. }}    make html    {{}}{{}}"
Answer: 1707.0

User story: "Today, each package declares a package scoped logger, rather than accepting a logger as a dependency which is injected.    Not only does this make doing things like testing tricky for verifying log messages for instance, it requires that every log message re-implement certain function.    For much of the logging, the log messages have a channel context, so each log message ends up starting with a format string like {{[channel %s]}}, but, sometimes the implementer forgets to add the channel scope, or sometimes the context only needs to be aware of the channel name for the logging messages.  All of this can be fixed if the logger is injected which does the channel context automatically."
Answer: 948012.0

User story: "Counterfeiter and mockery are being used for automatic generation of fakes and mocks. Having these tools available enables developers to use `go generate` to regenerate up to date mocks after changing interfaces."
Answer: 8923.0

User story: "Rather than cram so much into the top-level .gitignore file, it should be properly spread around the subdirectories, as it is for the fabric-ca/ and balance-transfer/typescript/ subdirectories."
Answer: 2300.0

User story: "I notice that both scripts byfn.sh and eyfn.sh assign a normalized value to the variable OS_ARCH, but neither of them ever ends up using it. In fact, those appear to be the only two references to that particular variable in the entire fabric-samples checkout. Thoughts?"
Answer: 614896.0

User story: The byfn.sh script continues to support the "-m <mode>" option, despite admitting that it's only for historical purposes ("muscle memory is powerful"). However, given that "byfn.sh --help" doesn't even mention that option, it seems pointless to continue to support it. It should just be tossed.    In addition, tighten up and update the usage message; make sure it matches the actual script.
Answer: 28418.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 cauthdsl {{policyparser.go}} provides a human readable language for specifying policy strings.    It supports syntax like {{OR('Org1.member', 'Org2.admin')}}, but per the proto specification a perfectly legal policy string would also be {{'Org1.member'}}.  Simply doing {{OR('Org1.member')}} works around the problem, but it's a bit unintuitive.  It would be nice to enhance the code to handle this case."
Answer: 949177.0

User story: "Tutorials section describes the first two tutorials (Building Your First Network, Writing Your Fist Application) in the reverse order of how they show up, so just swap the first two entries in the toctree in that section."
Answer: 65019.0

User story: "` Performance driver (there is caliper and PTE to consider)    Measuring performance         [~<USER>"
Answer: 936070.0

User story: "Tutorial describing how to remove a peer from the network -         [~<USER>"
Answer: 155417.0

User story: "Add a new tutorial describing how to use cello    [~<USER>"
Answer: 155419.0

User story: "Add a new tutorial describing using of Side DB and Collections"
Answer: 109313.0

User story: "Add a new tutorial describing Fabric usage with CouchDB"
Answer: 111124.0

User story: "Tutorials BYFN and Add an org to channel are quite long (but useful!). But it is easy for the user to loose track of what he is actually doing since to tutorials go on for so long.         I think it would be beneficial for these tutorials to provide a roadmap or summarize the list of steps before the step-by-step instructions so the user does not loose the context of what they are doing.     "
Answer: 155558.0

User story: "The echo of the environment before each command in BYFN is more noise than is of value. Should make this debug output."
Answer: 27562.0

User story: From the top level, even "make clean-all" doesn't clean the generated doc files, which seems like a minor oversight.
Answer: 1451.0

User story: The current check_license.sh script does not properly escape periods in filenames when building a list for exclusion, so that a filename pattern of ".go$" could conceivably match a filename of "fubargo". It's unlikely that this will cause a serious problem, but it's just easier to do the right thing and properly escape periods; as in, "\.go$".
Answer: 1635.0

User story: "Changes to Gerrit changes.rst file include:   * correct subject line length to 55 characters   * grammar/wording issues"
Answer: 2463.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: If I have a clean checkout, then running "make license" gives me what appears to be correct output:    *$ make license*  *The following files are missing SPDX-License-Identifier headers:*  *peer/node/start_test.go*    *Please replace the Apache license header comment text with:*  *SPDX-License-Identifier: Apache-2.0*    *Checking committed files for traditional Apache License headers ...*  *All remaining files have Apache 2.0 headers*    However, if I edit, say, docker-env.mk, and remove the old-style license info and rerun that command, I get:    *$ make license*  *The following files are missing SPDX-License-Identifier headers:*  *docker-env.mk*    *Please replace the Apache license header comment text with:*  *SPDX-License-Identifier: Apache-2.0*    *Checking committed files for traditional Apache License headers ...*  *The following files are missing traditional Apache 2.0 headers:*  *docker-env.mk*  *Fatal Error - All files must have a license header*  *make: *** [Makefile:144: license] Error 1*    Note how there is suddenly no mention of the earlier reported file, peer/node/start_test.go, which is because having a locally-edited file in your working directory restricts the value of CHECK in the check_license.sh script to only the locally-edited files. Is that what it's supposed to do? That seems non-intuitive.     
Answer: 952658.0

User story: """make license"" reports:    *The following files are missing SPDX-License-Identifier headers:*  *gotools/Makefile*    *Please replace the Apache license header comment text with:*  *SPDX-License-Identifier: Apache-2.0*     "
Answer: 69435.0

User story: "Git is particularly squawky about unnecessary trailing whitespace in text files, so remove the few examples of that in the docs/source/*.rst files."
Answer: 1672.0

User story: "In a Linux checkout, all text files should have proper EOL characters."
Answer: 2823.0

User story: BYFN could use a thorough edit to make things clearer.    Some things to consider:   * Would a roadmap at the top of the step-by-step instructions to summarize the steps be helpful to keep people oriented as they go through the instructions?    - Comment from the HyperLedger Fabric e-mail ==>    BYFN  - I am a little confused about the meaning of an  "end-to-end" application? in ==>       _"This will launch all of the containers, and then drive a complete_       _*end-to-end** application* scenario."_            Is it has the same meaning of "e2e" in the file name of docker-compose-e2e.           yaml?       If so,  it shouldn't be an e2e application since it started a *cli*       container:    Answer from Chris: end-to-end (hence the e2e) is a hold-over term. basically, we had the e2e scenario in the fabric repo as a test that covered the entire lifecycle of deploying a network, deploying a trivial application (chaincode) and driving a few transactions before tearing it down. We still use this today. We turned it into a tutorial and it has grown arms and legs.     
Answer: 941907.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 fabric logo to the doc "splash page" and margin.
Answer: 1907.0

User story: In gotools/Makefile, a number of variables are set for the default acquisition of a number of gotools:    *go.fqp.dep := github.com/golang/dep/cmd/dep*  *go.fqp.golint := github.com/golang/lint/golint*  *go.fqp.goimports := golang.org/x/tools/cmd/goimports*  *go.fqp.gocov := github.com/axw/gocov/...*  *go.fqp.misspell := github.com/client9/misspell/cmd/misspell*  *go.fqp.gocov-xml:= github.com/AlekSi/gocov-xml*    for the following rule:    *gotool.%:*    *$(eval TOOL = $\{subst gotool.,,$\{@}})*    *@echo "Building $\{go.fqp.$\{TOOL}} -> $(TOOL)"*    *@GOPATH=$(abspath $(TMP_GOPATH)) go get $\{go.fqp.$\{TOOL}}*    However, there is no need to set "go.fqp.dep" as that tool is processed explicitly by an earlier "gotool.dep:" rule and therefore doesn't invoke that default target, so setting "go.fqp.dep" would seem to be superfluous, no?    I realize it's not doing any harm, but I see no value in hanging onto unnecessary content. Thoughts?     
Answer: 71024.0

User story: "User would like to have more detailed documentation on how to perform the following:        # How to judge on what basis a consortium would be created?   # How to judge on what basis an orderer organization should be created?   # What parameters needs to be kept in mind when hosting an Orderer organization? [Trust issues, although an orderer does not see data, but there is no bound that a malicious orderer cannot]   # What is the default set of mod_policies in an configuration transaction and how to change them?   # How to create custom certificates without cryptogen and which ones to distribute and what should be the best practice while doing so?               "
Answer: 955669.0

User story: "Continue to integrate FAQs from Stack Overflow and the Mailing List into these two docs:    Fabric FAQ: [http://hyperledger-fabric.readthedocs.io/en/release-1.1/Fabric-FAQ.html]    Orderer FAQ: [http://hyperledger-fabric.readthedocs.io/en/release-1.1/ordering-service-faq.html]     "
Answer: 956516.0

User story: "I have encounter a very strange behavior of the orderer when domain name is *.local.    I try to setup a dev env with Kafka, and urls are :     orderer0.plasticbank.local    kafka0.plasticbank.local    kafka1.plasticbank.local    kafka2.plasticbank.local    kafka3.plasticbank.local    Orderer panics (see attached logs). If I change domain from *.local* to *.localhost* everything is working as expected.     I have necessary records in /etc/hosts    It may be OS or docker issue, but I am able to access urls ending with .local using grpc at this machine.    Fabric: 1.1 official images    Go: 1.9.2 linux/amd64    Docker: 18.03.0-ce, build 0520e24"
Answer: 956655.0

User story: "Acceptance:    I can execute the end-to-end tests using ginkgo."
Answer: 69097.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 will remove an extra step of updating a credential at the client side and will make refactoring to comply with the BCCSP interfaces simpler.    For credential issuance we do not need anonymity of the user with respect to the CA."
Answer: 20154.0

User story: "In the top-level Makefile, three of the platform-specific binaries (peer, orderer and configtxgen) are defined as PHONY targets, while the remaining two (configtxlator and cryptogen) aren't. They should all be defined consistently as PHONY, just for uniformity."
Answer: 72285.0

User story: The use of a trailing "||:" in several rules in the top-level Makefile is unnecessary, as it is just a hacky way of saying, "Even if this command fails, keep going," and is equivalent to the simpler and more obvious use of a hyphen prefix for the command. In addition, even the hyphen is unnecessary for most of those rules since they are all "rm -rf" commands which, by definition, cannot fail even if the arguments don't exist (although they can fail if permission is denied).
Answer: 72334.0

User story: It response empty secret value after successfully register and enroll, and the value of "enrollmentSecret" in persistence is also empty string. The fix allow user get the enrollment secret value and store it in local file.    After start the network, register and enroll new users in Organization :   {{curl -s -X POST [http://localhost:4000/users] -H "content-type: application/x-www-form-urlencoded" -d 'username=Jim&orgName=Org1'}}    the output (secret value is a empty string):    {{\{ "success": true, }}{{"secret": "", "message": "}}{{Jim enrolled Successfully", "token": "<put JSON Web Token here>" }}}     
Answer: 956968.0

User story: "The gotools directory only contains a Makefile. These recipes should be folded into the top-level Makefile and the gotools directory should be removed."
Answer: 9485.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: "http://hyperledger-fabric.readthedocs.io/en/latest/samples.html    Instructions for downloading the Samples contain this information:  git clone -b master https://github.com/hyperledger/fabric-samples.git  cd fabric-samples  git checkout \{TAG}  Note:    To ensure the samples are compatible with the version of Fabric binaries you download below, checkout the samples {{\{TAG}}} that matches your Fabric version, for example, v1.1.0. To see a list of all fabric-samples tags, use command “git tag”.    ------------------------------    Problem:    Both Nancy and I checked out the wrong version of the binaries (v1.0.0) and ended up following the Tutorial instructions in the doc for v1.1.0. This creates problems - most notably that Node.js chaincode was not supported in v1.0.0. So if you try to follow the v1.1.0 instructions for deploying  node.js chaincode it will fail.    Action:    It would be good to give more guidance (warning?) here about what to specify for the TAG value.  I would even suggest   # putting the Note: text before  the git checkout \{TAG} instruction   # warn them, if they want to use node.js chaincode they will need v1.1.0 or higher."
Answer: 16641.0

User story: "Given the explicit usage of the GOPATH variable in some of the Fabric support scripts, it should be strongly emphasized in the documentation that that environment variable needs to be set in a very specific way:   * It _must_ be set and exported, even if one is using Go's default directory of ~/go, and   * It can contain only a _single_ directory, not the more general, colon-separated list of directories.    Short of refactoring the support scripts, the simplest solution is to add a warning about this in the documentation."
Answer: 5664.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: "* *Endorsement:* Use the new proto message (FAB-9204) for persisting the pvtwriteset into transient store and gossip push. Include height _H_ into this proto message where H=Max(last collection config, last channel config)  **   * *Serving gossip pull from the committed storage*: When serving a gossip pull request for a data committed at height h from the committed data, evaluate the following two conditions and serves the data if either of these conditions is true.    condition1: A config is committed at height x such that   `(x > h) && (collectionConfig contains requestingOrg) && (requestingOrg has fullAccess)`    condition2: A config is committed at height x such that   `(x = latest height less than h) && (collectionConfig contains requestingOrg)`    Note that in the case of condition1, the corresponding channel config that is used for evaluating the condition should be the most recent channel config committed before height `x`. However, in the case of condition2, the corresponding channel config that is used is the most recent channel config before `h`. For retrieving configs by height - see FAB-9203   * *Serving gossip pull from the transient store*: When serving a request for the pvt data from the transient store  - gossip pulls out the data from the transient store   - Evaluates whether the ledger height at the peer is greater than or equals to the height `H` specified in the proto message      - If `ledger height < height specified in the proto message`; return error      - else fetch the most recent collection config and channel config below (or at height) `H` and evaluate the eligibility of the requester     "
Answer: 79142.0

User story: It would be helpful to have the build emit a list of docker images that it has/would generate for integration with things like "docker push" in a CI flow.
Answer: 6653.0

User story: "I fell victim to the illegal character in Channel ID because of my use of an upper case letter in the channel ID as I set about creating a channel.    Someone was kind enough to point me in the direction of the code which stated that only this pattern /^[a-z][a-z0-9.-]*$/ is permitted for the channel ID.    May I suggest that this information be included in the tutorial docs so as to help everyone - and especially greenhorns to Fabric - avoid making similar mistake I and many others have made when attempting to create a channel ID with a name that doesn't match the desired pattern."
Answer: 123522.0

User story: Would be convenient to utilize the build-systems knowledge of docker image/tags to implement a "docker push" operation. Suggest "make docker-push".
Answer: 35504.0

User story: These are needed for unit-testing, etc, but not a basic build.  "make docker" should do the minimal amount of work to build the images.
Answer: 17564.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: Running "make linkcheck" generates numerous "redirect" diagnostics, almost all of which are simply translations from "http://" to "https://", so might as well make those changes in the .rst files to remove all that clutter from the output.    There are still other link issues, such as broken links, but that's for another patch – this patch is strictly for basic redirect warnings.
Answer: 1753.0

User story: Since initialization status cannot be managed in the LSCC table (because of the likely mismatch between the LSCC validation and chaincode validation requirements), the chaincode initialization status needs to be stored with the other chaincode data and validated according to the chaincode validation parameters.    However, because there is no namespacing within a chaincode keyspace, attempting to story the initialization status within the standard chaincode namespace could cause collisions with existing user chaincodes.    Therefore, we need a namespace tied to the existing chaincode namespace which can store whether a chaincode has been initialized or not.  This namespace could at some point be made available through the chaincode interface, but for the time being, the endorser code can manipulate it directly.  A suggested name for this namespace could be the "chaincode system namespace".     The implementation is intentionally left vague, but the `endorser.go` code will need to be able to read from this namespace, and add a write to it into the RW set of the transaction.    At commit time, the standard validation code should operate over this RW set to determine that it was generated correctly.  For standard endorser txes this should require no additional code, as the standard endorsement policy may verify the initialization writes as is.
Answer: 498297.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 go race detector can be used to detect unserialized access to data that may result in non-deterministic execution of a program.    As a developer, I want to have the race detector enabled during unit-test execution to ensure that I'm able to evaluate and fix serialization bugs before they are integrated."
Answer: 384770.0

User story: "With current master (8d67d599933b7455a034c089f672ca98d45d4d11), the race detector enabled flagged a number of issues. Each of these issues needs to be evaluated and fixed to help ensure serialization bugs do not present themselves in production environments."
Answer: 145546.0

User story: A number of doc files use the phrase "key/value pairs", whereas the consensus on the mailing list is that the correct expression is "key-value pairs".
Answer: 40.0

User story: "Editing changes include:   * Remove erroneous indentation   * Adjust punctuation   * De-capitalize non-proper names   * Other grammar and wording adjustments"
Answer: 46.0

User story: In samples.rst, the text refers to "four" downloaded binaries, but the subsequent list shows six, so just fix the number, and add a couple of commas for consistency.
Answer: 50.0

User story: Some editing of fabric_model.rst for grammar and clarity, and to standardize on the accepted spelling of "key-value", not "key value".
Answer: 8500.0

User story: Standardize on the accepted spelling of "chaincode", not "chain code", in docs, comments and printed strings within Go code.
Answer: 11465.0

User story: "Fill out the list of references to all five official and unofficial Fabric SDKs."
Answer: 121659.0

User story: "Clean up lf-account.rst with respect to grammar, spelling mistakes, brevity and so on."
Answer: 2916.0