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: "As currently we only have chain.queryBlockByNumber(), but sometimes we might need to go through all the block sequentially to check all data (e.g. build a data warehouse from the data), and query only one block at a time is too inefficient for that.    The alternate approach within chaincode GetStateByRange() does not work well for scanning all keys, since you would have to continuously re-scan to find key changes.  It would be better to be able to get blocks by block range and process all changes from the block transaction write sets.  For example get blocks 1-100, then 101-200, etc.    Would prefer a peer API than a chaincode API, since the query is not a contract.  This would imply a peer API and a corresponding SDK API."
Answer: 1419400.0

User story: add "how to propose a feature/enhancement" to CONTRIBUTING.rst
Answer: 7507.0

User story: "In support of the [Hyperledger Security Bug Proposal|https://docs.google.com/document/d/1gne57E4XEAxETZh_pmyVVWyI7FgXkmD72U3HfG193D8/edit[]|https://docs.google.com/document/d/1gne57E4XEAxETZh_pmyVVWyI7FgXkmD72U3HfG193D8/edit], this task would implement the following as a non-critical path feature to the Fabric project's CI:    1) Establish a VM resource to build a security scanning instance [Anteater|https://github.com/lukehinds/anteater] to scan the existing code and new checkins for various security vulnerabilities.    2) If a vulnerability is identified, notify the owner(s) in a manner that will allow the matter to be resolved and to minimize any unnecessary panic.          [Jonathan: adding [~<USER>]"
Answer: 371164.0

User story: "Per testplan [https://docs.google.com/spreadsheets/d/1_IdXCuYMKkqXr3Za0pVnFP3sP1jBcNbYnTJGV-nSkxI/edit#gid=442991954]   using new end-user-friendly behave test APIs in the .../fabric/test/ folder,  write the Peer Functional Tests that can be written using Behave tooling.    These tests will include chaincode and channel interaction testing.    Create new jira issues for each test or test group."
Answer: 610720.0

User story: "We have to create templates of the tests that will be executed using the behave framework. The Scenario name should look as follows:       {code:java}  Scenario: FAB-XXXX - <Description of the Test Scenario>      Given some setup      When some state changes      Then some action is expected  {code}  Each scenario should be tagged with the @skip tag. This tag will be removed once the test is written and ready for use.     "
Answer: 10403.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 error handling framework currently relies on every file importing the error handling package (fabric/common/errors) and making a call similar to:  {code:java}  errors.ErrorWithCallstack(errors.ChaincodeSupport, errors.BadRequest, "chaincode name not set"){code}  Certain packages may wish to wrap this call into their own utility function but not have this utility function displayed in every error callstack.          To accommodate this usage, the error handling framework should provide a parameter to adjust the starting point of the callstack.     For example, the following usage would shift the stack down two lines:  {code:java}  errors.ErrorWithShiftedCallstack(2, errors.ChaincodeSupport, errors.BadRequest, "chaincode name not set"){code}
Answer: 149703.0

User story: "In order to support hyperledger in a production environment, especially when hosting many networks for other users, we need a way to easily tell if an orderer is healthy or not.  Simply checking if the process is running isn't enough, and looking at the logs is great for debugging a single network, but doesn't scale when trying to support many networks in a production environment.    A simple, low impact, CLI or grpc call that verified that returned status indicating whether or not an orderer was healthy, or a simple check we could do on a network we were hosting for other users (so didn't require us to submit transactions) would suffice.          "
Answer: 1420848.0

User story: "A minor patch for consistency's sake (we're currently adding printout to some stages only) and for helping with debugging."
Answer: 2548.0

User story: "I often see questions in Rocket.Chat and on the mailing list from folks who want to run the E2E tests using Kafka.    How do we handle this? Do we modify the default configuration so that it runs on Kafka? Do we introduce yet another configuration for the tests?    The fix is simple, see [https://github.com/<USER>fabric/commit/7f83f40fdd8c5cd0a837a820f728f3b864e1cce2] for an example."
Answer: 119291.0

User story: "--- matrix    --- docker-compose config ino         --- template (cut an paste"
Answer: 224933.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 default chain "testchainid" is defined in common/util.    Other components should retrieve the value using the method, instead of hard-coded.
Answer: 204634.0

User story: "This file was written a long time ago, and needs to be updated to reflect the current status of the ordering service component."
Answer: 1258.0

User story: "Create a daily test task for the CI with the proposed performance measurement tool for the Ledger Component. ([https://gerrit.hyperledger.org/r/#/c/6793/)] . The test tool needs to be in the /test/tools/ folder, the test driver needs to conform to the test framework guidelines ([https://gerrit.hyperledger.org/r/#/c/8989/3)] and reside in the /daily folder. The CI wil pick the test and run from there.   * +Component+:  Ledger   * +Artifact Locations+:  {{fabric/test/tools/ledgerbenchmarks}}   * +Network Topology+: Not Applicable, as it tests the component only   * +Input+:  To run all tests, go to directory:    {{/fabric/test/regression/daily}}   run:    {{py.test -v --junitxml results.xml ./test_ledger_benchmark.py}}"
Answer: 226260.0

