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: "Hitting the following unit-test issue:  {code:java}  unit-tests_1  | --- FAIL: TestNewConnection (0.03s)    unit-tests_1  |     --- FAIL: TestNewConnection/client_TLS_/_server_TLS_match (10.00s)    unit-tests_1  |     client_test.go:273: starting server with TLS    unit-tests_1  |     client_test.go:282: server: accepted from 127.0.0.1:39454    unit-tests_1  |     client_test.go:286: tls handshake error: tls: first record does not look like a TLS handshake            Error Trace:    client_test.go:297    unit-tesError:      Received unexpected error:    unit-tes            context deadline exceeded    unit-tes            github.com/hyperledger/fabric/core/comm.(*GRPCClient).NewConnection    unit-tes            github.com/hyperledger/fabric/core/comm/_test/_obj_test/client.go:191    unit-tes            github.com/hyperledger/fabric/core/comm_test.TestNewConnection.func1    unit-tes            /opt/gopath/src/github.com/hyperledger/fabric/core/comm/client_test.go:294    unit-tes            testing.tRunner    unit-tes            /opt/go/src/testing/testing.go:746    unit-tes            runtime.goexit    unit-tes            /opt/go/src/runtime/asm_amd64.s:2337    unit-tes            failed to create new connection    unit-tesTest:       TestNewConnection/client_TLS_/_server_TLS_match            Error Trace:    client_test.go:298    unit-tesError:      Expected value not to be nil.    unit-tesTest:       TestNewConnection/client_TLS_/_server_TLS_match    unit-tests_1  | FAIL    unit-tests_1  | coverage: 90.5% of statements    unit-tests_1  | FAIL github.com/hyperledger/fabric/core/comm 24.667s{code}  Similar (though not identical) issues have been observed in jenkins builds. For example:    https://jenkins.hyperledger.org/job/fabric-verify-x86_64/21824/consoleFull"
Answer: 8835.0

User story: A handful of our tests require CouchDB. The current approach is to hard code the tests with assumptions about our vagrant or docker environment that makes the database available at "couchdb:5984". While this works, it gets in the way of a pure local development environment.    Instead of assuming the database is available at that host and port, a mechanism should be created to point the tests to an active instance. When the tests are not explicated pointed to an active instance, the tests should be able to start a containerized instance on demand.    Acceptance:   # Tests continue to run in a docker-compose environment when {{make unit-tests}} is used.   # When running tests locally with {{go test ./...}}, the local docker engine will be used to start and stop an instance of hyperledger/fabric-couchdb:latest. This assumes that the latest image has already bee pulled and tagged for local execution (which is also true of {{make unit-tests}}. We are not improving this.)
Answer: 39910.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: A number of concept docs and tutorials have been added since this doc was written. Need to link out to those.    Also, some of the language here is a bit marketing-y and cringey, e.g.:    "Hyperledger Fabric delivers a uniquely elastic and extensible architecture, distinguishing   it from alternative blockchain solutions. Planning for the future of enterprise   blockchain requires building on top of a fully vetted, open-source architecture;   Hyperledger Fabric is your starting point."    And should be deleted.    Also, latest png files were never added to this doc. Should add those.
Answer: 49351.0

User story: "Doc change here: https://jira.hyperledger.org/browse/FAB-7469    Document the following enhancement:    Once this code is published it will be possible to identify MSP administrators by using the Organizational Units they belong to without have to name them explicitly. Therefore, we need to document the how the MSP configuration can be used to specify an OU that identifies the administrators of that MSP. Namely, we propose to add the following new protobuf message:  {code:java}  message FabricAdminOUs {      // If true then an administrators are identities by their OUs, otherwise they need      // to be named one by one.      bool   Enable = 1;        // OU Identifier of the clients      FabricOUIdentifier adminOUIdentifier = 2;  {code}  to FabricMSPConfig. At setup time, if FabricAdminOUs.Enable is equal True then the MSP will enforce only identities carries the specified OU will be considered administrators of that MSP, otherwise, the previous behavior is enforced.     "
Answer: 951717.0

User story: "As per https://jira.hyperledger.org/browse/FAB-8729    And its design doc: https://docs.google.com/document/d/1YmWCdPOJAJU6kxO56vYoS6Ev_La32mx4PG-3pCUri6g/edit"
Answer: 67827.0

User story: "People often write in to say they're confused about what Anchor Peers are and what they do. In addition to beefing up the glossary definition, it makes sense to add a section on it in this doc."
Answer: 4524.0

User story: The new Client Identity Chaincode Library introduced with Fabric 1.1 seems not to be included in the respective Docker image(s).    When chaincode is instantiated and built, the following errors occurs:  > error starting container: Failed to generate platform-specific docker build:  >   Error returned from build: 1 "chaincode/input/src/github.com/my_example_cc/main.go:4:2:  >     cannot find package "github.com/hyperledger/fabric/core/chaincode/lib/cid" in any of:  >       [...]    I'm using the latest fabric-ccenv Docker image.    Several other people have the same problem, see also:  - https://github.com/yeasy/docker-hyperledger-fabric/issues/4  - https://github.com/<USER>fabricDeployment/issues/8  - https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-December/002441.html
Answer: 170371.0

