udaykiran19491/user-stories-from-tawos-for-llm-fine-tuning huggingface dataset:
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The LTE tool is valuable for testing performance impact of changes to specifically the ledger code functions inside the peer. It is a useful developer tool, but that is all. It belongs inside the fabric repo. It is not a system test tool, and does not really belong in fabric-test repo. Clean up the following, on master branch AND in release-1.4 :   * +CI+:  Abandon the CI job for fabric-test LTE tests   * +CI+: Remove the LTE results from the fabric-test daily results job   * +fabric-test+: Remove all references to LTE tool and tests from Makefile and README and regression/daily/ and regression/smoke/.   * +fabric-test+: Remove fabric-test/tools/LTE/, and   * fabric:  Place LTE tools and test scripts in fabric repository in a ledger test folder. The plan is to keep the tool for developers to use on an as-needed basis, but not run all of the tests as part of any regular CI job. It would make sense to incorporate a small test using LTE (such as that executed in the fabric-test smoke test suite) into fabric integration tests folder in ledger domain, to help ensure the tool is maintained."
Answer: 140836.0

User story: "After finishing the other tasks in this epic by rewriting all the required Behave tests in the Fabric Integration golang, we must clean up the following, on master branch AND in release-1.4 :   * +CI+:  Abandon the CI job for fabric-test behave daily tests   * +CI+: Remove the behave results from the fabric-test daily results job   * +fabric-test+: Remove scripts/install_behave.sh and remove all references to behave tests from Makefile and README and regression/daily/ and regression/smoke/. Remove any associated build targets that are not used elsewhere (e.g. consider removing fabric-ca-client - although I think that one is still used by CTE). Clean up the scripts/pull* bash scripts. (Note the behave tests were already removed from the master branch smoke test suite here - but the Makefile was not cleaned up, and the daily tests are still running: [https://gerrit.hyperledger.org/r/c/fabric-test/+/33942/6/regression/smoke/runSmokeTestSuite.sh])   * +fabric-test+: Remove all test code in feature/ and feature-upgrade/.     "
Answer: 64519.0

User story: "The orderer used to have the ramledger, the jsonledger, and the fileledger.  Both of the former types have been removed, so requiring a type to be specified is confusing and unnecessary."
Answer: 9657.0

User story: "We have seen in many of our tests, that shifting the build from the first invoke to install, that many existing automated scripts now fail with a timeout.  It would be nice if we could automatically increase the timeout for chaincode install operations."
Answer: 29810.0

User story: "Create draft of documentation for the external build and launch infrastructure for Fabric. This should include introductory material, rationale, and reference data for implementors.    The documentation will need to be massaged by the technical writing team for Fabric and adapted for use in the correct locations."
Answer: 117847.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: "BYFN capabilities are not yet at  V1_4_3 or V2_0 level.    Cryptogen is running with Node OU enabled, which no longer populates admincerts directory.    However the orderer and peers without the latest capabilities enabled will not be identifying admins via Node OUs, they will still be identifying admins via admincerts directory. Without the directory populated, BYFN fails with error:   {code:java}  12:33:25 [34m2019-10-04 16:33:25.720 UTC [channelCmd] InitCmdFactory -> INFO 001[0m Endorser and orderer connections initialized  12:33:25 Error: got unexpected status: BAD_REQUEST -- error validating channel creation transaction for new channel 'mychannel', could not successfully apply update to template configuration: error authorizing update: error validating DeltaSet: policy for [Group]  /Channel/Application not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied  12:33:25 !!!!!!!!!!!!!!! Channel creation failed !!!!!!!!!!!!!!!!  12:33:25 ========= ERROR !!! FAILED to execute End-2-End Scenario ===========  12:33:25   12:33:25 ERROR !!!! Test failed  {code}"
Answer: 1002.0

User story: "Go >= 1.13 adds a wealth of optimizations, speed improvements, and new features including: full mod packaging support, a more uniform set of number literal prefixes, error wrapping, and much much more.     The Go FabSDK has recently been updated to support Go 1.13. Teams using go for chaincode and the sdk would benefit significantly by having uniform tooling, packaging, and build environments.    Given that the Fabric 1.4 release is an LTS, we were originally hesitant to jump from the current specified go version (1.11) to 1.13, however, we've noticed zero negative impact."
Answer: 48839.0

User story: "Acceptance:    An end-to-end test against a solo network and Golang chaincode can be executed without docker. In particular, the chaincode binary is compiled for the host platform, the peer that is launched points to a custom no-op builder, and the launcher simply executes the chaincode with the correct flags and environment variables."
Answer: 30121.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 generation of a system channel genesis block is not a core function of the orderer. Even though it could be somewhat useful in test environments, from a technical perspective, it requires the orderer to include and use the "sample" {{configtx.yaml}} in addition to the orderer's own {{orderer.yaml}}.    From a process and deployment perspective, it's better to have the system channel genesis block explicitly created by administrators with real names than to rely on fixtures that were originally intended for test.    For these reasons, we should remove the provisional genesis method from the orderer, it's associated artifacts, and documentation. The removal should be highlighted in release notes.    Acceptance: code supporting "provisional" is gone, documentation for the feature is removed, and a release note highlighting the removal is created.
Answer: 60568.0