User story: "Over time, the cache of chaincode info grows as the number of instantiated (and subsequently upgraded) chaincodes grows. We need a mechanism to remove items from this cache."
Answer: 725893.0

User story: "Here is documentation that describes how to install,setup,configure, debug/run  the marbles example code in eclipse and set breakpoints to inspect the code and variables in the eclipse IDE.    The document is in .rst format at the moment.     [^GODebugging.rtf]    ^[~<USER>  I forgot details about the proper format and where to stick the documentation.   Ping me if you could so we can do a quick review.  Thanks,^"
Answer: 1424053.0

User story: "We need to explain the different options available in core.yaml and orderer.yaml and how these variables translate to docker-compose scripts."
Answer: 1405538.0

User story: "Add new command  {code:java}  peer chaincode list --installed{code}  to get all the chaincodes installed on the connected peer.    If specify channel with  {code:java}  peer chaincode list --instantiated -C <channel Id>  {code}  ，   get all the instantiated chaincodes on the specified channel."
Answer: 181029.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: "*Premise:*  For developers using Fabric or any other tools/systems, eg Composer they really get benefits testing their applications/scenarios using as real a backend system as possible.   Both functional and non-function behaviours are important.     The great power of Fabric comes at the price of having many configuration options to start a specific set of peers, ca etc. But for developers they would like to have a small set of good practice setups they can start/stop/teardown.    This means that in development/test phases they can focus on their application/scenario - and in production, they can call upon admins or other online services to actually run correct Fabric setup.          *Scripts:*    As part of the Composer project, we wanted to give a developer a simple place to start with a Fabric instance. Therefore we took some of the Fabric system tests scripts and put them together in an easy to consume manner.     The current culmination of these in the repo.. [https://github.com/<USER>fabric-dev-servers]    At present these are focused around the node.js centric world of the Composer developer.    However they are not specific to Composer - but they do use node and npm to control the scripting. (as well as BASH).         *Requirements:*    The aim is to have a setup of very simple *start, stop, teardown, download* scripts that a developer can call. They should know the absolute minimum of Fabric configuration. Defaults should be assumed for everything.  At present, the only choice is 0.6 or 1.0 with 1.0 being the default.     As a developer becomes more confident or knowledgeable in Fabric they can take the scripts and modify them if they wish. However, this job would ideally be the job of a Fabric Admin Role.   Not all app devs will want/wish to be Fabric admins.           "
Answer: 615454.0

User story: "Now we have ``peer chaincode upgrade`` command. Should add e2e_cli test for relevant patchsets."
Answer: 1425210.0

User story: "{{honnef.co/go/tools/cmd/unused}} found unused vars etc in ./orderer/...  orderer/kafka/config_test.go:41:5: var testGenesisConf is unused (U1000)  orderer/kafka/orderer_test.go:39:6: func newMockSharedConfigManager is unused (U1000)  orderer/kafka/orderer_test.go:46:2: field consumerSetUp is unused (U1000)  orderer/ledger/json/impl.go:53:2: field fqFormatString is unused (U1000)  orderer/multichain/manager_test.go:66:6: func mockCryptoRejector is unused (U1000)  orderer/multichain/manager_test.go:70:6: type mockCryptoRejectorHelper is unused (U1000)  orderer/multichain/util_test.go:77:6: type mockLedgerWriter is unused (U1000)  orderer/multichain/util_test.go:150:6: func makeSignaturelessTx is unused (U1000)  orderer/network_test.go:55:6: type flags is unused (U1000)  orderer/network_test.go:69:2: field config is unused (U1000)  orderer/sbft/simplebft/request.go:66:16: func (*SBFT).batchSize is unused (U1000)  orderer/sbft/simplebft/testsys_test.go:302:6: func newTestSystemWOTimers is unused (U1000)"
Answer: 33655.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 CONTRIBUTING.md to root link to CONTRIBUTING.rst in docs"
Answer: 967.0

User story: "fabric-ca has a crude license checking script, we should add to all projects."
Answer: 481395.0

User story: "Because we are using protobufs for block structure, Blockholder is not turning out to be relevant  as expected earlier assuming a custom serialization. Better to remove this in order to avoid confusion."
Answer: 9672.0

User story: "raise awareness of Fabric dashboard/front door"
Answer: 27222.0

