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: "Refer to [https://wiki.hyperledger.org/projects/fabric/proposedv1_1] and the New Feature JIRA blocking this.    txid , event name , tx validation indicator   And we could use that info for subsequent queries or verification.       ----  Interface tests utilize the sample deliver client to connect to a Peer Deliver API and receive filtered block events on a channel level.    Peers are referred to by PO<org#><peer#>. eg. PO11    Network Topology:   * e2e_cli example with TLS disabled: 2 org, 2 peers per org joined to channel1   * modification: additional channel2 with PO11 joined, cc installed and instantiated    Execution:   # Deploy e2e_cli network, execute cli script and pause prior to invoking.   # Using sample deliver client [https://github.com/hyperledger/fabric/blob/master/orderer/sample_clients/deliver_stdout/client.go]    connect multiple sample deliver clients *with block filtered enabled* and retrieve all blocks and listen forever. Note that each of these clients should receive the genesis block for the channels they are connected to:   ## PO11 on channel1 (DC1-1-1)   ## PO11 on channel2 (DC1-1-2)   ## PO21 on channel1 (DC2-1-1)   # Execute normal cli scripts with modifications for *channel2*.   # Connect new deliver client to PO11 channel1 and retrieve all blocks for channel1 and listen forever.   ## compare results with DC1-1-1 in step 2   # Invoke a new transaction on channel1.   # After a few minutes, connect new deliver client to PO12 channel1 and retrieve latest block for channel1 and listen forever.   ## compare results with DC1-1-1 in step 2   # connect new deliver client to PO21 channel1 and retrieve block 2 and disconnect.   ## compare results with DC1-1-1 in step 2   # Invoke new transaction on channel2.   ## check output of DC1-1-2 and confirm that new block is received.   # connect sample deliver client to PO12 *channel2* and confirm that *no blocks can be retrieved*.   # Join PO12 to *channel2*, rerun step 9 and confirm that all historic blocks are retrieved.     Test passes if:   * All block events received by the deliver clients are *filtered*.   * All block events on channel1 are printed by DC1-1-1 DC2-1-1.   * All block events on channel2 are printed by DC1-1-2.   * All block events on channel1 are retrievable by all peers.   * All block events on channel2 are retrievable only by PO11 and PO12 (after PO12 has joined channel2)."
Answer: 955397.0

User story: "Refer to https://wiki.hyperledger.org/projects/fabric/proposedv1_1 and the New Feature JIRA blocking this."
Answer: 155211.0

User story: "Refer to https://wiki.hyperledger.org/projects/fabric/proposedv1_1 and the New Feature JIRA blocking this."
Answer: 1210007.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: "systest FAB-6122 v1.1 upgrades subtasks 6123 fabric, 5676 shim, 5556 capability enabling      {color:#000000}References:{color}   # [https://docs.google.com/document/d/16ZogU_InYeLZZ8lTGNdBhd4Iosi7T4KP3ppFSEUcI30/edit?ts=5a285ab9#heading=h.gfha2pfdu0uz]   # [https://github.com/<USER>fabric-prototype/blob/master/features/upgrade.feature]   # [https://wiki.hyperledger.org/projects/fabric/proposedv1_1] and the New Feature JIRA blocking this. This is a big effort. Ensure network is stable, secure, and able to correctly handle transactions while:     * upgrading all fabric network components (peers, orderers, kafkas, etc, and maybe CA servers and SDKs (see FAB-7116))   * all at same time OR only some at a time   * enabling new features with run-time flags when all (or when only some) components are upgraded"
Answer: 951671.0

User story: "Refer to https://wiki.hyperledger.org/projects/fabric/proposedv1_1 and the New Feature JIRA mentioned in the summary."
Answer: 90923.0

User story: "Refer to https://wiki.hyperledger.org/projects/fabric/proposedv1_1 and the New Feature JIRA mentioned in the summary.    In initial stage, verify system performance, to ensure no degradation of overall network throughput. Next stage should focus on measuring component perfomance improvements (in this case, the orderer)."
Answer: 90928.0

User story: "Refer to https://wiki.hyperledger.org/projects/fabric/proposedv1_1 and the New Feature JIRA mentioned in the summary"
Answer: 1210050.0

User story: "Refer to https://wiki.hyperledger.org/projects/fabric/proposedv1_1 and the New Feature JIRA mentioned in the summary"
Answer: 32052.0

User story: "Refer to [https://wiki.hyperledger.org/projects/fabric/proposedv1_1] and the new feature JIRA mentioned in the summary    FAB-5346 provides controls to manage each member's access to chaincode information.    Notes from chat channel:    We should read the attributes out of the ___ and use for member roles actions. We've mentioned previously that they are focused on ACL evaluation, and therefore even if there are changes to resource/policy configuration the ACL evaluation would still be relevant. I believe the ACL checks would be enabled regardless; what could be disabled/enabled would be rscc based resource/policy config - and if disabled then fall back to 1.0 permissions. The ACL calls will default to 1.0 behavior if RSCC is disabled OR if RSCC enabled and resources are not configured channel confi which is true (per Murali testing)."
Answer: 958298.0