User story: "With the removal of the fabric/chaincode/shim and dependencies from the v2 ccenv, chaincode packaged for previous releases can't be built with by a 2.0 peer.    It's inevitable that previously built chaincode docker images will be removed and, when that happens, the previously installed 1.x chaincode will need to be built by a 2.x peer. This will fail for go chaincode when using the 2.x version of ccenv.    To help get out of this mess, we need to verify that the peer can be successfully configured to use the hyperledger/fabric-ccenv-1.4 as the builder image.    /cc [~<USER>, [~<USER>"
Answer: 21037.0

User story: The peer currently uses the orderer endpoints it obtains from the channel config to communicate with orderers.  If the orderer addresses change, new peers will not be able to join channels as join channel requires the initial configuration block for a channel which will have endpoints which no longer exist.    As a stop gap, we will add an orderer endpoint override section to the peer config.  It will be a map of "old address"->"new address".
Answer: 54921.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "[~<USER> highlighted something about the launch contract that we should try to address moving forward.    The client key and client cert that we provide to the chaincode are base64 encoded PEM blocks while the root certificate is simply the PEM block.    The base64 encoding of the PEM blocked (already encoded) certificate is really weird... Unfortunately, we can't just change it as existing chaincode will be decoding so we need to add mitigation/migration.    [https://github.com/hyperledger/fabric-chaincode-go/blob/8f8a45e6039e7bc0e03a042591b010317481f21d/shim/internal/config.go#L48-L67]    The thought is that we can create two new files that contain the pem blocks (instead of base 64 encoded pem blocks) and use new keys to reference them. The old config and format would be deprecated and ultimately removed.    This will impact the run step of the launcher as well (in a different story)...    The go shim should be updated to prefer the non-double-encoded certificates. Node and java should not.    Acceptance: I can run chaincode build with the old and new go chaincode shim."
Answer: 47271.0

User story: "There are some comment errors"
Answer: 8434.0

User story: "*1. Symptoms*    When SW BCCSP is set as default BCCSP provider and 'fileKeystore.KeyStorePath' config for SW BCCSP is empty, the path '[MSP directory]/keystore' is used as keystore path without error.    But when Fabric is built with pkcs11 tag and PKCS11 BCCSP is default BCCSP provider, it causes error and Fabric node(peer/orderer) fails to start under same condition.   The 'fileKeystore.KeyStorePath' config of both SW and PKCS11 should be set for removing the error.    Even though PKCS11 BCCSP does not need keystore, It fails to start because the logic in the PKCS11Factory only checks 'FileKeystore' config - it should also check 'KeyStorePath' under 'FileKeystore'.    *2. Enhancement suggestions*    I suggest 2 changes like below :   - Set default keystore path( [MSP directory]/keystore ) for SW BCCSP not only default BCCSP provider is SW, but also BCCSP just when config for SW is set(not nil).   - Check BCCSP 'FileKeystore.KeyStorePath' config of PKCS11 BCCSP, set DummyKeystore if the config is empty( zero length ).      !image-2019-09-16-10-33-58-805.png!        "
Answer: 5142.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 existing chaincode platforms can package, carry, and extract _metadata_ associated with a chaincode. The ledger component uses this to documents necessary to create couch DB indexes.    The {{release}} or {{build}} phase of an external builder should be responsible for providing this information to the peer by populating a directory with the metadata documents. These documents must then be saved and provided to the ledger (where appropriate).    The current proposal reads like this:    {quote}  * Chaincode /bin/release (optional)    `release` is called to generate metadata necessary to control how the peer starts the application.    The executable is called with two arguments:    - the directory that was populated by `build` with the artifacts required to run the chaincode  - a directory to be populated by `release` with a metadata and assets    The details have not been worked out but there are two kinds of information we're expecting:    - metadata like CouchDB indices that have been extracted from chaincode to be consumed by the peer  - information about the location and assets necessary for a peer to connect to running chaincode that will not be started by the peer  {quote}    In retrospect, some of that seems a bit wrong. I believe we could actually use {{build}}/{{compile}} (whatever it's called) to populate the metadata as well as the runtime assets. That would mean that {{release}} is truly optional and only necessary to provide assets necessary for the peer to connect to chaincode.    Acceptance: The build script is provided a fourth directory to (optionally) populate with metadata. Upon completion of the build process, this metadata is captured and made available to the ledger. An existing chaincode that requires a CouchDB index can be deployed and executed using the external builder."
Answer: 54806.0