User story: h3. All Questions & very few Answers    h4. Hyperledger-Fabric Policy:  {code}    What does one mean by "policy" in Hyperledger-Fabric?           "At its most basic level, a policy is a function which accepts as input a set of signed data and evaluates successfully, or returns an error because some aspect of the signed data did not satisfy the policy.  More concretely, policies test whether the signer or signers of some data meet some condition required for those signatures to be considered ‘valid’. This is useful for determining that the correct parties have agreed to a transaction, or change." - doc link below    Few policies I heard about:                * Channel Configuration                * Signature                 * Implicit Meta                * Endorsement.  Understand how these various policies opearate? If they all fall in the same category? How does an endorsement policy differ from Signature policy say?    Explore what other kind of policies Fabric 1.0 support?    How can rules be defined and enforced around policies?  What tools currently support creating and modifying these policies?    Can we have dynamic user defined policies?   Is there a language to define these policies and rules?  {code}    h4. ACL  {code}  What are "Access Control List (ACL)"?  How do you associate users and corresponding ACL?    It appears current cryptogen tool does not have the capability to support ACL.  How can we achieve defining ACL in Fabric?  How does ACL relate to these multiple policies?  What exists in default ACL during Channel Creation policy and how is it enforced?  {code}    h3. Next Steps To Do:    {code}  * Gather input and ideas from development/test on policies and ACL in Hyperledger-Fabric?  * Can we test each of the policies listed above?  * Document possible tests around policies and ACL.  * Automate tests using basic (highly used) policies and verifying their validity.  * Understand if CLI testing equipped for this?  * Can we leverage behave framework o write automated tests?  * What capability does Node SDK offer around this?  * Work with documentation enhancements if necessary.    {code}    h3. References:  http://hyperledger-fabric.readthedocs.io/en/latest/policies.html
Answer: 620871.0

User story: "There is an error left unchecked, add an error check here can prevent potential obscure."
Answer: 50134.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 tests that invoke the following Java chain code stub methods:  * getStateByRange()  * getStateByPartialCompositeKey()  * getQueryResult()  * getHistoryForKey()"
Answer: 1430894.0

User story: "Improve unit test coverage for common/configtx/tool/configtxgen.   "
Answer: 42022.0

User story: "Improve coverage for the following packages:  github.com/hyperledger/fabric/orderer  github.com/hyperledger/fabric/orderer/ledger/ram  github.com/hyperledger/fabric/orderer/multichain  github.com/hyperledger/fabric/orderer/mocks/blockcutter  github.com/hyperledger/fabric/orderer/ledger/json  github.com/hyperledger/fabric/orderer/mocks/multichain  github.com/hyperledger/fabric/orderer/common/deliver  github.com/hyperledger/fabric/orderer/common/broadcast  github.com/hyperledger/fabric/orderer/localconfig  github.com/hyperledger/fabric/orderer/ledger/file  github.com/hyperledger/fabric/common/mocks/configvalues/channel/orderer  github.com/hyperledger/fabric/orderer/configupdate  github.com/hyperledger/fabric/orderer/ledger  github.com/hyperledger/fabric/orderer/solo  github.com/hyperledger/fabric/orderer/common/configtxfilter  github.com/hyperledger/fabric/orderer/common/filter  github.com/hyperledger/fabric/orderer/common/blockcutter  github.com/hyperledger/fabric/orderer/common/bootstrap/file  github.com/hyperledger/fabric/orderer/common/sigfilter  github.com/hyperledger/fabric/orderer/common/sizefilter  github.com/hyperledger/fabric/orderer/kafka"
Answer: 149080.0

User story: "Currently, access control is scoped by organization at the channel level. This means that clients / peers are interchangeable in many cases.    The desire here is to limit the scope of what clients who transact can actually do.   Examples include:    1) Request endorsements and query chaincode   2) Submit transactions to the orderer   3) No access to gossip network   4) No access to blocks only to their transactions   5) Related to 4 - events payload should be limited to transaction IDs if that is what is used to asynchronously learn the status of their transaction         The original intent was to introduce the concept of client orgs    A design doc is at https://docs.google.com/document/d/1oaR7IlpNCV6udvLhDootRtoruEvOrxByYVN4BQ___0A"
Answer: 445249.0

User story: "Now we only enable the goimports and go vet checking.    The following change should be done:    * Enable `go fmt` check on the main part of code."
Answer: 264062.0

User story: "Utilize component/subcomponent loggers as described here:  http://hyperledger-fabric.readthedocs.io/en/latest/commands/peerlogging.html?#set-level-usage"
Answer: 889518.0

User story: "Add unit test instructions to docs    - Add make unit-test info  - Add test coverage info"
Answer: 2308.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 NetworkLauncher (to be submitted with FAB-3475) and other test tools that spin up a network, we need scripts for generating the crypto-config.yaml and the configtx.yaml. The tester will provide user paramters such as #orderers, #orgs, #peersPerOrg, to the test tool (such as NetworkLauncher) which needs to generate these configuration scripts before running the configtxgen and the cryptogen tools and finally launching the test network."
Answer: 171363.0

User story: "It would be nice to have a CI slave node running fabric tests in   * RedHat (7.x)  * SUSE  * CentOS  * Debian  * ...     We can then say, as an aside, what version(s) of OS we have executed fabric against. This does not mean that we need to support these environments, but that we know or at least have some idea of what happens when we run in these environments."
Answer: 1178455.0

User story: "We need a system integration test driver to exercise different facets of integration, performance, and scalability.    https://gerrit.hyperledger.org/r/#/c/9261/"
Answer: 33427.0