User story: "Refer to [https://wiki.hyperledger.org/projects/fabric/proposedv1_1] and the New Feature JIRA mentioned in the summary.    FAB-830 provides an encryption library that allows customers to encrypt sensitive data that a chaincode processes and updates. This provides another level of security for highly sensitive data. To test, the chaincode simply must be able to encrypt and decrypt data, using library, per the sample provided by design team."
Answer: 57648.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: "Refer to [https://wiki.hyperledger.org/projects/fabric/proposedv1_1] and the New Feature JIRA mentioned in the summary.    Previously, all applications needed to capture information of the target fabric environment. The FAB-5363 enhancement generates a common exchange doc, with backend topology information. With this doc the application will no longer need to construct the channel, add peers, orderers and get the org admin, simplifying your application development."
Answer: 958307.0

User story: "Refer to [https://wiki.hyperledger.org/projects/fabric/proposedv1_1] and the New Feature JIRA mentioned in the summary.    FAB-2331 Node JS chaincode feature: provides additional implementation of chaincode that mirrors the current Golang version in functionality. The benefit is that when using the node SDK(although you can still use any SDK of your choosing) you are provided a full stack development model. This also helps the large Javascript developer community base with a familiar coding language.    We should test all APIs functionally, in nodeJS (in addition to GO language)."
Answer: 958308.0

User story: "Add function queryChaincodeData from peer then we can get endorsement policy from it for later use such send tx to corresponding endorsing peer with it."
Answer: 1212082.0

User story: About a week ago, I started a Clojure SDK as my pet project - <EMAIL>:ozjongwon/clojure-fabric.git         I got a suggestion from Gary Singh to gauge interest from the community.    Please feel free to add your thoughts.              *For more details about Clojure SDK, please keep reading.*         Currently almost all Clojure files (which are wrapper of Java files) were generated from Java SDK, and only 'core.clj' is my main focus at the moment. I am going to add some high level abstraction and hopefully the SDK grows as I learn more.         An example client code is like:       {code:java}  ;; Make a client  (defonce cli (get-or-make-client "Org1MSP"                                   "PeerAdmin"                                    (-> (slurp <private-key-file>)                                       (keys/str->private-key))                                   certificate-str                                   {}))  ;; Add an orderer  (add-channel-end cli "mychannel" (map->OrdererOpts {:name "orderer0" :grpc-url "grpc://localhost:7050"}))     ;; Add a peer  (add-channel-end cli "mychannel" (map->PeerOpts {:name "peer0" :grpc-url "grpc://localhost:7051"}))     ;; Proposal & order transaction  (->> (map->TransactionOpts {:fcn "createCar"                              :args (java.util.ArrayList. ["CAR10" "Chevy" "Volt" "Red" "Nick"])                              :proposal-wait-time 10000})       ;; Proposal Tx       (propose-transaction cli                            "mychannel"                            (make-ChaincodeOpts {:name "fabcar" :version "1.0" :path "resources/"}))        ;; Order Tx        (order-transaction cli "mychannel"))  {code}        
Answer: 1211158.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 can be thought of as a quasi-alternative to the proposal identified in FAB-6042.)    Similar to how we have the standard Readers/Writers/Admins policies under "/Channel/Applications/Policies", we introduce a new policy – let's call it "Instantiation". (A sensible default for it would be the majority of channel Admins.)    Instantiating chaincode "foo" begins with a proposal and works like the typical endorsement flow; once you have collected enough proposal responses to satisfy the "Instantiation" policy, you collect them into a transaction and broadcast this to the network via the ordering service.    This means that at any point in time, chaincode instantiation is defined by a single policy per channel; if participants wish to modify the policy, they just have to modify the value corresponding to "/Channel/Applications/Policies/Instantiation".
Answer: 1212684.0

User story: Currently the validator code creates an array of tx validation codes, initializes them all to "the transaction is valid" and then later the code may invalidate the tx by changing the value of the validation code. Any bug in the validation code (present or future) that causes validation to be skipped would permit an attacker to skip transaction validation altogether (because by default, the transaction is marked as valid). This goes against security principles; we should default to a secure position (e.g. the tx is invalid) and possibly relax that later if the code was able to determine that the tx was valid.
Answer: 306878.0

User story: "gRPC allows a server enforcement policy to be configured which sets a threshold for how often a client can send keepalive pings as well as whether or not to allow keepalives without an active streaming RPCs.    Currently, the default policy is being used and this only allows clients to send keepalive pings every 5 min.  Based on feedback of people running peers in various cloud environments behind load balancers, firewalls, etc, it seems that 1 min would be a better setting.    Finally, given that the policy will be less restrictive, the keepalive interval used for client connections (e.g. peer to orderer) will be lowered to 1 min as well."
Answer: 113.0