User story: "Remove references to GOPATH from tools, scripts, tests, artifiacts paths, etc, throughout fabric-test repository. Redesign as needed."
Answer: 17304.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "in module mode, go will often access remote VCS repositories to validate pinned versions are valid with respect to expectations at the time the go.sum file was written. Alternatively, if a go.sum is not written, the repositories will be accessed to check for version information and tags. This is expensive.    To reduce the cost, go can be configured to point to a proxy that hosts indexes for packages and calculated sums. The google go team hosts proxy.golang.org for publicly accessible repositories.    Acceptance: During build and test, if I have {{$GOPROXY}} configured, it uses my configuration. This includes containerized chaincode builds. If the proxy is not explicitly configured, it should be conditionally set to [https://proxy.golang.org|https://proxy.golang.org/].    In addition to inheriting and honoring the calling environment, this should allow end-users to provide their own proxy configuration when using private repositories.    The environment variable only *needs* to be set for the golang platform.   Integration test configuration should whitelist GOPROXY."
Answer: 46472.0

User story: "Today Fabric-Test Makefile has references to Gerrit for cloning repos. These references need to be updated to point to GitHub instead. We are migrating as early 9-16-2019 Fabric CA which will cause clones from the Fabric-Test repo to fail    For reference:  {code:java}  cd fabric-test    grep -r gerrit regression    grep -r gerrit tools    grep gerrit [MR]*  {code}"
Answer: 118171.0

User story: "Currently, the e2e test to use the external builder fails and falls back to the docker build."
Answer: 5607.0

User story: "Currently a fabric-cli plugin is defined as an executable which is wrapped by a cobra command. This has its limitations in that custom flags for the command are ignored and long descriptions and examples cannot be provided.    The fabric-cli plugin mechanism should also recognize commands that are defined using Go plugins. A Go plugin can return a full cobra sub-command which provides all of the features mentioned above."
Answer: 1447.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: *Background:*    Currently in Hyperledger Fabric, new peers joining a channel can only get the orderer locations from the channel genesis block.  Once joined to a channel, any change to orderer locations will be pushed as a channel config block so the peers are able to update.         The problem is, if the orderer locations have changed at any point during the life of the channel, new peers joining that channel have no way to get the current, correct location of the ordering nodes since the genesis block will have old information and the peers don't have access to anything else.         I believe there is work slated for maybe Fabric 2.0 (or later) to allow peers joining the channel to pull the orderer locations (and perhaps other data) from the latest channel config block vs only the genesis block.  This seems like the proper way to solve this long term, but we need a 1.x based solution to hold us over until then and this is what this story is meant to address.         *Proposed Change:*    After some internal discussions we believe that the best solution to this problem until the long term fix shows up is to add a section to core.yaml to provide an additional set of  orderer locations the peer could check when joining a channel if none of the original orderer locations were valid.    I say "none" because my thinking is as long as the peer was able to connect to one of the orderers and join the channel, it could then get the locations of the rest of the orderers from the channel configuration it gets after it joins.  The logic could of course be to check the core.yaml block if any of the orderers listed in the genesis block didn't exist or to check it every time.    I'm told there is precedence here since the same thing was done for TLS certificates, so I suspect the exact same logic would apply.
Answer: 100740.0

User story: "As a *temporary* workaround during the transition to modules, honor go.mod files that are part of a chaincode package. This is likely to do more harm than good so it needs to be short lived."
Answer: 362.0

User story: "High level story for enhancing block storage index."
Answer: 7833.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "* Add a peer node command so that the dbs in old format can be dropped   * Improve the log message pointing to the above command, in case user forgets to execute the above command and starts the peer    Specifically:  - Added peer node command upgrade-dbs to upgrade ledgerProvider db and drop other dbs that will be rebuilt upon peer restart  - Added peer node command rebuild-dbs to drop dbs so that they will be rebuilt upon peer restart"
Answer: 41116.0

User story: "*Overview*    Some Fabric networks have seen issues with excessive gossip communications, memory usage, or grpc max message size.    We have an opportunity to improve some of the default peer settings, for example I propose:  {code:java}  CORE_PEER_GOSSIP_USELEADERELECTION = false   CORE_PEER_GOSSIP_ORGLEADER = true   CORE_PEER_GOSSIP_MAXBLOCKCOUNTTOSTORE = 10   CORE_PEER_GOSSIP_STATE_ENABLED = false  CORE_PEER_GOSSIP_STATE_BLOCKBUFFERSIZE = 20    CORE_PEER_GOSSIP_STATE_BATCHSIZE = 10  {code}  *More details*    We have found that unless there are a large number of peers in an organization, it is more efficient to have peers pull blocks directly from orderer nodes, by using this configuration:  {code:java}  CORE_PEER_GOSSIP_USELEADERELECTION = false   CORE_PEER_GOSSIP_ORGLEADER = true   CORE_PEER_GOSSIP_STATE_ENABLED = false  {code}  If there are a large number of channels or large block sizes, reduce the size of these configurations from default of 100 to improve memory usage (the latter setting is not needed if CORE_PEER_GOSSIP_STATE_ENABLED is false):  {code:java}  CORE_PEER_GOSSIP_MAXBLOCKCOUNTTOSTORE = 10   CORE_PEER_GOSSIP_STATE_BLOCKBUFFERSIZE = 20    {code}  And if the block sizes are so large that you risk hitting grpc 100MB limit, reduce this setting (again, not needed if CORE_PEER_GOSSIP_STATE_ENABLED is false):  {code:java}  CORE_PEER_GOSSIP_STATE_BATCHSIZE = 10  {code}  The CORE_PEER_GOSSIP_STATE_* settings were added in v1.4.1 and above.    These are proposed tactical improvements, while longer term improvements are identified in FAB-15317."
Answer: 445454.0