User story: "Improve unit test coverage for common/configtx/tool/provisional. "
Answer: 15426.0

User story: "The bccsp packages needs to be updated to use the fabric error handling framework. It will be used only at the border of the bccsp infrastructure."
Answer: 243050.0

User story: "In the ledger code - fabric/core/ledger/kvledger/txmgmt/validator/statebasedval/state_based_validator.go refers to CONFIG transactions. Though, it does not do anything with these transactions.    Since, ledger validation should be limited to mvcc validation and hence be restricted to ENDORSER transactions. Remove the check for CONFIG transactions."
Answer: 2744.0

User story: "CouchDB password is currently stored in plaintext on the peer. It needs to be encrypted. The plaintext password will not pass our security audit."
Answer: 1434699.0

User story: "Per testplan https://docs.google.com/spreadsheets/d/1_IdXCuYMKkqXr3Za0pVnFP3sP1jBcNbYnTJGV-nSkxI/edit#gid=442991954   which is derived from FAB-972 (which has some detailed test steps to use),  write the Orderer Functional Tests that can be written using OTE tool."
Answer: 629054.0

User story: "Per testplan https://docs.google.com/spreadsheets/d/1_IdXCuYMKkqXr3Za0pVnFP3sP1jBcNbYnTJGV-nSkxI/edit#gid=442991954   which is derived from FAB-972 (which has some detailed test steps to use),  using new end-user-friendly behave test APIs in the .../fabric/test/ folder,  write the Orderer Functional Tests that can be written using Behave tooling.  Create new jira issues for each test or test group."
Answer: 629074.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 story has tests we are going to run from "test/regression/daily/chaincodetests" using chaincodes in fabric/examples/chaincode/go folder        * +Component+:  endorser/peer   * +Description+:  to build tests and verify example chaincodes in fabric in our daily runs.   * +Artifact Locations+:  test/regression/daily/chaincodetests/fabricFeatureChaincodes   * +Network Topology+:  4 peer solo, TLS enabled docker-network   * +Client Driver+: CLI shell scripts wrapped in Python.
Answer: 624611.0

User story: The documentation is now published on readthedocs and involves a build process which is not currently documented anywhere. This makes it difficult for anyone new to the project to contribute without "bugging" one of the few people in the know.  Furthermore the documentation relies on several principles that one should know about so that any change to the doc is made in a consistent manner. These principles also ought to be documented somewhere.  
Answer: 872.0

User story: "Write the v1Launcher tool. This tool takes parameters on command line to specify things like #peers, #orgs, #ordererers, #channels, etc, and launches a network."
Answer: 178492.0

User story: "In order to improve the test coverage of the bccsp/sw package, the following tasks are designed.    1. Replaces the switches with maps whose keys are opts types and values are interfaces representing key generation, key derivation, encryption and so on..  The reason for this is that it would allow the ability to test the single functionality (keygen, keyderiv, ...) in isolation and simplify testing of the bccsp implementation.    2. Add tests for the each component.    Actually, this two tasks can be run in parallel and a change-set can be submit for each bccsp method."
Answer: 17135.0

User story: "This will be achieved in two steps:  1. refactoring the package to remove subfolders and introduce a mocks folder  2. improve test coverage"
Answer: 452349.0

User story: "Current log doc doesn't include following.    1. How to set default peer logging level for subcomponent in the docker-compose.yaml?  2. How to dynamically change the logging level for subcomponent?  3. How to check the current logging level?  4. how to revert the levels to the default (at the startup of peer)?"
Answer: 147324.0

User story: "In particular this FAB will focus on the test coverage of the following sub-packages:  - bccsp/  - bccsp/signer  - bccsp/sw  - bccsp/factory    Unit-tests and refactoring of the code will be introduced.  "
Answer: 29666.0

User story: "I've been working around hyperledger fabric for a while. I'm successful in install and form network of Fabric without using docker with 5 peers. Now I try to Setup Auditor and non-validationg peers within the network. I surf around ,but cannot find any clear document in this. Can anyone help?"
Answer: 52381.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: "Improve unit test coverage for ledger.    There will be a subtask per ledger package.  Developers can pick up any available package subtask to work on.  As each package is inspected, tests can also be refactored and ledger testutil assertions can be replaced with github.com/stretchr/testify/assert assertions.   Eventually we will be able to remove ledger testutil."
Answer: 628908.0

User story: "Need metrics from Fabric so users can monitor fabric metrics to be able to support the fabric in a production environment  and maintain a high SLA.    1 - Need to create a metrics component, similar to a logger, that allows a developer to easily publish a metric by including  a few lines in their code at the point an operation they want to publish a metric for occurs.  2 - This metrics component would publish any metrics to a statsd endpoint that was configured in core.yaml.  3 - Metrics we urgently want published are:   a - Endorsement Count   b - rejected endorsement count   c - validated transaction count   d - invalid transaction count   e - Block count   f - channel count per network          g - endorsement response time (including time spent in statedb, e.g. couchdb queries)        Other requests from Fabric solutions:    Provide basic information about deployed chain code on the chain, such as chain code ID, its deployed time, etc；For each chain code, with proper permission, provide invoke/query metrics data such as TPS, consensus latency(average, 50%, 85%), broken down into different chain code API (function)；Provide storage usage information on peer node. (@huangssh, Nov 16, 2016)  "
Answer: 838924.0