User story: "in the orderer/sample_clients/broadcast_config,the user can use the tool to create channel,but in the newchain.go,it doesn't assign the org,and i add a new option,the user can set the channel creation config,like the command `peer channel create`"
Answer: 1214864.0

User story: "As a network administrator we need to add additional organizations into a running network. Would like to have a video showing exactly how to do that, without bring down the network.    Would be good to start with a quick image of what is happening like a .ppt picture.    Afterward go through the process detailing out the process on addition."
Answer: 249470.0

User story: "Now that we can configure fabric to compile chaincodes dynamically, let chaincode authors bundle go plugins with their GOLANG chaincodes."
Answer: 63572.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: "fabric/examples/configtxupdate/README.md has some error."
Answer: 42096.0

User story: "when using fabric in a production environment, customer can write their own chaincode for business integration and deploy it to fabric network. While these chaincode may have bugs or not well tested, or have some performance problem, that may cause problems in production chain.    If there is a light-weight chaincode sanbox, the chaincode developer can upload their chaincodes to the sanbox, for syntax, performance or other factors(need more discuss here) verification, chaincode passed those verifications are ready to be used for the next step, like function test in a test environment. "
Answer: 1217992.0

User story: "We will propose two new extended API functions for Fabric's performance improvement, which has already been presented at P2PFISY2017.    Differential Update State (DUS) : an API function in which differential update operation (e.g. A:=A+X or A:=A-X) is executed in the peer side, allowing users to reduce the number of API functions they used in their chaincodes.    Compound Request (CR) : an API function in which multiple existent API functions are merged into one, allowing users to reduce the number of API functions they used in their chaincodes again.    We have already evaluated its efficiency for v0.6.1, where two extended API functions improve Fabric's transaction rate from 725tps to 1,350tps (86% increased). We are now evaluating it for v1.0."
Answer: 1218556.0

User story: "Because the epic is introducing a backwards incompatibility, we need a way to version MSP. The purpose of this item is to introduce an MSP factory that would allow the creation of MSP instances based on passed options that would specify the type of MSP to be created and its version."
Answer: 20772.0