User story: "We need to announce deprecation of the Kafka-based orderer given Raft provides the equivalent trust model, has additional features and is easier to manage and operate.  Fabric 1.4.2+ has the ability to migrate from Kafka to Raft.    Personally, I'd like to actually remove Kafka support in Fabric 2.0.0 but if not, we should announce and then remove in a 2.x version."
Answer: 142574.0

User story: "Update fabric-samples."
Answer: 49.0

User story: "See discussion in https://gerrit.hyperledger.org/r/#/c/fabric/+/32976/4/core/tx/processor_factory.go@94"
Answer: 5752.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 a hyperledger fabric user, I have a suggection for chaincode "marbles02_private" in fabric-samples .         In the front of source,     !image-2019-08-21-09-53-44-824.png!    When I started the tutorial using that chaincode command,    but i recieved error massesge below.      (environmet : host O/S- windows7, virtual O/S - ubuntu, I think that some users will have same errors)         <json parsing error>    !image-2019-08-21-09-53-18-785.png!    So, I suggest that add "tr -d \\n" at the back of export sentences.    !image-2019-09-02-14-19-23-179.png!         Change export expression, it works!    !image-2019-08-21-09-52-46-211.png!          
Answer: 23787.0

User story: "The sanitycheck function was a well intentioned bit of function that was never completed.  As such, it's a maintenance burden and drags a number of unwanted fabric dependencies into the configtxlator tool."
Answer: 1415.0

User story: As a hyperledger fabric user, I have a suggection for chaincode "marbles02_private" in fabric-samples .         In the front of source,     !image-2019-08-20-16-12-16-036.png!    When I started the tutorial using that chaincode command,    but i recieved error massesge below.      (environmet : host O/S- windows7, virtual O/S - ubuntu, I think that some users will have same errors)         <json parsing error>    !image-2019-08-20-16-18-39-179.png!    So, I suggest that add one more comment.    // When parsing error "invalid character '\n'", adds tr -d \\n    // ex) export MARBLE=$(echo -n "\{\"name\":\"marble1\",\"color\":\"blue\",\"size\":35,\"owner\":\"tom\",\"price\":99}" | base64 | tr -d \\n)               !image-2019-08-20-16-25-27-076.png!         Change export expression, it works!    !image-2019-08-20-16-27-50-488.png!          
Answer: 1046.0

User story: "https://gerrit.hyperledger.org/r/c/fabric/+/32833/4/internal/peer/node/start.go#313"
Answer: 136414.0

User story: "The security check that renders the 1.x lifecycle its security guarantees is the instantiation policy.  However, to my knowledge, nowhere in our integration tests do we actually verify that violating the instantiation policy prevents chaincode execution.  It is very likely that a custom RW set will need to be generated in order to exercise this path."
Answer: 141002.0

User story: "Today, we are storing packages on the filesystem as '.bin' files.  Since they are in fact tar.gz files, this doesn't make a ton of sense.  This should be a fairly trivial change."
Answer: 10846.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: "BlockIndex, StateLevelDB, and HistoryLevelDB enable sync when the data is written to the DBs. When sync enabled, a fsync system call is called after every write. The fsync system call flushes the data on a page cache (memory) to a disk. Although the fsync system call guarantees to persist the data, it has large overhead because it does not return during writing the data to a disk. Since the writes to the DBs are done by a single committer goroutine, they affect the performance significantly.    I propose to disable sync for BlockIndex, StateLevelDB, and HistoryDB. This should be possible because the DBs can be recovered from block files, which contents are still written to a disk with fsync system calls, even when a system crashes before writing the data to the DB files from memory.    This is a prototype for these changes [https://gerrit.hyperledger.org/r/c/fabric/+/32807.]    These changes gives 15% TPS improvement for a simple benchmark which sends a single PutState transaction iteratively."
Answer: 77107.0

User story: "Many tests will need to change to use the new interfaces, to remove the install/instantiation steps and replace with approve/commit etc. In the current format, that means editing lots of runCases files and json test description files under CITest/ directory. In the new system test framework for k8s, it means changing the test input specification file. In addition, the tools and command functions must all be added. There will likely be many pieces to merge for this."
Answer: 441128.0