User story: Some cruft has been accumulated over time on the orderer-related Docker Compose configurations under the "bddtests" folder. This changeset:   # Removes environment variables that are either deprecated (e.g. `ORDERER_RAMLEDGER`) or not in use by the BDD tests (e.g. all `CONFIGTX` variables since `bootstrap.feature` does not use the `configtxgen` tool, or the `provisional` bootstrapper).   # Removes configurations that are either no longer relevant (e.g. `bdd-docker/docker-compose-4-consensus-batch-nosnapshotbuffer.yml`) or no longer in use.   # Moves all Docker Compose files to the `bddtests` folder and renames them to filenames that are hopefully a bit more expressive. Thanks to Jeff Garratt for guiding me through his.   # Modified the Kafka environment so that it uses the bare-minimum sensisble defaults, and added comments for the critical settings.
Answer: 45618.0

User story: "We need to make our examples/scripts work with production-level artifacts.    The fabric-testenv-orderer image is not an artifact targeted for production. This abundance of options leads to user confusion (I've had folks ask me whether they need to use `fabric-testenv-orderer` to make Kafka work), and it also means we have yet another image we need to maintain."
Answer: 22349.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "We may want to consider extending our e2e flow to check the following:    a) Installation of various versions of a chaincode (with instantiation policies - [~<USER> suggested)  b) Instantiation of chaincodes in various chains, attempts of instantiating twice on the same chain or more  c) Application chaincode querying another application chaincode on the same chain  d) Application chaincode invoking another application chaincode on the same chain  e) Application chaincode querying another application chainocde on a different chain  f) Application chaincode invoking a system chaincode (LSCC, QSCC, CSCC, ESCC, VSCC)      - on the same chain?      - on a separate chain?     - chainless functions of theirs?      - while considering invoking each function separately(?)  g) System chaincode invoking another system chaincode (?)  h) Installing chaincodes with same name but different metadata on different peers, and attempting to instantiate and invoke afterwards these chaincodes on each of the peer.   i) Configuration updates of multiple components on a chain   j) others? Inviting [~adc], [~<USER>, [~<USER>, [~<USER>, [~<USER>, [~<USER>, [~<USER>, [~<USER> to comment on these or more additions are needed here (?)  "
Answer: 1446035.0

User story: "i cann't invoke or query  because cann't fount orderer0:7050 join chainnel after    i have not orderer0 , i setting orderer name is orderer1      you can try modify e2e_cli about orderer0 word  all change to orderer1 or any word"
Answer: 1427207.0

User story: "As more people start using cryptogen, need to make sure the test coverage is increased"
Answer: 683.0

User story: "Chaincode images may become stale and may not match fabric runtime images. Cleaning of chaincode images will take care of this but for debugging and servicing, it is important to know if that is necessary.     Version information should be passed to the chaincode at the time of building it so the chaincode can log it."
Answer: 221.0

User story: "The current getting started is focused on using Docker Compose on a local machine or single remote node.  While this is great for testing and development of chaincode and applications, it does not mimic real world multi-host deployments.    Users would like to be able to quickly mimic a real world setup and have sample topologies, deployment scripts and documentation to create more realistic sandbox environments."
Answer: 1193272.0

User story: "Instantiation policies are supplied when a chaincode is installed. Currently we accept nil policies for backward compatibility but this should be removed"
Answer: 1448923.0