User story: "Split the peer into the server and the client part. The peer binary will still be the server, while all client functions will be moved into the new fabriccli binary.    This change enables having different build strategies for the server and the client (for example dynamic vs static build, which is important for things like support for go plugins and PKCS11).    Also, this change is (hopefully) a step towards refactoring the fabric code so the fabric client protos and supporting libraries are decoupled from the server code. This way, the client API could be used by fabriccli and Go SDK (and potentially other Go based fabric client software) without having to depend on the whole fabric that includes the server code.    The separation will also reduce confusion due to `{{peer}}` doubling as CLI."
Answer: 1220011.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, it is not possible to override a submodule's log level at peer start (e.g. peer/gossip). Logic should be added to enable this.          In order to allow both yaml files and environment variables to override these levels, the submodule name should be provided in the form:  {code:java}  module_submodule{code}  This will allow the value to be set in yaml files:  {code:java}  peer:     gossip: warning{code}  as well as via environment variables:  {code:java}  CORE_LOGGING_PEER_GOSSIP=warning{code}"
Answer: 2714.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 was attempted in FAB-5930 however the upgrade was not complete. Certain grpc-go packages (including the core transport package) are still at an untagged version between 1.3 and 1.4.    Due to a [bug|https://github.com/grpc/grpc-go/issues/1401] in gRPC, the version currently vendored into fabric is incompatible with clients > v1.5. This forces clients to downgrade.    We propose to upgrade all grpc packages to the stable version 1.5.2     "
Answer: 1378.0

User story: "high-throughput chaincode has some spelling error"
Answer: 1792.0

User story: "When trying to join peer to a channel by sending the genesis block, the peer doesn't check whether it belongs to the channel or not, which results peer creating the ledger of the channel even when it actually doesn't belong to the channel. And later on, the error messages keep coming from orderer because the credentials do not match.    So, peer should check the organization info of a genesis block before creating a new ledger. This also can avoid(partially) peer cli sending false information."
Answer: 112703.0

User story: "Some command options and example are not written correctly in scripts of Network Launcher.    We need to modify usage comment for usability improvement. Also, we need to update README."
Answer: 50376.0

User story: "Noticed a couple of minor typos while reading on pages:    [https://hyperledger-fabric.readthedocs.io/en/latest/fabric_model.html]    [https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html]          "
Answer: 48238.0

User story: "Currently, fabric only support leveldb and couchdb.         Would support mongodb as another stateDB option."
Answer: 1227928.0

User story: {code:java}  $ docker-compose -f docker-compose-cli.yaml  up  WARNING: The CHANNEL_NAME variable is not set. Defaulting to a blank string.  WARNING: The DELAY variable is not set. Defaulting to a blank string.  WARNING: The TIMEOUT variable is not set. Defaulting to a blank string.  Creating network "net_byfn" with the default driver  Pulling cli (hyperledger/fabric-tools:latest)...  Pulling repository docker.io/hyperledger/fabric-tools  ERROR: Tag latest not found in repository docker.io/hyperledger/fabric-tools  {code}  There is no "latest" tag in hyperledger/fabric-tools ([https://hub.docker.com/r/hyperledger/fabric-tools/tags/]). I set this to medium because it would blocking the newcomer when starting their first network.
Answer: 434055.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "For orderer system channel, messages of type other than CONFIG or CONFIG_UPDATE are useless, and should be discarded instead of  being cut into block.    However, this is trickier than it sounds. we cannot do it in {{consenter}}, because it simply does not have knowledge to tell if it's system channel or not. So we need to do that at the entrance of broadcast, which means filtering EVERY ingress message. This is the overhead we want to avoid.    So, this story just documents this potential improvement, but not necessarily needs to be addressed due to reasons aforementioned."
Answer: 1228258.0

User story: Function [validateTx(...)|https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/validator/statebasedval/state_based_validator.go#L128] uses TxValidationCode(-1) as return value ([L136|https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/validator/statebasedval/state_based_validator.go#L136],  [L143|https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/validator/statebasedval/state_based_validator.go#L143],  [L150|https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/validator/statebasedval/state_based_validator.go#L150]), which is not a valid one defined in [transaction.proto|https://github.com/hyperledger/fabric/blob/master/protos/peer/transaction.proto#L125] and [transaction.pb.go|https://github.com/hyperledger/fabric/blob/master/protos/peer/transaction.pb.go#L19]. We should add one more TxValidationCode, "MVCC_READ_ERROR", to prototransaction.proto and update related go files.
Answer: 436721.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 chaintool expects <dir of chaintool.yaml>/src/chaincode/*.go as entrypoint    Support for greater nesting under chaincode so that src/chaincode/foo & src/chaincode/bar may be the only entries in src/chaincode, but passing e.g. chaintool package -e src/chaincode/foo would cause src/chaincode/foo to be treated as src/chaincode is currently.         Notes on item from <USER>   *    I would probably tie it to the :platform tag in the yaml   *    like line 18: [https://github.com/hyperledger/fabric-chaintool/blob/master/examples/example02/app/chaincode.yaml#L17|https://github.com/STTOOA/fabric-chaintool/blob/master/examples/example02/app/chaincode.yaml#L17]   *    Entrypoint: chaincode/ec     *    I __think__ all of this should be contained within src/chaintool/platforms/golang/userspace   *    theres some hard coded assumptions like this one: [https://github.com/hyperledger/fabric-chaintool/blob/master/src/chaintool/platforms/golang/userspace.clj#L210|https://github.com/STTOOA/fabric-chaintool/blob/master/src/chaintool/platforms/golang/userspace.clj#L210]   * here as well: [https://github.com/hyperledger/fabric-chaintool/blob/master/src/chaintool/platforms/golang/userspace.clj#L281|https://github.com/STTOOA/fabric-chaintool/blob/master/src/chaintool/platforms/golang/userspace.clj#L281]     *    it might just be those two places   *    nope: one more: [https://github.com/hyperledger/fabric-chaintool/blob/master/src/chaintool/platforms/golang/userspace.clj#L295|https://github.com/STTOOA/fabric-chaintool/blob/master/src/chaintool/platforms/golang/userspace.clj#L295]"
Answer: 1231744.0

User story: "Is it possible to make fabric-sdk-go and fabric run without docker?    So when I run peer node start --peer-chaincodedev=true and try again to run make in fabric-idk-go, following error appears:     {{2017-09-18 01:32:15.121 ULAST [chaincode] sendReady -> DEBU 656 handler not found for chaincode e1q81biqy3:v0}}   {{2017-09-18 01:32:15.121 ULAST [chaincode] Launch -> ERRO 657 sending init failed(handler not found for chaincode e1q81biqy3:v0)}}         {{What could the reason of this error?}}    {{thanks,}}    {{Ganbold}}     "
Answer: 210302.0

User story: """overriden"" in [https://github.com/hyperledger/fabric/blame/release/docs/source/msp.rst#L146] should be ""overridden"".     "
Answer: 2665.0

User story: "The documentation on submitting changes to Gerrit appears to be outdated. The current convention is to include the JIRA issue ID on the one-line commit message for readability in Gerrit."
Answer: 16907.0

User story: "Improve documentation for queries."
Answer: 269442.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: Now that we are building with Go 1.9, we can leverage support for Go-based plugins.  Given that BCCSPs are meant to be pluggable, the idea here is to implement a "plugin" provider.    The plugin provider will be simple:  - implement the bccsp interface  - config will take a path to a plugin module as well as a raw map[string]interface{}     The provider will load the plugin and simply call the matching exported methods.    It should be noted that that plugins will only be useful on Linux platforms, but that's fine since we also provide Docker images.
Answer: 41455.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 orderer benchmark permutations are hard-coded. Provide a way of running the benchmarks with arbitrary parameters."
Answer: 1238051.0

User story: "There have been a number of changes/enhancements to Fabric's logging package that should be reflected in the documentation to ensure the doc is still usable and easy to follow.    [http://hyperledger-fabric.readthedocs.io/en/latest/logging-control.html]"
Answer: 594599.0

User story: "After upgrade to 1.9 {{make proto}} command will update all proto files as new golang version cause to update message descriptors. In order to reduce conflicts files need to be updated."
Answer: 2729.0

User story: The setlevel regular expression currently updates the level for all logging modules that contain the supplied name. It should really only match loggers that start with the name.     For example, setting the level for "gossip" currently updates not only the expected gossip modules but also "peer/gossip/mcs" and "peer/gossip/sa". 
Answer: 7588.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: "FAB-4207 added endorser filters to the peer to allow preprocessing of a transaction. The utility of these filters is limited by the fact that the peer must be recompiled with changes to the source code to add a custom filter.    We propose to extend this functionality by allowing a deployer to dynamically link an authentication or decoration filter at runtime. This will be done using plugins that are available since Go 1.8.    In addition to loading filters as plugins, this change set will also allow for chaining of static and dynamic authentication filters. "
Answer: 32826.0

User story: "Add continuous integration section to fabric-test README."
Answer: 6939.0

User story: "There is quite a bit of historical context, but originally, channel config was supposed to be specified by some non-existent tool, and so the components were developed under the assumption that this tool would exist.  As the tool did not materialize, these components started hacking more and more pieces together for testing without the tool.  Finally, when it became apparent that there was no tool inbound, {{configtxgen}} was created in its stead, by cobbling together the assorted pieces of testing code from different packages to form a coherent configuration generation binary.    Unfortunately, this evolution of the configtxgen tool means that much of this code is spread throughout the fabric codebase, and in packages which really have nothing to do with bootstrapping or generating new configuration.  Additionally, the underlying configuration structures have changed so much since much of the code was written, that there are unneeded and unhelpful abstractions (like the configuration template concept) which serve only to obfuscate the way configuration is generated.    This story should encompass moving the bits of code from other packages like {{configtx}} and {{channelconfig}} under the  {{configtxgen}} package.  Additionally, the {{provisional}} package should be rewritten to mirror the more recent configuration parsing code, which directly operates on config groups."
Answer: 72550.0

User story: The following statement in the documentation on intro to Blockchain isn't all that clear:    "Rather than the “proof of work” some blockchain networks use to verify identity (allowing anyone who meets those criteria to join the network), the members of a Hyperledger Fabric network enroll through a *membership services provider*."    Link: https://hyperledger-fabric.readthedocs.io/en/latest/blockchain.html
Answer: 1241070.0

User story: "Provide a docker-compose environment that brings up a Kafaka + Zookeeper environment for use by the Orderer benchmarks found in {{orderer/server/benchmark_test.go}}.     "
Answer: 22836.0

User story: Added documentation to https://docs.google.com/document/d/16ZogU_InYeLZZ8lTGNdBhd4Iosi7T4KP3ppFSEUcI30  See the "Upgrading Fabric CA" section.
Answer: 171996.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: "Includes upgrade of Fabric binaries and docker images for peer, orderer, kafka, couchdb.    Includes documentation and test."
Answer: 173525.0

User story: "Add new command  {code:java}  peer channel getinfo -c channelName{code}  to get the blockchain information of specified channel peer joined.     "
Answer: 49836.0

User story: "the following is my step,    i use the fabric master branch to start the fabric network,as you know,in the example/e2e_cli folder,it provide the kafka consensus and then i map the data to the host,    for each zk:    volumes:   - /var/hyperledger/zk\{number}/data:/data   - /var/hyperledger/zk\{number}/datalog:/datalog    for each kafka:    volumes:   - /var/hyperledger/kafka\{number}:/tmp/kafka-logs    for each peer:    volumes:   - /var/hyperledger/peer\{number}/org\{number}:/var/hyperledger/production    i ues the couchdb to store the data,so i map the data to the host also    volumes:   - /var/hyperledger/couchdb\{number}:/opt/couchdb/data    i start the cli,it work fine,and make tx,and then i restart the fabric network,it seems the kafka consensus error       "
Answer: 1242227.0

User story: "Benchmark tests get littered with debug-level log output from other modules (msp, viperutil), because of the global setting in server_test.go. This is not right and should be fixed."
Answer: 2012.0

User story: The packages in the orderer have been re-arranged multiple times, In the process, many of the logging names have not been updated to reflect the new package names.    Consider for instance {{fabric/orderer/common/server}}.  This package logs as {{fabric/server/main}} and debugging is turned on for all components of the system, not just that package.  This occurs via:    {noformat}  func init() {          logging.SetLevel(logging.DEBUG, "")  }  {noformat}    All of the ordering (and common) packages should be fixed to define a constant which is the logging package name, which should correspond to the package name in the filesystem relative to the {{fabric}} dir.    For example: {{fabric/orderer/consensus/solo}} should have a logging package name of {{orderer/consensus/solo}}.    Additionally, all of the {{logging.SetLevel}} calls should be modified to set the logging for this package constant, and not for {{""}}.    
Answer: 2385.0

User story: "# Move to using profiles for all tests, instead of relying on just setting the CONFIGTX_ORDERER_ORDERERTYPE ENV var   # Switch to 3-broker default for Kafka tests   # Add sarama verbosity flag in envvars map for easier debugging   # Fix comments and log statements"
Answer: 8386.0

User story: "# In accordance to what we do for all other default values, the default Kafka version should be filled out in the orderer.yaml config files.   # The default value for Kafka was actually set to 0.10.1 even though our images use 0.10.2. We should change this to 0.10.2."
Answer: 3864.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's a couple of issues with the existing Kafka documentation.   # Every mention of Fabric is actually a mention of Hyperledger Fabric. This always felt wrong, and I'm glad to find out that it is actually redundant. See the first paragraph here: [https://lists.hyperledger.org/pipermail/hyperledger-tsc/2017-September/001086.html]   # Most importantly, the formatting is way off, and for the life of me I cannot figure out the right way to get indentations and proper list numbering. ("reStructuredText is an easy-to-read, what-you-see-is-what-you-get plaintext markup syntax and parser system." Riiiight.)
Answer: 22885.0

User story: Currently chaincode developers have no easy way of retrieving information about the invoker/submitter of a transaction. The stub that is passed to the chaincode Invoke function has GetCreator function that return bytes representing the invoker. The chaincode needs to Unmarshal the bytes, read the cert and extract info from it.     The goal is to provide a chaincode API which allows chaincode to implement access control.  We want to make these APIs as independent of MSP type as possible, while still allowing value-add for certain types of MSPs.    {code}   // GetID returns the ID associated with the invoking identity.  This ID   // is guaranteed to be unique within the MSP.          // Supported for all MSP types.   GetID() (string, error)     // Return the MSP ID of the client          // Supported for all MSP types.   GetMSPID() (string, error)     // GetAttributeValue returns the value of the client's attribute named `attrName`.   // If the client possesses the attribute, `found` is true and `value` equals the   // value of the attribute.   // If the client does not possess the attribute, `found` is false and `value`   // equals "".          // Supported for all MSP types, though only fabric CA will likely issue certificates with the attributes extension.   GetAttributeValue(attrName string) (value string, found bool, err error)     // AssertAttributeValue verifies that the client has the attribute named `attrName`   // with a value of `attrValue`; otherwise, an error is returned.          // Supported for all MSP types, though only fabric CA will likely issue certificates with the attributes extension.   AssertAttributeValue(attrName, attrValue string) error     // GetX509Certificate returns the X509 certificate associated with the client,   // or nil if it was not identified by an X509 certificate.          // Supported for only the default MSP type, which is based on X509.   GetX509Certificate() (*x509.Certificate, error)  {code}    For more info, pls see https://docs.google.com/document/d/1GP5tcN0oK9Zewed9h5pLiM2BowWPhtgFUGXEDKjeGGo/edit#
Answer: 57327.0

User story: "Fix spelling error in core/ledger/customtx/custom_tx_processor.go at line 26,modify 'comaptibility' to 'compatibility'."
Answer: 19908.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "There is currently a debilitating limitation with the cryptogen utility as it assumes the identity of a unique root CA with each use.  The outputted organizational CA root certs (`e.g. ca.org1.example.com-cert.pem`) are truly intermediate root certs.  As a result it is unfeasible to run the tool a second time to create certs and keys that are capable of interacting with an already bootstrapped fabric network    A simple objective is to use a basic crypto-config.yaml configuration to produce a set of crypto material for an orderer org and two peer orgs, and then bootstrap a network.  (The BYFN scenario).  Then use cryptogen a second time to produce crypto material for a third peer org and submit configuration updates to the ordering service to join this org (and by extension its peer(s)) to a channel and add the peer organization to the consortium definition at the system level.     There should also be accompanying documentation specifying 1. what the various certs and keys are used for 2. which certs exist within the orderer configuration block and channel configuration blocks.  Among the community, there is still a big gap of knowledge regarding Fabric's MSP implementation and the accompanying hierarchy."
Answer: 295152.0

User story: "I propose changing the default version of the fabric images in download-dockerimages.sh scripts from 1.0.0-beta to the current release 1.0.2    As well as adding a failure message to the generateArtifacts.sh script, on configtxgen build step, since without it you have a broken script pipeline with a mysterious error in the end if be chance you forgot to add GOPATH variable or place the fabric sources in it.    Something like:  {code:java}  make -C $FABRIC_ROOT release || { echo 'Could not build cryptogen' ; exit 1; }{code}"
Answer: 1249086.0

User story: "When the *byfn.sh* is been executed, a problem which is similar to the following may occurs.  {code:none}  /bin/bash: ./scripts/script.sh: /bin/bash^M: bad interpreter: No such file or directory  {code}  This is usually caused by the *wrong formate of the shell file*.    A troubleshooting may be needed to add in the BYFN tutorial in order to describe the problem and provide a probably solution."
Answer: 327412.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "While we have the broad overview of the configtxlator tool through the configtxlator.rst piece, we need to marry this with a running network and a real world example.  This involves creating a new doc that transitions from the BYFN piece and shows the user how to:    Add new org to the existing channel.    Add new org to consortium at the system level.    Use new org to create a second channel"
Answer: 1232409.0

User story: "There are some disclaimers that are no longer accurate.  Also need to insert better transitions between a few of the manual steps.  Add a small section linking out to a new update page. "
Answer: 457541.0

User story: "add unit test for crypto/random.go"
Answer: 76695.0

User story: "The docker-clean target currently deletes all images even if they are the official release versions.  It would be best if it only deleted the snapshot versions"
Answer: 374461.0

User story: "As the project attempts to move to a more consistent release schedule (current proposal is every 3 months), there will be features which will not be completed in a single release cycle.    It is not uncommon, however, for projects to provide builds with experimental features for those who wish to stay on the bleeding edge.      There are a couple of ways to do this:    1) Use feature flags to enable/disable features at runtime  2) Use Go build tags to optionally compile with experimental features."
Answer: 38687.0

User story: "We need to have a user-friendly way to create a IdemixMSPConfig out of issuer credential, the same way we do for the FabricMSPConfig.     This is to be used later on to feed config blocks.     As soon as this capability is in, IdexmiMSP would be usable by Fabric nodes that run a version with Idemix MSP.     Therefore, we indicate this item is blocked by FAB-5556."
Answer: 86807.0

User story: "It didn't go well when I tried the following use case.    There are two organization(A and B) which have already been running their own channels seperately(channelA and channelB) meaning that they have their own ordering system (ordererA and ordererB) and peers(peerA and PeerB). Now one day organization A wants to create a new channel C using its own orderering system with peerA and PeerB. PeerA joins the channel successully and starts to receive blocks from ordererA. the log shows that peerB joins successully, but actually peerB tries to send deliver request to ordererB instead of ordererA. The genesis block of channel C contains the info of ordererA but ignored by peerB.         After studying the code, I found out that when peer is asked to join a new channel, if it already belongs to a channel, despite of the orderer's information written in the genesis block it received, it still tries to connect to the orderer it first established connection with.　Since there is no information of channel C in ordererB, the error message of not being able to get block from ordererB keeps coming up. I think this situation should be improved."
Answer: 7335.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 endorser.getCDSFromLSCC() actually get chaincode data from ledger, instead of get chaincode deployment spec.    There's already a GetCDSFromLSCC() method in core.chaincode package, which does the correct work.    Would suggest to rename it to getCDFromLedger(), as it calls GetChaincodeDataFromLSCC() from the core.chaincode package."
Answer: 464038.0

User story: "Use ChaincodeSpec_Type_value instead of hard-coded number."
Answer: 220387.0

User story: "The script.sh has some repeated areas and syntax error.     "
Answer: 1259409.0

User story: "Syntax error in sampleconfig:    core.yaml Line 82 ,this will make ambiguity to others."
Answer: 372416.0

User story: "There is a syntax error in the order.yaml of sampleconfig package."
Answer: 372747.0

User story: "A valid configure message {{TX ~config~}} will advance {{ConfigSeq}} when committed. In this case, while a {{TX ~config~}} is in flight, all messages received between *receipt* and *commit* of {{TX ~config~}} *need to be re-validated*. In the case of Kafka-base OSN, this introduces *overhead of re-submitting those messages to Kafka* (see FAB-5720 for the reason).    A simple, yet native solution is to block ingress TXs when a {{TX ~config~}} is received until that TX is eventually committed. However, there's no mechanism to synchronously block all orderers when only one of them receives a {{TX ~config~}}.    Instead, we block if consecutive {{TX ~config~}} are in-flight and the commitment of *first one* causes all following ones to be re-validated and re-submitted.    So we don't necessarily eliminate all the potential overhead, but hopefully most of it."
Answer: 123162.0

User story: msp/msp_test.go has the HEAD as         /*  Copyright IBM Corp. 2017 All Rights Reserved.      Licensed under the Apache License, Version 2.0 (the "License");  you may not use this file except in compliance with the License.  You may obtain a copy of the License at                     http://www.apache.org/licenses/LICENSE-2.0    Unless required by applicable law or agreed to in writing, software  distributed under the License is distributed on an "AS IS" BASIS,  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  See the License for the specific language governing permissions and  limitations under the License.  */         We need to replace it to the new SPDX license to pass    "make checks".    Otherwise, there is the error as below.    ---------------------------------------    Checking committed files for SPDX-License-Identifier headers ...  The following files are missing SPDX-License-Identifier headers:  msp/msp_test.go    Please replace the Apache license header comment text with:  SPDX-License-Identifier: Apache-2.0  Makefile:111: recipe for target 'license' failed  make: *** [license] Error 1    ---------------------------------------     
Answer: 60282.0

User story: "in the dev mode,the fabric-orderer module doesn't provide the tls config thought the orderer enable the tls feature"
Answer: 1261019.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 *balance transfer* spring boot application using +fabric SDK java+ which will demonstrates all the basic _functionalities_ of *hyperledger 1.0*, such as enrolling and registering user , creating channel , installing chaincode , instantiating chaincode , invoking chaincode and querying chaincode. I have created this sample application for reference so that people who want to develop a hyperledger fabric solution using Java SDK can use the sample to accelerate their application development."
Answer: 1261034.0

User story: "Currently the BCCSP PKCS11 implementation sets the CKA_LABEL of the public and private keys to something like BCPUB1 and PCPRV1 respectively and sets the CKA_ID to the SKI bytes of the key pair.  For an HSM partition, this means that the CKA_LABEL will be the same if there are many key pairs in the same partition.  This makes it impossible to search for a key by the CKA_LABEL which is a common attribute to use for searching as the attribute will not be unique.      The CKA_LABEL should be set to the hex string of the SKI to make it unique for searching.    NOTE:  The SKI is a good choice as it can easily be calculated from the public key bytes of the MSP certificate which allows searching for the key by an alias (CKA_LABEL) given a certificate from an MSP that has the private key in a HSM."
Answer: 69180.0

User story: "In the current Behave feature files (`fabric-test` repo) the term *deploy* stands for a combination of two steps:  1) creating a channel, and joining the channel by the peer,  3) install and instantiate the chaincode    This contradicts with the usage of  the term *deploy* in Fabric, where it means install and instantiate a chaincode only.    The *deploy* in behave should be broken down in two parts mentioned above. "
Answer: 21361.0

User story: "clean up fabric-sdk-node ci scripts    Add more debug statements    remove npm-publish from node6 job    Add code coverage report for fabric-chaincode-node CI job.    Add more debug statements."
Answer: 2666.0

User story: "The following code include the configuration for the retry policy of peer to orderer. but it be hard coded. I think it should be configurable by someway.    File: core/deliverservice/deliveryclient.go    Line 31:    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<    var (    reConnectTotalTimeThreshold = time.Second * 60 * 5    connTimeout                 = time.Second * 3    reConnectBackoffThreshold   = float64(time.Hour)    )    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>         Line 37    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<    // SetReconnectTotalTimeThreshold sets the total time the delivery service    // may spend in reconnection attempts until its retry logic gives up    // and returns an error    func SetReconnectTotalTimeThreshold(duration time.Duration) \{    reConnectTotalTimeThreshold = duration    }    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>"
Answer: 331887.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "in the orderer/sample_clients,it provide many tool to test the orderer,like the broadcast_msg,  but when i use the command to start the broadcast_msg,it show nothing,just running,so i think the rate of progress should be provide"
Answer: 287442.0

User story: "Block/transaction validation in VSCC is as of v1.0.1 sequential and single-threaded. Therefore the transaction validation does not scale with CPU. This implies a performance bottleneck in VSCC, which amounts to about 500-600 tps - on small scale Fabric deployments - where transactions pertain to a simple utxo cryptocurrency application we built on Fabric with a *single* endorsement. This validation bottleneck in those experiments is also an end-to-end throughput bottleneck and, as such, critical.          Fix to this issue would allow parallelized VSCC to scale with CPU (number of peer cores)."
Answer: 63863.0

User story: "Line 70 : `It it` should be `It is`.It is a stupid error."
Answer: 4391.0

User story: "v1.0.x currently uses grpc-go 1.4.0.  grpc-go 1.5.2 was released a few weeks back and we should try to stay current.  Addtionally, 1.5.2 is now license under Apache2.  There are some performance improvements and some new features to tweak logging as well."
Answer: 21418.0

User story: "A consortium who uses an out-of-band process to certify an implementation ideally produces an allow list for CC installation (e.g., hashes of the platform packages submitted to peers).    See [comment on FAB-5460|https://jira.hyperledger.org/browse/FAB-5682?focusedCommentId=30236&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-30236] for some context."
Answer: 1266070.0