User story: "By default, when a process is started, it inherits the environment of its caller. In the context of external chaincode, the environment of the peer is propagated to the builder. Given most users of the peer rely on environment variables to influence the configuration, it's quite likely that sensitive information is accessible in the environment.    In order to reduce the likelihood of information leaks via the environment, the external build configuration element in the peer should be extended to support and environment variable name whitelist. Any environment keys in that list will be propagated to the external builder.    The default list should contain PATH, LIBPATH, and TMPDIR. It's likely that environment variables like http_proxy/HTTP_PROXY will be added by users."
Answer: 63325.0

User story: "Currently, there are about 30 hyperledger fabric shim api.    But according to [https://github.com/hyperledger/fabric-samples/] ,     I can't find some examples of shim api below.(GoLang)   # GetArgsSlice() ([]byte, error)    # GetChannelID() string         !image-2019-08-06-15-18-36-155.png!    !image-2019-08-06-15-19-03-553.png!         For hyperledger users, there should be more examples of functions in the sample source.    Best regards!     "
Answer: 21306.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: "Reconciliation should be intelligent enough to not retry pulling private data forever, based on some new configuration settings.    This may be important in the following scenarios:   * private data is not available on any collection member, either because it was missing from the start, the peers that had the private data have gone away from the network, or peers had archived old blocks or have been more recently bootstrapped from a later snapshot.   * In some network level backup/restore scenarios, it may be acceptable to restore peers to a lower height than ordering service, implying that the private data between the heights is now missing."
Answer: 223833.0

User story: "The first pass of the detect, compile, launch infrastructure was implemented with a collection of  command line switches. This will become unwieldy over time as implementers will have difficulties ignoring unknown flags and parameters - especially flags that accept values.    Instead we should remain consistent with the buildpack model that already exists - namely, we provide a list of directories that contain extracted files. If we need to provide more data, we can add an additional argument or populate additional files. This means that implementations should ignore extra arguments as a general rule until they know what they point to.    launch receives directory containing metadata, the source the directory, the output directory from build, and an artifacts directory that contains file necessary for launch (key, cert, address, etc.). The artifacts must have well known names.    Acceptance: external scripts do not need to process flags; existing parameters are reworked to fit this model."
Answer: 56640.0

User story: "The first pass of the detect, compile, launch infrastructure was implemented with a collection of  command line switches. This will become unwieldy over time as implementers will have difficulties ignoring unknown flags and parameters - especially flags that accept values.    Instead we should remain consistent with the buildpack model that already exists - namely, we provide a list of directories that contain extracted files. If we need to provide more data, we can add an additional argument or populate additional files. This means that implementations should ignore extra arguments as a general rule until they know what they point to.    build should receive receive arguments for the metadata directory, a directory containing the extracted source, and a directory for it to store its output.    Acceptance: external scripts do not need to process flags; existing parameters are reworked to fit this model."
Answer: 56640.0

User story: "The dependency on bccsp prevents proper structuring of the code and will result in a rewrite of the package. The proposal from [~<USER> is to remove the code and, if we need to recreate it, we can do it when the package has been extracted from fabric.    Acceptance: there are no fabric dependencies in shim extensions other than the protos."
Answer: 20171.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 first pass of the detect, compile, launch infrastructure was implemented with a collection of  command line switches. This will become unwieldy over time as implementers will have difficulties ignoring unknown flags and parameters - especially flags that accept values.    Instead we should remain consistent with the buildpack model that already exists - namely, we provide a list of directories that contain extracted files. If we need to provide more data, we can add an additional argument or populate additional files. This means that implementations should ignore extra arguments as a general rule until they know what they point to.    detect should be provided a directory containing metadata.json (holding metdata as a basic map) and a reference to a directory containing the exploded source.    Acceptance: external scripts do not need to process flags; existing parameters are reworked to fit this model."
Answer: 60784.0

User story: "Presently, the code package file is determined by process of elimination.  This dates back to the original requirement for CAR compatibility, which was an archive format which was not a tar gzip, but was instead something else.  So, there was a need to be able to name a code package as 'Code-Package.tar.gz', or 'Code-Package.car' in order for commodity tooling not to get confused.      We have since dropped support for  CAR, so all archives can be required to be tar gzs.  Thus, let's require the package to be consistently named 'code.tar.gz'.    This has impacts in the peer CLI, the Java SDK, and the Node SDK."
Answer: 26722.0

User story: If admin certificate that is stored in the ledger expire, there is no way to update it. This locks all administrative operations in the blockchain.     This is edge case, but is very dangerous, because it "locks" the system in the current state. Endorsement and commits will work, but chaincode cannot be upgraded.    Adding some mechanism to update the admin certificate may open security issues, so the best option, in my opinion, is to notify the administrators in some way, lets say 1 month before expiration, so they can add new certificate before the expiration.
Answer: 9673.0