User story: "Take someone through the scenario and then actually deploy it."
Answer: 947585.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 doc: [https://github.com/hyperledger/fabric/blob/13447bf5ead693f07285ce63a1903c5d0d25f096/proposals/r1/Next-Ledger-Architecture-Proposal.md]    Needs a disclaimer to reflect that it's somewhat out of date."
Answer: 42316.0

User story: "This doc: [http://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html]    Is badly outdated. Need a strategy on replacement/revision/deletion/etc.    My suggestion is to provide a doc stub and link out to this: [https://arxiv.org/pdf/1801.10228.pdf]    Rather than attempting to summarize it.          "
Answer: 172815.0

User story: "The question to explain and clarify the concept of the anchor peers appear quite frequently in mailing list, on rocket chat channels as well as in StackOverflow. Need to add documentation section which would expand and explain about configuration related to the anchor peers and theirs role."
Answer: 173029.0

User story: "As with identity.md, although Elli did a great job, a final review/edit is needed for this doc to fix typos, certain formatting issues, as well as cleaning up some of the language."
Answer: 80086.0

User story: "Although Elli did a great job shepherding identity.md through the final stages before the 1.1 release, the doc still needs another round of minor clean up."
Answer: 72847.0

User story: "We should enhance configtxgen to make specifying ACLs possible as part of channel creation, and users may of course use standard channel reconfiguration tools to modify or add them later.    We should create a new ACLs element under the Application element that users may modify.    {noformat}    Application:      ACLs:        CSCC.GetConfigBlock: /Channel/Application/Readers        ...        QSCC.GetBlockByNumber: /Channel/Application/Readers  {noformat}"
Answer: 38311.0

User story: "The resources tree was introduced as a place to store information which was jointly administered by the network, like channel config, but which could change frequently or become large.  Since chaincode lifecycle was moved off of the resources config, and the ACLs are the only small consumer of it, it is too much and too complicated to leave in place to support this relatively simple use case.  As ACLs are migrated to channel config, the resources tree should simply be removed."
Answer: 60875.0

User story: "Today, the ACLs are held in the resources config.  However, since the resoruces config is going away, they need to be moved to the channelconfig.    This should be as simple as defining a new config value, and implementing parsing for it."
Answer: 37333.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 element (Such as Channel, Application, Orderer, and Org) should  be enhanced to support a Policies sub-element. Like:      {noformat}    Application:      Policies:        Foo:          Type: Signature          Rule: "Org1.Peer AND Org2.Peer"        Bar:          Type: ImplicitMeta          Rule: "MAJORITY Readers"  {noformat}    This will require a new parser for rules of type "ImplicitMeta", but the parser for signature policies (as used in the peer CLI) should be recyclable.  Once parsed, these policies should be injected into the new config block or channel creation transaction.
Answer: 22924.0

User story: "Once working end to end, the fabric-samples need to be migrated onto the new chaincode lifecycle.  Note, this should include updating the corresponding documentation which references the samples."
Answer: 547003.0

User story: "The current validation plugin is not compatible with the improved lifecycle.    Notably, the VSCC contains special checks for invocations of 'LSCC'.  The new lifecycle also depends on standard VSCC validations for the LSCC functions."
Answer: 546904.0

User story: "To flexibly and securely instantiate chaincode, the 'instantiate step' has been split into a 'define' step, and an 'Init' step.    The 'Define' step collects endorsements from different peers which have the chaincode metadata package installed.    This Define step needs to be implemented as a function of the LSCC and exposed through the peer CLI."
Answer: 175465.0

User story: "Today, chaincode install stores non-code related artifacts like instantiation policy and signatures.    Because chaincode (code) installation is a global operation, and because fabric v1.2 may have some channels operating in a v1.2 lifecycle mode, and some channels operating in a v1.1/v1.0 lifecycle mode, it's necessary to support both of them in the new peer binary.    However, going forward, there will need to be a new LSCC.InstallCode function which stores the new chaincode code package.  To minimize upgrade pain, it likely makes sense to have both of these functions store their data in the same way, so that users do not have to 'install' and 'installcode' the same chaincode bytes twice.  Still, going forward, perhaps in v1.3, the plain 'install' function should be removed entirely."
Answer: 175477.0

User story: "The design of the chaincode lifecycle calls for channel-scoped, chaincode metadata packages.    These metadata packages describe the chaincode which is being defined and are used to help a peer's LSCC decide whether or not to endorse a 'Define' proposal.    This feature is to track the implementation of this piece of the design."
Answer: 175510.0

User story: "Since goprofile is very useful in finding bottle necks in golang applications, I recommend NL and PTE should make some changes to support goprofile."
Answer: 971364.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 interface for vscc validator has been defined in \{\{validator.go}}, to keep the code clean and make it possible to handle refactoring later, it's better to have this interface and its implementation separated."
Answer: 2246.0

User story: "vsccValidator interface introduces VSCCVAlidate function which accepts payload, marshaled and unmarshaled transaction envelop.     {code}  type vsccValidator interface {   VSCCValidateTx(payload *common.Payload, envBytes []byte, env *common.Envelope) (error, peer.TxValidationCode)  }  {code}    While there is no functional use of unmarshaled Envelop except for using in debug message. This commit removes this parameter from declaration due its redundancy."
Answer: 23910.0

User story: "Add a brief introduction."
Answer: 88.0

User story: "This FAB consists of the following steps:   # Introduce the Idemix options to support the various cryptographic operations   # Provide a new BCCSP interface implementation to support the Idemix options   # Refactor the Idemix-based MSP to use the Idemix BCCSP    After this, it will be easier to refactor the idemix package and introduce new functionalities."
Answer: 368224.0

User story: "A short topic on connecting to the ledger from mobile app to REST server, fabric application, chaincode."
Answer: 975761.0

User story: "Sample JIRA for DWG am call"
Answer: 8124.0

User story: "bypassdownload of docker images if not installed - leaving just the function of downloading the appropriate tarball for platform-specific binaries."
Answer: 20355.0

User story: "Today, there are some local peer scoped operations, such as deploying chaincode which equate to installing files onto the filesystem.  This is an inflexible mechanism, and as more use cases arise, different peer components may need to store peer specific (non-configuration) data in a consistent way.    The most obvious way to accomplish this, is to provide per peer channel scoped, local storage within some partitioning of the state database.    This local storage must be manipulable in a safe way relative to channel ordering.  Specifically, there are two cases which must be supported:    # Reading/Writing to this storage space in a concurrency safe way during a chaincode invocation.  e.g. {{LSCC.InstallMetadata}}  # Reading/Writing to this storage space in a concurrency safe way during the block commit phase e.g. during the commit of an {{LSCC.Define}} transaction    These properties are necessary to address the following case:    An Administrator attempts to install a chaincode metadata package for a chaincode.  Simultaneously, a chaincode definition is committing to the ledger.  The commit needs to check if the chaincode metadata exists in the peer local data, and if so, mark it as 'active'.  The chaincode metadata install also needs to check if the chaincode is already defined in the LSCC (non-local-data) table to see if the chaincode should be set as active."
Answer: 429725.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 peer CLI has always had a serious shortcoming, in that it can only collect an endorsement from a single peer when submitting a transaction.    This is a serious problem for doing any sort of meaningful testing or examples with the CLI, as an endorsement policy of "1 out of ..." is really not a good example for a system with distributed trust.    Because chaincode lifecycle will require by default endorsements from a 'majority' of organizations, for all but single-organization networks, deploying a chaincode will require obtaining a signature from at least two peers.    The design of this feature's implementation is deliberately left as an open question, to be decided with a design sub-task.
Answer: 90633.0

User story: "Currently within many Fabric unit tests which requires to establish networking the ports are assigned statically and hard coded in many places. This raise a problem where developer which writes new UT has to be aware of ports already in use to avoid collisions, since we would like to be able to parallelize our unit tests.    There is a need to develop a mechanism/utility which will allow to dynamically allocate random ports to be used in the unit tests, thus reducing a burden or need to manually track ports which are currently in use."
Answer: 978457.0

User story: "NetworkLauncher is a great tool to help generate dynamic networks,but it will take lots of time to construct scfile for PTE which will easily cause manual mistakes.. So I recommend NL could generate scfile automatically for PTE."
Answer: 978684.0

User story: "Enable configuring the SDK with custom key and cert stores."
Answer: 724829.0

User story: "*###Scenario*    A user has a chaincode written in golang with several external dependencies. They would like to use the `dep` tool to vendor these dependencies and the shim (as is advised in the latest build), but they don't want to commit a large number of files to what is otherwise a small repository.         *Current Behaviour*    Users are forced to commit their `vendor` directory along with their chaincode in order to include the dependencies in their chaincode container.         *Suggested Behaviour*    When the chaincode is built, we should search for `Gopkg.toml` and `Gopkg.lock` files. If they are present, then we should run `dep ensure`. This will fetch the dependencies from their respective upstreams and build them into the dependency tree without the user having to commit them to their repository.         It's also worth noting that.. If a user _wants_ to commit their vendor directory to their repository, this will still work - and has the added benefit of running `dep ensure` - which will make sure that the committed dependency tree is valid.     "
Answer: 906171.0

User story: "Extend the VSCC to handle per-key endorsement policies stored in the key metadata."
Answer: 281664.0

User story: "A custom ESCC is required to endorse changes to ownable state. This ESCC makes use of the ownable state endorsement interface for signing."
Answer: 980674.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: "Owners of an ownable state endorse changes to it by signing transactions with some keys. This key may be the long term signing identity of the peer or a different kind of key. Key management should be in place to capture all possibilities.    Design/Implement a proper key manager/signer factory (especially for privacy-preserving OS)."
Answer: 980731.0

User story: "Testing for default config values is already performed in {{TestSystemChannel}}. {{TestProfileConfig}} is there to increase test coverage but it is redundant. It should be removed."
Answer: 37052.0

User story: "This comment on the {{Chain}} interface is no longer accurate:    //NOTE: The kafka consenter has not been updated to perform the revalidation  // checks conditionally.  For now, Order/Configure are essentially Enqueue as before.  // This does not cause data inconsistency, but it wastes cycles and will be required  // to properly support the ConfigUpdate concept once introduced  // Once this is done, the MsgClassification logic in msgprocessor should return error  // for non ConfigUpdate/Normal msg types"
Answer: 35997.0

User story: "This is a sample JIRA to get you comfortable with JIRA and contributing to Hyperledger Fabric"
Answer: 14355.0

User story: "Currently test in gossip/state package executed serially, parallel execution was not possible since there was a dependency on the ledger package, however after CR for FAB-8064 state transfer tests could be easily parallelized."
Answer: 2969.0

User story: "The peer chaincode package command should be updated similarly to FAB-8731. "
Answer: 673.0

User story: "By FAB-7969, some field names are reserved in a JSON document to be put a CouchDB state database. This topic should be documented."
Answer: 476.0

User story: "Yogendra's test jira"
Answer: 18152.0

User story: "See review comments in : [https://gerrit.hyperledger.org/r/#/c/17541/] ."
Answer: 61662.0

User story: "Similar to how {{cryptogen}} does it, {{configtxgen}} should support a {{config}} option:    {{configtxgen -config=./foo/configtx.yaml ...}}    When this is set, the usual config mechanism that looks for the {{FABRIC_CFG_PATH}} environment variable, and then the CWD, etc. is overriden."
Answer: 89202.0

User story: "These two alternative, non-production ledger implementations have outlived their usefulness and should be removed from the code base. This should also allow us to remove the {{LedgerType}} setting from {{orderer.yaml}}."
Answer: 734323.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 process for updating the policy on a channel for a chaincode requires that one reinstalls the chaincode for that channel (even though the software necessarily does not change). One must install chaincode changing the version, even though it's the exact same chaincode as the previous version. So if one wants to change the endorsement policy from "OR" to "AND", the following must be done when using CLI commands:  {code}  $ peer chaincode install --name mycc --version 1 --channelID behavesystest --tls true --cafile tlsca.example.com-cert.pem --orderer orderer.example.com:7050 --path github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 --lang GOLANG    $ peer chaincode upgrade --name mycc --version 1 --channelID behavesystest --tls true --cafile tlsca.example.com-cert.pem --orderer orderer.example.com:7050 --policy "AND ('org1.example.com.client','org2.example.com.client')"  {code}  Changing the policy seems similar to changing a software's configuration. Some organizations will change the version, others may not. A fresh deployment of the same software is not needed in either situation and should not be necessary here. There should be a way to reference an existing chaincode path when changing the policy. I can see the argument for both sides when deciding whether or not to force the incrementing of the version.
Answer: 68924.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: "* Cleanup separation between API and implementation   * Move out of pkg/core"
Answer: 19883.0

User story: "The Fabric docs TOC was a mile long and that makes it difficult to navigate. A refactor to only list top-level content makes it much more accessible."
Answer: 6984.0

User story: "State databases (e.g. goleveldb, CouchDB) currently implement the VersionedDB interface.  However this requires compiling state database implementations into Fabric itself.    It would be more clean to use the new go plugin architecture to support truly pluggable state databases that do not need to be compiled into Fabric.  This will make it easier to implement and support additional state databases, outside of the Fabric build.    Please see the design doc:  https://docs.google.com/document/d/1ZdxPWdxUwEDwRAKY8tewgjqh2qTZCm6RZ6tU9ccm4dM/edit?usp=sharing"
Answer: 832056.0

User story: The channel update code will return an error message like:    {noformat}  Update not for correct channel: foo for bar  {noformat}    Which is fairly easy to understand if both channel IDs are set, but in particular if 'foo' is empty, the error message reads very oddly.    In addition to the quoting, making the error message a little more verbose like:    "ConfigUpdate for channel 'foo' but envelope for channel 'bar'.    would be helpful.
Answer: 359140.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: "indira.kalagara {color:#a0a0a0}1:48 AM{color}  On Fabric v1.1 document page -  [http://hyperledger-fabric.readthedocs.io/en/v1.1.0-rc1/upgrading_your_network_tutorial.html]    Checout is referring v1.1.0 and the cmd   git checkout v1.1.0 gives below error:  error: pathspec 'v1.1.0' did not match any file(s) known to git.    I think it should be v1.1.0-rc1 as below is working.   The below works  git checkout v1.1.0-rc1    Let me know if its correct."
Answer: 191.0

User story: Question: SDK local time is different from fabric orderer's,when SDK connects to fabric network will get error message:    "org.hyperledger.fabric.sdk.exception.TransactionException: Bad newest block expected status 200  got  400, Channel x"    It's not friendly.Because I can't find real problem by the error message.    Advice:Orderer's error messages should return to SDK so that we can know real problem.    Env: v1.1.0-alpha,when checking timestamp of SDK and server time.     
Answer: 995867.0

User story: let the symbol *"=>"* stands for *invokeChaincode*  current fabric-peer only supports cc1 => cc2 and get response    but sometimes we may meet the following scenario:    1.  cc1 => cc2 => cc3 (no circle)  2.  cc1 => cc2 => cc1 (with circle)    for scenario 1, cc2 => cc3 does not work  for scenario 2, cc2 => cc1 does not work    It seems current fabric-peer does not support embedded cross-chaincode invoke, this feature should be added.
Answer: 741357.0

User story: "Right now, we have quite a collection of RTD builds for Fabric:  [latest|http://hyperledger-fabric.readthedocs.io/en/latest/] [v1.1.0-rc1|http://hyperledger-fabric.readthedocs.io/en/v1.1.0-rc1/] [v1.0.6|http://hyperledger-fabric.readthedocs.io/en/v1.0.6/]  *[release|http://hyperledger-fabric.readthedocs.io/en/release/] [master|http://hyperledger-fabric.readthedocs.io/en/master/]*This actually is somewhat redundant, because 'latest' and 'master' are equivalent. 'v1.0.6' and 'release' are also equivalent.    Now, we have also talked about reworking the branch strategy for post 1.1 so that we have a release branch for every major.minor release. What I would propose is that so that we can avoid having to constantly change references, that we adopt a strategy of publishing two doc versions for master branch (current development):    latest == HEAD of masterstable == most recent preliminary release (preview, alpha, beta, rcx)     and that we publish one doc version for each major.minor release we have published:    release-1.0 == v1.0.xrelease-1.1 == v1.1.x    I would also propose that we adopt a similar naming convention for the release branches  (e.g. release-1.0 and release-1.1) and that we then publish a series of tags against that for each patch release (e.g. v1.0.0...v1.0.6, etc)."
Answer: 40373.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 have an issue in that the build process takes a dependency on a previous "release" when looking for images from other repositories (e.g. fabric-ca looking for "previous" release version of fabric-orderer. When this is a release build, there isn't going to BE a previous release image published until the fabric repo is tagged.
Answer: 212353.0

User story: "The e2e and byfn scripts rely on the output of {{configtxgen}} to update anchor peers.  This has always been a bit of a dirty hack, as the output of {{configtxgen}} assumes an untouched network.  For instance, changing anchor peers a second time will always fail.  If other changes have been made, such as modifications to the MSP, setting anchor peers will also fail.    Really, anchor peer updates should be done like any other config update, such as adding a capability or org, and our examples/tests should be fixed to do so."
Answer: 996859.0

User story: In fabric read-the-docs under section "Command Reference" we have "peer command" which is followed by actual commands like:    peer channel    peer logging    ....    [http://hyperledger-fabric.readthedocs.io/en/latest/commands/peercommand.html]    For better organizing could we have "peer command" in Bold something like "Peer Command(s)" and have the actual commands to be collapsible or in italics or something to give the user an indication these are the set of command that make up "Peer Command(s)" 
Answer: 996970.0

User story: "Missing code block."
Answer: 102.0

User story: "Want to keep some ops guide doc for upgrade, but something short and high level that points to the Upgrading Your Network Components tutorial and the doc on Capability Requirements."
Answer: 165.0

User story: Need to add in a few loose ends from the "Procedure for Upgrading from 1.0.x" doc that were not in tutorial to ensure that "Procedure" doc can be slimmed down and made entirely high level.
Answer: 53.0

User story: "Upgrading Your Network Components was merged without a link to the Fabric-CA material on that topic. Need this link now that the CA doc has been merged."
Answer: 81.0

User story: "Links in Identity and Membership documentation worked, but needed to use more resilient links that use the correct relative paths."
Answer: 50.0

User story: "Gossip enqueues blocks into the payload buffer via different mechanisms:  - State transfer anti-entropy  - Pull  - Push    Whenever an attempt to add a block to the payload buffer which was already added before by some other pathway - a warning is logged.    I think we should make that warning a debug, since it's not something that users should be worried about. "
Answer: 208.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, gossip stores blocks in several places:   * Message store, to know if a message was received before, or not, and also to be used by the pull mechanism to provide blocks to other peers that request them  * Payload buffer (in the state module) to reorder blocks that are received.    This poses a problem when blocks are huge. i.e 10MB blocks might sum up to 1GB of memory.        [~<USER>"
Answer: 744095.0

User story: "It would help in debugging (and understanding) the byfn tutorial better if the various commands were echo'ed to the output. add debug output to first-network/byfn.sh and first-network/scripts/script.sh and first-network/scripts/utils.sh"
Answer: 1741.0

User story: """peer node start"" does not utilize --orderer flag, but no validation error is returned if the flag is passed.  There are likely many more validation improvements that can be made once we take a close inspection."
Answer: 1000589.0

User story: "byfns.sh stores the ledgers directly in the container.  Since upgrading the image requires destroying the container, there is no way to simulate a realistic ledger upgrade.  This issue is to add a '-p' flag and compose file which causes the ledgers to persist."
Answer: 1914.0

User story: Fabric currently has the concept of VSCC and theoretically one can associate different VSCCs with chaincode on a per channel basis.    In practice, this is not the case as the validation "flow" is actually "hard-wired" and there is really no definition / interface defined for implementing "custom" VSCC.    Ideally we should be able to easily add built-in VSCCs to Fabric and also allow VSCC to be built as plugins.
Answer: 115378.0

User story: Fabric currently has the concept of ESCC and theoretically one can associate different ESCCs with chaincode on a per channel basis.    In practice, this is not the case as the endorsement "flow" is actually "hard-wired" and there is really no definition / interface defined for implementing "custom" ESCC.    Ideally we should be able to easily add built-in ESCCs to Fabric and also allow ESCC to be built as plugins.
Answer: 114201.0

User story: "Command *peer channel fetch* is used against an orderer deliver service to fetch a block.    If you forget to add -o to connect to an orderer, you get error:    *Error: ordering service endpoint  is not valid or missing*    However, starting in 1.1 the peer also supports the deliver service, and therefore this command can be used against a peer now.  The command should be improved to go against an orderer or a peer."
Answer: 131060.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 has the option to generate NodeOUs and currently uses "FabricPeer" and "FabricClient" for peers and clients respectively.    fabric-ca supports NodeOUs by specifying the "type" of user when registering but uses "peer" and "client".    The fact that they do not match causes issues when trying to bootstrap a network with cryptogen with NodeOUs enabled and then registering and enrolling users with fabric-ca.    The logical thing would be for cryptogen to simply use the same convention as fabric-ca.
Answer: 25089.0

User story: "Include the EYFN tests in fabric in fabric-byfn-verify-x86_64 and fabric-byfn-merge-x86_64."
Answer: 2994.0

User story: "The fabric-sample first-network tutorial was originally based off of the e2e_cli example.  Over time, the two have diverged.  The e2e now only supports Kafka, the samples only support solo.  The e2e runs the test script directly via the compose file, the samples do it via a docker exec in byfn.sh.    The list goes on.    We should really synchronize these two, so that we don't have to do dual maintenance."
Answer: 385065.0

User story: "1. Would be good to include Nodejs installation steps (or atleast download link with instructions to install Nodejs) in the prereqs.html in hyperledger-fabric docs.    2. Mention compatible version of Nodejs that is required.    [http://hyperledger-fabric.readthedocs.io/en/master/prereqs.html|https://nodejs.org/en/download/]    [https://nodejs.org/en/download/]     3. Add steps to install GO language and set GOPATH env variable    [ |https://nodejs.org/en/download/]"
Answer: 114014.0

User story: "A placeholder feature to improve command output.         The peer channel command (and indeed all subcommands), should   # Provide a clear indication of whether the command has succeeded or failed   # Have some level of helpful INFO messages that return helpful information on command progress.     I'm happy to expand here on what these need to be, but for now, I've just opened this JIRA as a placeholder."
Answer: 749874.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: Updating the orgs for the fabric-ca sample does not have an effect.  If I modify the {{env.sh}} script:  {code:none}  # Names of the orderer organizations  ORDERER_ORGS="eu"    # Names of the peer organizations  PEER_ORGS="fr ge it sp"  {code}  The register attempts fail with a message like:  {{  Failed to get Affiliation: sql: no rows in result set}}    This is because the server init/start sequence relies on all of the config defaults, so only   the default affiliations are available. It requires a little massaging of the start-up scripts:    a) in {{makeDocker.sh}}:  {code:none}  writeRootCA()  ...  environment:  - FABRIC_ORGS="$ORGS"  {code}  and  {code:none}  writeIntermediateCA()  ...  environment:  - FABRIC_ORGS="$ORGS"{code}  b) in both {{./scripts/start-root-ca.sh}} and {{./scripts/start-intermediate-ca.sh}}:  {code:none}  # Add custom orgs  for o in $FABRIC_ORGS; do     aff=$aff"\n   $o: []"  done  aff="${aff#\\n   }"  sed -i "/affiliations:/a \\   $aff" \     $FABRIC_CA_SERVER_HOME/fabric-ca-server-config.yaml  {code}  Now the start.sh tests pass.
Answer: 17147.0

User story: "Implement Context Functions"
Answer: 158565.0

User story: Once FAB-8453, is fixed/corrected, we will need to revisit the use of "." in the MSPID.    This includes any other changes that were made to allow tests to continue including using 'peer channel fetch config'.  
Answer: 4239.0

User story: "fabric-ca used a scheme to generate the help docs by simply piping the help output to a markdown doc. This seems like a better approach than manually editing documents with the same intent. We should work to ensure over time that the help text is helpful and sufficient to be the documentation."
Answer: 80171.0

User story: "Please provide an example compose file that shows the environment variables to be set in the containers for making it possible to authenticate orderers that access Kafka. The Kafka should be configured such that only orderers are allowed to access the topics."
Answer: 1007657.0

User story: "Error: failed sending proposal: rpc error: code = Unknown desc = chaincode error (status: 500, message: Invalid chain ID, my-channel)"
Answer: 1008405.0

User story: "BYFN tutorial should make clear to teardown before doing step-by-step"
Answer: 53273.0

User story: "write your first app tutorial does not describe how to teardown a network that was started."
Answer: 57003.0

User story: "In the upgrade document,  http://hyperledger-fabric.readthedocs.io/en/master/upgrade_to_one_point_one.html    The upgrading of the fabric-ca is more comprehensive then updating the binaries.  We need to provide details to prevent database corruption, clustering steps, any specifics with respect to support DBs, should it be done in a maintenance window or rolling upgrades.  If someone adds the text here someone from the quaility team can submit the CR.   Thanks,  Barry"
Answer: 11279.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: "Per FAB-5246, for fabric networks NOT using gossip leader election, we must document that we can support using gossip in this mode ONLY IF all peers are set as leaders when adding extra orgs and peers to an existing network.    Otherwise, any nonleader peers added later in time (at least to organizations added after the initial network bring-up) would never receive any blocks.    This could be addressed in release notes , and should be addressed in docs - most likely in the gossip section [http://hyperledger-fabric.readthedocs.io/en/master/gossip.html] or somewhere in the Operations Guide section because it involves discussing supported gossip configurations.     "
Answer: 18352.0

User story: "There is currently no documentation for enabling mutual TLS on a node-sdk based client."
Answer: 22079.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The current description:    {quote}DefaultOrg defines the organization which is used in the sampleconfig of the fabric.git development environment{quote}    Makes zero sense."
Answer: 1669.0

User story: Currently committer UT using ledger, to actually check functionality, however this introduces complexity and couples test to be dependent on the ledger package. This dependency could be removed by leveraging:  {code}  "github.com/stretchr/testify/mock"  {code}    which will allow to speed up the test, to make it parallel and voids the need to create physical ledger during UT.
Answer: 35825.0

User story: "The peer's admin server shares the listener with the endorser one.         This doesn't make much sense because the admin service might be deployed in a setup where it should only be accessible to peer administrators and not to clients, and also  - mutual TLS is used, then it also accepts TLS client certificates issued by CAs of other organizations which share a channel with the peer's organization."
Answer: 640754.0

User story: "We should probably move the peer admin API to its own package, because it stands out in the core/ package and affects its code coverage report and doesn't reflect well the reality."
Answer: 640781.0

User story: GetStateByPartialCompositeKey only allows for exact matching of key attribute values, it does not allow for comparisons. This is an issue when working with objects such as timestamps, where an exact match is far less valuable than a less than or greater than comparison.    This can be handled by allowing GetStateByRange to query both the composite and simple key namespaces, though obviously querying both at the same time is likely to cause issues.    This could be achieved by replacing the current validateSimpleKeys check with a namespacing check, i.e.    {{// GetStateByRange documentation can be found in interfaces.go}}  {{func (stub *ChaincodeStub) GetStateByRange(startKey, endKey string) (StateQueryIteratorInterface, error) \{}}  {{    if startKey == "" \{}}  {{        startKey = emptyKeySubstitute}}  {{    }}}  {{    if keyInCompositeNamespace(startKey) != keyInCompositeNamespace(endKey) \{}}  {{        return nil, fmt.Errorf("Range queries cannot mix simple and composite keys.")}}  {{    }}}  {{    return stub.handleGetStateByRange(startKey, endKey)}}  {{}}}    Where {{keyInCompositeNamespace}} is something like the follows:    {{//Check if a given key is in the composite namespace}}  {{func keyInCompositeNamespace(key string) bool \{}}  {{    return len(key) != 0 && key[0] == compositeKeyNamespace[0]}}  {{}}}     
Answer: 266020.0

User story: "update wiki page [https://wiki.hyperledger.org/projects/fabric/fabric_ci_documentation] with latest CI information"
Answer: 114160.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 purpose for this is to allow in docker-compose files the ability to just reference the latest fabaric/ca images regardless of their release tags.    Each time a release in a major version is published to docker hub with tags like:    x86_64-1.1.0-alpha, x86_64-1.1.0-rc and later x86_64-1.1.0, and then x86_64-1.1.1    There should be a x86_64-1.1-LATEST image tag alias that is update to reference that same image above.         This would allow for SDKs, tests user created in docker-compose files to just get the latest when they're published. by specifying something like this:    orderer.example.com:       container_name: orderer.example.com       image: hyperledger/fabric-orderer:x86_64-1.1-LATEST         Discussed with [~<USER>          "
Answer: 137448.0

User story: "I think it makes sense to add an API call to the peer, that makes the peer dump its stack trace into the log.     This is useful for highly secure and isolated environments where no one can get into, and only the container logs are visible because they are automatically shipped via some mechanism.  In such environments, if there is a problem like a deadlock or something similar, having the stack trace in the log is very useful to troubleshoot.     There are 2 approaches that I see:  # Add a new method to the admin gRPC API:  ## Pros: The admin gRPC interface was created just for these kind of operations.  ## Cons: I don't see a reason of adding this method unless it is authenticated, and the admin API currently does not have authentication.   # Add a new method to CSCC  ## Pros: We don't need to extend the admin protos, however there is no real backward compatibility issue because I don't think any client but the peer CLI has implemented this capability anyway.  ## Cons: I personally don't think that chaincodes should be used for administrative operations in the peer at all, and it's pretty hard to unit test SCCs but I may be biased."
Answer: 5915.0

User story: "Integrate Extend Your First Network into the CI tests in Jenkins environment. Append the EYFN tests with the BYFN, to add the third org and run the EYFN tests to successfully."
Answer: 7373.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: "*Problem area:*   Existing Jenkins verify & merge jobs always clone the “parent commit” & GERRIT_REFSPEC from the patch set submitted by the developer not against the HEAD.     - This approach reminds maintainer to rebase the patch before merge, as it is not fetching patch set against the latest commit from the repository.    - When a build reference is changed in CI (like adding a new make target or update name of the target) or when a new file is added (ex: ci.properties), developers have to rebase all their submitted patches. This wastes build resources also this approach takes developer time to analyze the error.    *Proposed Solution:*    Every verify and merge patch clones the parent commit HEAD, fetch the GERRIT_REFSPEC & checkout to FETCH_HEAD.    *Benefit with this solution:*    Irrespective of the parent commit of the patch, the proposed approach catch the integration issues in the early stage of the patch verification and can avoid rebase issues.    saves build resources."
Answer: 398279.0

User story: "When gossip selects K peers out of the total candidates, it performs the filter predicate over all of them and then selects a random subset of size K (if possible).    It might be problematic in case the membership view is very large.    It will be much more efficient to first randomize the order of all peers, and then iterate and select the first K that match the predicate. "
Answer: 29424.0

User story: "    * QueryInstalledChaincodes()   * QueryChannelsForPeer()   * QueryInstantiatedChaincodes()   * QueryConfig()    QueryConfigFromOrderer() retrieves channel config from orderer."
Answer: 27585.0

User story: "Goals:   - Split FabricCAClient interface into two:   ** EnrollmentService - users without signing identities use it to signup with a Fabric network   ** IdentityManagement - services that require signing identity of a CA registrar   *** remove the user parameter from Register/Revoke. It represents the CA registrar and should be taken from the client CA configuration.   - Add ability to provide attributes on enroll/reenroll.   - Reimplement the user store to allow for easy manual cert management.   ** Specifically, the use case of enrolling with a certificate issued by a public certificate authority should be supported.   - Manage user certificates within the SDK   ** save to store on enroll/reenroll"
Answer: 41162.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "As of FAB-7777 , failed index create during chaincode install/instantiate will not panic peer but will still leave peer in a state where chaincode is deployed to a peer, but not able to endorse transactions (at least, not able to endorse transactions that utilize rich queries that require the indexes).    If the index create statements failed due to operational issues, there needs to be ability to re-process the failed index create statements at a later point in time, in an attempt to create the indexes that failed previously.    The re-processing of failed index create statements could be done in two ways:    1) Manually by a peer admin, e.g. via new peer APIs.    2) Automatically upon peer startup when ledger is being initialized and recovered.    Hosted environments have requested automatic recovery be implemented first.  This work item will add capability to re-process failed index create statements upon peer startup during ledger initialization/recovery.    [https://gerrit.hyperledger.org/r/#/c/17425/]    proposed to drop failed index create statements to /stateDBfailedChaincodeArtifacts directory for re-processing.    Additionally, although most indexes are known at chaincode deploy time and applicable to all peers, and therefore included in the chaincode deployment package, there are scenarios where an index may apply to queries performed on a single peer only (for example consider an auditor peer). There have been requirements to create new indexes on a single peer's channel database.  The mechanism implemented for this work item could also be used as a way to deploy new index definitions to the peer, by dropping index create json files into the correct /stateDBfailedChaincodeArtifacts directory."
Answer: 1018746.0

User story: fabric-samples/fabcar/registerUser.js line74 should be "interact" instead of "intreact"
Answer: 123795.0

User story: "The documentation doesn't explain that changing the consensus type in a config update is not allowed. the code works fine and it will be good to document the same in the docs."
Answer: 63193.0

User story: "The orderer has ClientAuthEnabled  as its configuration key that toggles the TLS service to verify clients, and the peer uses clientAuthRequired.    I think this is a bit confusing and also not uniform, and since we are introducing mutual TLS in v1.1 there is no backward compatibility issues with changing this to be uniform.    I think the required (clientAuthRequired) should be in both, because Enabled makes it sound as if it is a recommendation and not a requirement, though the option clearly makes it mandatory.     [~<USER> [~<USER> opinions?"
Answer: 162.0