User story: """Advanced"" features not contained in v1.0"
Answer: 1169165.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 signatures are not needed in a deploy/upgrade tx, since for these two functions validation is performed using :   - creator certificate & creator signature   - invocation data (and to some extend validation of the simulated results by repeating parts of its)    Endorsement signatures are not needed here from a security perspective. They are simply used for convenience for the client to be able tor retrieve the instantiation policy of the chaincode to deploy without knowing it in advance.         "
Answer: 732732.0

User story: "Ultimate goal of two jira items FAB-2362 and FAB-3296  is to work towards the following :   - retrieve hashes used within the context of a chain (proposal, txid, binding, block) from chain genesis block (*done*)   - [subtask of FAB-3262] retrieve hashes used within a signature from a (hardcoded) MSP property (FAB-3293)   - [subtask of FAB-3296] retrieve chain-less operation hashes from local configuration of peers/orderers (FAB-3294) - post v1   - [subtask of FAB-3296] enable MSP crypto configuration be retrieved at peer setup time or channel genesis (FAB-3295) - post v1      Side change-sets needed are:   - Remove the usage of BCCSP default opts"
Answer: 1449201.0

User story: The default value in configtx.yaml for "Absolute Max Bytes", the size batches that the ordering service outputs, breaks the Docker Compose configuration files in "bddtests/environments". This changeset brings all configurations in sync.
Answer: 10491.0

User story: "Functional and behavior driven tests should be written based on the understanding of a fabric requirement (story) and not on the implementation of the requirement. This story will add this capability. These tests can then be executed to verify that the implementation was completed as expected.    When writing the underlying code behind the feature files, certain details of implementation should be understood and used, but this should not stop the initial setup of the tests.    This story should allow for the basic setup of functional and behavior tests for the fabric project."
Answer: 10159.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: CLI supports sending proposal to only one endorser at a time. This does not allow us to test policies such as "AND". Murali suggested adding a new feature to the CLI invoke command to send proposal to multiple endorsers.  Here are the steps he suggested:    # Step 1: Adding a new parameter CORE_PEER_ENDORSERS to core.yaml to allow user to specify list of endorser peers   # Step 2: Adding a new method like sendProposalToEndorsers to peer/chaincode/common.go and leverage existing code to send proposals to multiple endorsers using list of endorser addresses provided in CORE_PEER_ENDORSERS parameter if specified.  Also, if CORE_PEER_ENDORSERS is undefined/empty, we expect the command to default to using current behavior and CORE_PEER_ADDRESS.  # Step 3: Adding related changes to peer/chaincode/invoke.go    In Step 2:   We would expect CLI command to send proposal to all the listed peers, and provide all the proposal responses received (after some time period) together in the transaction that it broadcasts to the orderer. CLI would not need extra logic to evaluate the responses; the validation stage (after orderer delivers block) could handle that.
Answer: 529797.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: "cryptogen currently creates useful artifacts but the are hard to use with common configuration and orchestration tools.    As an example, fitting into a structure similar to the following would make life simpler:    build/nodes/  ├── cli  │   ├── channel.tx  │   ├── configtx.yaml  │   ├── core.yaml  │   ├── msp  │   │   ├── admincerts  │   │   │   └── peerOrg1-cert.pem  │   │   ├── cacerts  │   │   │   └── peerOrg1-cert.pem  │   │   ├── keystore  │   │   │   └── d2ee5e16f9578778965ac4f61befbac4a714a84e8b33b6c774c5fab9f8640152_sk  │   │   └── signcerts  │   │       └── peerOrg1Admin-cert.pem  │   └── tls  │       ├── ca.crt  │       ├── server.crt  │       └── server.key  ├── orderer  │   ├── configtx.yaml  │   ├── core.yaml  │   ├── genesis.block  │   ├── msp  │   │   ├── admincerts  │   │   │   └── ordererOrg1-cert.pem  │   │   ├── cacerts  │   │   │   └── ordererOrg1-cert.pem  │   │   ├── keystore  │   │   │   └── 21bec31fd0f2a2388e98845ad8bef09b096d0f679a4fa1a0dfea009e64fae416_sk  │   │   └── signcerts  │   │       └── ordererOrg1Orderer1-cert.pem  │   ├── orderer.yaml  │   └── tls  │       ├── ca.crt  │       ├── server.crt  │       └── server.key  ├── peer1  │   ├── configtx.yaml  │   ├── core.yaml  │   ├── msp  │   │   ├── admincerts  │   │   │   └── peerOrg1-cert.pem  │   │   ├── cacerts  │   │   │   └── peerOrg1-cert.pem  │   │   ├── keystore  │   │   │   └── fd8948274f5b7a36dafbb36d1ae4fcaff7a7c2a57da12cc2f90b23a5b4c6a305_sk  │   │   └── signcerts  │   │       └── peer1-cert.pem  │   └── tls  │       ├── ca.crt  │       ├── server.crt  │       └── server.key  ├── peer2  │   ├── configtx.yaml  │   ├── core.yaml  │   ├── msp  │   │   ├── admincerts  │   │   │   └── peerOrg1-cert.pem  │   │   ├── cacerts  │   │   │   └── peerOrg1-cert.pem  │   │   ├── keystore  │   │   │   └── 859d526f3fe70c0dcc65d43811f9cfcb26934e67de444ffc2ad178813a773703_sk  │   │   └── signcerts  │   │       └── peer2-cert.pem  │   └── tls  │       ├── ca.crt  │       ├── server.crt  │       └── server.key  ├── peer3  │   ├── configtx.yaml  │   ├── core.yaml  │   ├── msp  │   │   ├── admincerts  │   │   │   └── peerOrg1-cert.pem  │   │   ├── cacerts  │   │   │   └── peerOrg1-cert.pem  │   │   ├── keystore  │   │   │   └── 58f8e5d5efe8da887007d121910e66608de017696e3cee19c5048c0910a9b685_sk  │   │   └── signcerts  │   │       └── peer3-cert.pem  │   └── tls  │       ├── ca.crt  │       ├── server.crt  │       └── server.key  └── peer4      ├── configtx.yaml      ├── core.yaml      ├── msp      │   ├── admincerts      │   │   └── peerOrg1-cert.pem      │   ├── cacerts      │   │   └── peerOrg1-cert.pem      │   ├── keystore      │   │   └── 2b183ef178008b81fa68c72cdd7e5b9a5fb250f9ed6f1ce1307bcae09b6d1f33_sk      │   └── signcerts      │       └── peer4-cert.pem      └── tls          ├── ca.crt          ├── server.crt          └── server.key"
Answer: 17264.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: "Goal:     1. To build a environment that can generate certs, orderer block and channel transaction for an organization and its peers. A docker-compose.yaml that can launch a network of 4 peers.    2. Add tests for all example chaincodes under fabric/examples folder as an e2e CLI test using the network launched in step1.    3. Add new chaincodes to test other fabric chaincode features like upgrade    4. Have an report generated that CI can use for reporting daily regression runs."
Answer: 27494.0

User story: "configtxgen tool looks for configtx.yaml file in the following paths  {panel}  ORDERER_CFG_PATH  PEER_CFG_PATH  $GOPATH/src/github.com/hyperledger/fabric/common/configtx/tool  {panel}      However, If user wants to provide a custom path that is not possible without exporting/Overiding the environment variables *ORDERER_CFG_PATH* , *PEER_CFG_PATH*    Providing a flag to accept filePath to the tool to access configtx.yaml will give more control to the end user while generating the orderer genesis block and channel configuration transaction."
Answer: 859977.0

User story: "Description          CC can getStates from peer and putState to peer by batch, it can reduce network traffic.  Motivation and Context          1、for example,getState by list a,b,c,d, e ,i need to call getState some times          2、for example,setState by list a->10,b->20,c->30,d->40, e->50 ,i also need to call putState some times          Now only need to call once by batch"
Answer: 1451955.0

User story: "The peer does not log any information when sending block events from the peer. This is a problem when events that a client (an SDK, for example) is waiting on are not received. Without logging on the peer side, it is hard to tell if the problem occurred with the peer sending the event or if the event was not received/processed by the client correctly.     Example of the updated logging messages, which show the channel, block number, and any transaction ids in the block event:  {code}  2017-04-14 23:46:55.090 UTC [eventhub_producer] SendProducerBlockEvent -> DEBU 698 Entry  2017-04-14 23:46:55.090 UTC [eventhub_producer] SendProducerBlockEvent -> DEBU 699 Channel [mychannel]: Block event for block number [1] contains transaction id: 8d74fd3a843ea49fe8f44d7d5c2e74101b43c98cda531962e42925f52fcba3a2  2017-04-14 23:46:55.090 UTC [eventhub_producer] SendProducerBlockEvent -> INFO 69a Channel [mychannel]: Sending event for block number [1]  2017-04-14 23:46:55.090 UTC [eventhub_producer] Send -> DEBU 69b Entry  2017-04-14 23:46:55.090 UTC [eventhub_producer] Send -> DEBU 69c Event processor timeout > 0  2017-04-14 23:46:55.090 UTC [eventhub_producer] Send -> DEBU 69d Event sent successfully  2017-04-14 23:46:55.090 UTC [eventhub_producer] Send -> DEBU 69e Exit  2017-04-14 23:46:55.090 UTC [eventhub_producer] SendProducerBlockEvent -> DEBU 69f Exit  {code}"
Answer: 1223.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 cryptogen and configtxgen are used to generate fabric PKI and configuration for peer and orderer. Adding these binaries inside of a container might make it easier for developers since at times it can be a little tricky with native binaries to connect to other running containers (e.g. using Docker for Windows) "
Answer: 224888.0

User story: There are sbft-related artifacts in the the top-level orderer package that do not belong there.    I was told that they were allowed in there temporarily until some sbft-related work was completed, but it's been a couple of months now, and as we're finalizing the work for v1.0 we should expedite this clean up.    Specifically, the following needs to go:    # "genesis" section in orderer.yaml file: this holds deprecated settings simply for sbft - https://github.com/hyperledger/fabric/blob/master/orderer/orderer.yaml#L173  # "sbft_test.go" and "network_test.go" in "fabric/orderer": both of them are sbft-related and don't belong in the top-level orderer package.
Answer: 121645.0

User story: "Let's look at worst case... CouchDB builds indexes at query time (for any new docs since last index update), not at insert/update time like most databases.  Let's say a new peer has just come up and done state transfer on 1 million blocks.  CouchDB state db will be built out, but the first query during a simulation will have to build out an index covering millions of documents. The amount of time is probably measured in seconds, potentially exceeding the default timeout for CouchDB and chaincode execution.    It would be better to 'warm up' the indexes upon peer start (ledger initialization) by doing a trivial query.  This will force any unindexed documents to get indexed, before the peer can accept simulation requests."
Answer: 296553.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: "Special case of FAB-2091 and aims to address instantiation specific checks:    - ensure creator / creator signature are valid and satisfy the chaincode's instantiation policy   - ensure a chaincode with the same name has not been added to the channel   - ensure consistency of the item included in the write set, i.e., chaincode identifier, instantiation policy, chaincode name and hash of binary code.   - does not overwrite existing chaincode entry    We need to do a check for upgrade.    Checks that need to be done at commit time:  * Same checks as during endorsement time (FAB-2931)  * Validation of the rw-set: instantiate can only create new entries, upgrade can only modify existing entries (read must be on the same key as the write and the key must match the invocation parameter)  * The tx submitter needs to satisfy the channel's CC instantiation policy. This policy needs to be added to the genesis block (optional?).  * The endorsements need to satisfy the channel's CC instantiation endorsement policy. This policy needs to be added to the genesis block (optional?).    Regarding CC instantiation endorsement policy:  A potential channel CC instantiation endorsement policy would be that a member of each MSP is required to co-endorse the simulation result of a given instantiation request for the corresponding transaction to be accepted. However, in certain cases defined MSPs (and respective applications) do not own peers.  If the submitter is trusted to choose endorsers that would not maliciously alter the LCCC state, no CC instantiation endorsement policy is needed."
Answer: 26467.0

User story: "For confidential deployments of Fabric, clients need to be restricted from using APIs that return blocks, transactions, RW sets, private data, and similar.    *Clients are not trusted at the same level as peers*"
Answer: 1460180.0

User story: Each transaction is stored in common.Envelope  type Envelope struct {      Payload   []byte       Signature []byte  }    The Payload of Envelope contains Header and Data.  type Payload struct {      Header *Header       Data   []byte   }    The Header contains a channel header and a signature header.   type Header struct {      ChannelHeader   []byte       SignatureHeader []byte   }    Again, we have a signature header in   type TransactionAction struct {      Header  []byte       Payload []byte   }.    Attached a document contain the whole block data as JSON. Refer to "signature_header" field and "tx_action_signature_header". 
Answer: 1460343.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 we send a StateInfo pull request, we currently select a random set of peers from the orgs that are members of the channel.     In case of most peers not being in the channel, they don't have any StateInfo messages to give back, so we just end up wasting resources and time.    OTOH - we can't go to the extreme opposite because there might be lots of peers that are in the channel, and since we don't do periodic (it's event-based) dissemination of StateInfo messages, we'll miss these peers.    So, we perhaps need to select a few peers that we know are in the channel, and also a random set out of all the peers of the orgs in the channel.    [~<USER> [~<USER> I'm putting this in the backlog as this is a mere optimization and not a vital one. "
Answer: 1460359.0

User story: "We inconsistently use global and private viper instances in the fabric.git codebase.  This makes it difficult to provide services such as config-path determination, needed as part of other efforts.  Suggest switching all uses to global method for ease of use."
Answer: 26138.0

User story: "The GetChannels call of CSCC (Configuration System Chain Code) currently returns only the channel IDs of the channels that the peer has joined.   This call should also return the config block associated with each channel,  or at least add that as an option.  This would allow clients/SDKs to efficiently get information related to channels."
Answer: 1460452.0

User story: "The gossip network transports sensitive data that must not be seen by clients. Rogue clients could also introduce other attacks if they can impersonate being a peer. Clients must be considered less trusted than peers (also see FAB-3134).     There needs to be a mechanism to validate that an entity is allowed to join the gossip network. This means, for example, that the entity is part of a valid organization, holds a certificate from a valid root, *and has been given authorization to be a peer*. The last part is important because clients are also given certificates.    p.s., I assume other peer cases are covered by config txn (e.g., anchorPeer, endorser policy)? I'm having trouble locating the configuration for the normal peer (as described above).    Also can we confirm that the anchorPeer in the config txn has a relationship to their certificate that is being validated?"
Answer: 1460624.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 should be a way to restrict events being sent back to clients. i.e., so that they only find out whether submitted transactions have been validated or invalidated upon commit (e.g. by txid). SDKs shouldn't be depending on having blocks and RW sets sent in events. Confidentiality is important and the client MUST be considered less trusted.    This ticket contrasts with FAB-2679 which proposes to add RW set in block events. There needs to be a mechanism to restrict block events and block events with RW sets to a subset of clients and/or disable. This is required for fabric deployers that require confidentiality such that the ledger is restricted to the peers.    A side benefit is that a smaller volume of data is being sent over the network, since in many scenarios the submitting client only needs the transaction status sent back.    Of course, there can be a set of well-defined fabric confidentiality levels for block events that are enforced by ACL policy and can be requested by the client. In particular, some applications may define their CC events in a way that can be exposed to clients and will find it useful to receive in filtered events (as another well-defined confidentiality level in addition to txn status)."
Answer: 1461274.0

User story: copy "cryptogen" and "configtxgen" binaries in peer image to access these binaries from peer docker image.     perform "make configtxgen" to generate configtxgen binary file and push this to peer docker image  perform "make cryptogen" to generate cryptogen binary file and push this to peer docker image    
Answer: 22993.0

User story: "This logic has an init() function which triggers in both test and production modes, which is not correct."
Answer: 21490.0