User story: "Hi,         I followed the following steps:    I define 3 Organisations in the config.tx and one channel profile in which consortium contains only 2 organisations.         I generated the artifacts and started the services on docker.    I created the channel and run the join command for the 2 organisation peers which were part of the consortium.         But when I tried to join the 3rd organisation peer, the command for the joins runs successfully and I can see the channel in the peer channel list.         So I think it not be able to Join the channel if it is not a part of the consortium.         In the peer logs of 3rd organisation I can see this:    ERRO 03b [korechain] Got error &\{FORBIDDEN}         And in the orderer logs:    Principal deserialization failure (MSP Org3MSP is unknown) for identity 0"
Answer: 17278.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: "These checks have no business existing, let alone in the validation paths.    Most of them can be performed trivially inside of a chaincode for invocation purposes, and system chaincodes should have real endorsement policies which govern commitment to their state."
Answer: 31018.0

User story: "See https://gerrit.hyperledger.org/r/c/fabric/+/32416/11/core/container/externalbuilders/externalbuilders.go#26    When creating the temporary directory, remove any character other than alphanumeric characters. This will address path separators and special characters that may need special treatment by scripts (eg. >< ! $ &, etc)."
Answer: 24608.0

User story: "There is a function 'Wait', in the current VM container API for chaincodes which is to allow the peer to monitor a running chaincode and, on its exit, deregister it from the map of chaincode handlers.  Presently, the externalbuilder implements this as a no-op {{select{ } }} waiting forever, as there is no way to determine the status of the chaincode.    It's unclear whether we want to implement this as a synchronous blocking call like 'Wait' before, or whether we want to use some health check mechanism etc., but if a chaincode terminates abnormally, as it stands today, the externalbuilder will never restart it."
Answer: 87710.0

User story: "This is currently ill defined, and we may decide that it is invalid.  Still, with existing chaincodes, particularly the docker ones, it is possible to stop a chaincode.  This is useful in integration style tests, and, would be nice to have for when a chaincode is no longer referenced in any channels, we could automatically stop it to conserve resources.  For this latter bit, we have seen users who deploy many iterations of a chaincode in development, and resource exhaust their machines as all copies remain running."
Answer: 168516.0

User story: "The assorted external builder components (detect, build, and launch), all currently lose the output of the commands.  For debugging build failures, or failures to detect etc., we should stream the standard error output of these invocations back to the peer logs.    Note: standard out will be reserved for communication with the process.    Acceptance: the output of 'detect', 'build', and 'launch', can be seen at debug level.  The output of 'build' and 'launch' can be seen at warning level when there is a failure. The log records should include some information about which process is generating the output."
Answer: 20274.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 external launcher stuff currently operates in a build context in a temporary directory.  This works, but, it means that whenever the peer is shutdown, the temp directory 'leaks' and needs to be cleaned up manually.  Additionally, the next time the peer starts back up, it has to rebuild all of the build contexts, including rebuilding any source code.    Acceptance:  Starting a peer, invoking a chaincode built by an external builder, restarting the peer and invoking that same chaincode should work, and the 'build' command should only be invoked once."
Answer: 87719.0

User story: "Convert genconfig.sh to go operator and read in pte input yaml file"
Answer: 99433.0

User story: "Create an input yaml file with pte parameters to run with operator and pte"
Answer: 48779.0

User story: "In an effort to maintain consistency as well as discussion in [https://gerrit.hyperledger.org/r/c/fabric/+/29132/5] let's rename all mentions of `PvtData`, `PrivateData`, `Privatedata`, `Privdata`, `PrivData` to Pvtdata and likewise for unexported fields/methods. Manish suggested that we treat Pvtdata as one entity hence one word. Let's also rename the `privdata` package in `gossip` as well"
Answer: 7453.0

User story: "  {code:java}  peer chaincode instantiate   {code}  does not support the {{--peerAddresses}} flag which is needed when using instantiation policies which require more than one org."
Answer: 42070.0

User story: As a consumer of the entities package, I want to avoid dependencies fabric packages and   their transitive dependencies.        *go list -f '{{join .Deps "\n"}}' ./core/chaincode/shim/ext/entities/... | sort -u* drags in    {code}  github.com/hyperledger/fabric/bccsp  github.com/hyperledger/fabric/bccsp/factory  github.com/hyperledger/fabric/bccsp/sw  github.com/hyperledger/fabric/bccsp/utils  github.com/hyperledger/fabric/common/flogging  github.com/hyperledger/fabric/common/flogging/fabenc  {code}    
Answer: 45212.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: *Background*    For a peer which is joined to a channel, if the peer's org is evicted from the channel (and cannot receive blocks), the peer will spend resources and spam log messages attempting to pull blocks from that channel forever.    *Objective*    Similar to the peer reset command, it would be very nice to add an option to simply delete the channel blockchain on the org's peer, effectively 'unjoin'ing the channel.    *Proposal*    When a peer is unjoined from a channel, ideally all the ledger data for the channel should be deleted from the peer. However, because a single instance of golevelDB is used for each store (except for blockstore), it is not feasible to delete ledger data at a per-channel basis.  Therefore we propose the following design:      Add a “peer node unjoin -c <channelID>” command (peer must be stopped).  The unjoin command will:    * tag the channel as "unjoined" in the peer's ledgerProvider database so that the channel does not get initialized upon next peer start.  * delete the channel's blockstore from the peer's /chains directory    Note that the channel data will not get deleted from the other internal cross-channel data stores. It will be orphaned (unreferenced from peer).    Once tagged as "unjoined", the peer will not be able to re-join the channel (since there is orphaned data for that channel).    If a peer administrator wants to completely delete the channel data from the internal cross-channel data stores, or wants to rejoin the peer to the channel, they can do a "peer node reset" which truncates all channels to genesis block and deletes the internal cross-channel data stores. As of this proposal it will also remove any channels tagged as "unjoined" in ledgerProvider database. Upon next peer restart, the peer will automatically pull blocks and rebuild the internal cross-channel data stores for the remaining joined channels.       *Future enhancement:*    Once ledger has truly per-channel databases in a future release, it will be possible for the unjoin command to immediately delete all data for the channel.
Answer: 110862.0

User story: "From [https://docs.google.com/document/d/1BBVA8u-GJ99ZYRT015PAnMVK4_pKv53Y-kiP9lZX8Gc/edit#] we propose passing in a new `TxProcessorFactory`, `PrivateDataProvider`, and `ChannelConfigProvider` to the ledger initializer. Much of the logic for the implementation of PrivateDataProvider will come directly from the existing logic in gossip coordinator's StoreBlock"
Answer: 108079.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: "Define configuration for peer builder/launcher plugin roots in {{core.yaml}}. The configuration should be a list of directories. The order of the directories specifies the order in which the {{detect}} portion of the protocol will be executed.    Example:  {code}  chaincode:    external_builders:    - some/filepath/one # should contain some/filepath/one/bin/detect    - some/filepath/two # should contain some/filepath/two/bin/detect  {code}    When relative paths are used, they are treated as relative to the directory containing {{core.yaml}} instead of the current working directory. This is consistent with other configuration data."
Answer: 1321.0

User story: Create a new github repository called {{fabric-protos-go}} and populate it with a {{protos}} directory that contains the fabric {{protos}}, the necessary LICENSE, CODE_OF_CONDUCT.md, CONTRIBUTING.md, and README.md.    This repository should not be a read-only mirror of gerrit but a simple github repo.    The repository should be configured not to accept pull requests (stale-bot or settings). The fabric release managers should be configured with write access to handle "unexpected" issues that may arise.
Answer: 53661.0

User story: The ledger currently maintains a small number of protobuf files outside of the protos tree. The goal was to prevent these from being consumed as fabric "api" but, in reality, they're used in the blockchain marshaling and, as such, are part of the surface area of the project.    In order to enable tools outside of the core fabric tree to decode and use these datatypes, the protos should be promoted into the protos tree, the bindings should be generated from there, and the ledger component updated to pull in the new imports as appropriate.    Acceptance: protos are in a sub-directory of the {{protos}} tree and the generated go bindings live in a package rooted under {{protos}}.
Answer: 44965.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 are number of places where {{bccsp/factory#GetDefault()}} is used to get a BCCSP implementation. Each call site should be evaluate in context.    Where an actual implementation is needed, instead of asking for the implementation, the required instance should be explicitly provided and wired to the consumer.    Where the implementation is being used for software crypto operations in test, consider replacing it with basic go crypto.    As of current master, the following packages seem to be impacted:    {code}  token/tms/plain/verifier.go  token/client/grpc.go  core/ledger/kvledger/txmgmt/rwsetutil/query_results_helper_test.go  core/ledger/kvledger/txmgmt/rwsetutil/query_results_helper.go  core/chaincode/accesscontrol/mapper_test.go  core/chaincode/shim/ext/entities/testutils.go  core/chaincode/shim/ext/entities/entities_test.go  core/common/ccprovider/cdspackage.go  core/common/ccprovider/sigcdspackage.go  internal/peer/gossip/mcs.go  internal/peer/gossip/mcs_test.go  internal/peer/common/common.go  common/util/utils.go  msp/mspimpl.go  msp/configbuilder.go  {code}    Acceptance: {{bccsp.GetDefault}} and its associated package level state is gone or an unprioritized story has been created that details the complexity involved in removing the reference."
Answer: 134978.0

User story: As a consumer of the statebased package, I want to avoid dependencies on fabric/comm, fabric/protoutil, pkg/errors, and their transitive dependencies.    {go list -f '{{ join .Deps "\n" }}' ./core/chaincode/shim/ext/statebased} show the following fabric packages are dependencies of the statebased package. Most of these are transitive deps that are pulled in by references to {{common/cauthdsl}}.    The {{protoutil}} import drags in deps on {{internal/pkg/identity}}.    {code}  github.com/hyperledger/fabric/bccsp  github.com/hyperledger/fabric/bccsp/factory  github.com/hyperledger/fabric/bccsp/idemix  github.com/hyperledger/fabric/bccsp/idemix/bridge  github.com/hyperledger/fabric/bccsp/idemix/handlers  github.com/hyperledger/fabric/bccsp/signer  github.com/hyperledger/fabric/bccsp/sw  github.com/hyperledger/fabric/bccsp/utils  github.com/hyperledger/fabric/common/cauthdsl  github.com/hyperledger/fabric/common/flogging  github.com/hyperledger/fabric/common/flogging/fabenc  github.com/hyperledger/fabric/common/policies  github.com/hyperledger/fabric/idemix  github.com/hyperledger/fabric/internal/pkg/identity  github.com/hyperledger/fabric/msp  github.com/hyperledger/fabric/protos/common  github.com/hyperledger/fabric/protos/msp  github.com/hyperledger/fabric/protos/peer  github.com/hyperledger/fabric/protos/token  github.com/hyperledger/fabric/protoutil  {code}    Acceptance: The only fabric imports are the protos.
Answer: 6334.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: "Create a build process for {{fabric-chaincode-go}}. This process should lint the code (yes, lint - including godoc), vet the code, and run tests.    The build process should be tied into github to ensure that the code is tested prior to merge.    Acceptance: change requests cause a build and test to occur. Successful builds result in a +1 vote and failed builds result in a -1 vote."
Answer: 99148.0

User story: "Keeping with the general pattern of {{fabric-chaincode-_language_}}, create a {{fabric-chaincode-go}} repository that will hold user consumable chaincode packages.    The repostiory should be updated with the typical boilerplate license, readme, contributing, etc.    This repository should be a v0 (unversioned) go module and should include {{go.mod}} and {{go.sum}} files but should *not* contain vendored dependencies. The goal is for this code to be consumed as a library by chaincode processes and we want to provide as much flexibility as possible.    Discussion: gerrit with github mirror? If gerrit, NACR review policy using the same maintainer list as fabric.    Acceptance:  1. I can build a chaincode program outside of a GOPATH that uses the shim from {{fabric-chaincode-go}}.  2. I can build a chaincode program within a GOPATH that explicitly vendors the shim from fabric-chaincode-go."
Answer: 67140.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 chaincode shim depends on a number of fabric packages. We need to isolate and remove the dependencies on these packages so we can move the chaincode shim to a separate repository that only relies on:    - go standard library  - grpc and its direct dependencies  - fabric protobuf definitions    In particular, {{go list -f '{{join .Deps "\n"}}' ./core/chaincode/shim | sort -u}} shows that the following fabric packages are imported:    {code}  github.com/hyperledger/fabric/bccsp  github.com/hyperledger/fabric/bccsp/factory  github.com/hyperledger/fabric/bccsp/idemix  github.com/hyperledger/fabric/bccsp/idemix/bridge  github.com/hyperledger/fabric/bccsp/idemix/handlers  github.com/hyperledger/fabric/bccsp/signer  github.com/hyperledger/fabric/bccsp/sw  github.com/hyperledger/fabric/bccsp/utils  github.com/hyperledger/fabric/common/capabilities  github.com/hyperledger/fabric/common/cauthdsl  github.com/hyperledger/fabric/common/channelconfig  github.com/hyperledger/fabric/common/configtx  github.com/hyperledger/fabric/common/flogging  github.com/hyperledger/fabric/common/flogging/fabenc  github.com/hyperledger/fabric/common/ledger  github.com/hyperledger/fabric/common/metadata  github.com/hyperledger/fabric/common/metrics  github.com/hyperledger/fabric/common/policies  github.com/hyperledger/fabric/common/util  github.com/hyperledger/fabric/core/comm  github.com/hyperledger/fabric/idemix  github.com/hyperledger/fabric/internal/pkg/identity  github.com/hyperledger/fabric/msp  github.com/hyperledger/fabric/msp/cache  github.com/hyperledger/fabric/protos/common  github.com/hyperledger/fabric/protos/ledger/queryresult  github.com/hyperledger/fabric/protos/msp  github.com/hyperledger/fabric/protos/orderer  github.com/hyperledger/fabric/protos/orderer/etcdraft  github.com/hyperledger/fabric/protos/peer  github.com/hyperledger/fabric/protos/token  github.com/hyperledger/fabric/protoutil  {code}    Acceptance: The only remaining dependencies on code from the "hyperledger/fabric" repo are proto bindings for messages.    With respect to comm, we will explicitly code the default values of the client side options for grpc. If we need to export the ability to configure these, we'll do that later and in a separate story.
Answer: 20665.0