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: "When protobuf definitions are updated in {{fabric-protos}}, an automated build process should be triggered to compile the protos to go and commit the generated artifacts to a separate source repository that gets used by or vendored into consumers. The {{fabric-protos}} repository will not contain the generated language bindings.    We have a couple of options to discuss for placement:    1. Create a {{fabric-protos-go}} repository to contain the compiled protocol buffer bindings for go. In this scenario, the import paths for the various protobuf packages would be {{github.com/hyperledger/fabric-protos-go/[common,discover,peer,orderer,etc]}}. This repo should be configured not to accept pull requests. The contents should be managed by automation.(Preferred.)  -2. Reuse the {{fabric-lib-go}} repository. In this scenario, the import paths would all be under a common {{protos}} folder and would be {{github.com/hyperledger/fabric-lib-go/protos}}.-    In either case, pull request builds for {{fabric-protos}} should generate but *not* merge/commit the artifacts to the target repo. Builds performed post-commit should generate the artifacts and commit them to the target repo.    Update: During IPM we decided to do the build and promote with Travis-CI.    [1:] Please consider branching strategies. {{fabric-protos/release-2.0}} should promote to {{fabric-protos-go/release-2.0}} while {{fabric-protos/master}} should promote to {{fabric-protos-go/master}}.  [2:] Please read https://medium.com/namely-labs/how-we-build-grpc-services-at-namely-52a3ae9e7c35 for inspriation.    "
Answer: 57590.0

User story: "Create a new github repository called {{fabric-protos}} 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 to provide write access to the fabric maintainers. This will likely require the definition of a new github team."
Answer: 57617.0

User story: "As a hyperledger fabric beginner and golang developer, samples should be written in an expression appropriate to the language's characteristics."
Answer: 9760.0

User story: "Orderer FileLedger Location should relative to the config (orderer.yaml)"
Answer: 2139.0

User story: "/scripts/bootstrap.sh downloads architecture and version specific binary locally.    BINARY_FILE=hyperledger-fabric-${ARCH}-${VERSION}.tar.gz  CA_BINARY_FILE=hyperledger-fabric-ca-${ARCH}-${CA_VERSION}.tar.gz    My suggestion is to run this binaries from docker images all the time, which is much better for compatibility and allows us to run different version of HLF on the same machine without any issues."
Answer: 425677.0

User story: "'TopLevel' struct member 'Consensus' type is interface{}, which actual point to struct 'Config', this will make code more clearer"
Answer: 592.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 an operator, I would like to use the operations service to get an orderer's/peer's version. For one thing, this will help operator know when a sufficient number of orderers/peers have been upgraded such that a channel can be upgraded to the latest capability. For example, an operator may display an 'upgrade channel capability' button on a channel when a sufficient number of peers/orderers have been upgraded."
Answer: 204375.0

User story: "Reconciler fetches the missing pvtData from other peers. 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.   * with the introduction of rollback, there is a possibility of invalid pvtData transaction becoming valid (after a potential bug fix and rollback) which would result in the permantent loss of pvtData.   * 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.    When the user tries to read missing private state from the stateDB, it returns an error."
Answer: 648706.0

User story: " https://docs.google.com/document/d/1BBVA8u-GJ99ZYRT015PAnMVK4_pKv53Y-kiP9lZX8Gc/edit"
Answer: 56449.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 Fabric Samples creates a CLI container from the Fabric-Tools image. It mounts the chaincode inside the container and calls `peer lifecycle chaincode package`.    Fabric recently merged a change that removes the shim and protos package from the ccenv image. This means that the shim, peer protos and their dependencies must either be vendored in the chaincodes package, or exist in the GOPATH. We also removed the filter that excluded the Shim and Protos package from the `chaincode package` "autovendoring" process.    The issue in Fabric Samples is that the Chaincode is mounted into the CLI container where there is no hope of Fabric existing. Fabric cant be cloned locally inside the container before calling the package process because the directory is already populated by the cryptographic material. And Fabric can't be mounted into the container because the GOPATH could potentially contain multiple paths, i.e., `/usr/go:/usr/local/go:/Users/user/go` unless you first discern where Fabric exists on the GOPATH before mounting the volume.    The Fabric Samples team needs to come up with a solution that will allow for the existence of Fabric, whether that be inside the container on the GOPATH, or, packaging the chaincode outside of the CLI and then mounting the chaincode package into the container, which requires Fabric to be on the local GOPATH. We already require the users to have the binaries on their system PATH as part of the Fabric Samples prerequisites, so building it outside the container is not an unreasonable things to ask.    Fabric's new chaincode packaging model will require the dependencies to be prevendored, or exist on the GOPATH, so having developers who are running Fabric Samples have to do the same process is reasonable, given it will be expected of them when developing.    We will also need to update Fabric Samples doc to inform developers they need to clone Fabric into their GOPATH locally, if samples doesn't provide another means for packaging the chaincode.    You can test this issue by simply running ./byfn.sh up. However we have backed out the changes which cause this to break. We will reintroduce the changes, but gate them with a environment variable `CHAINCODE_VENDORSHIM` which if set to true will take the path that breaks the packaging process. You will be able to test your changes by setting this flag in your environment, whether that be locally outside of Fabric Tools, or in side of the Fabric Tools container.
Answer: 60449.0

User story: " This story is for testcases necessary for Kafka to Raft Migration system testing    This is where add all system verification tests (SVT) involving the Kafka to Raft Migration"
Answer: 61335.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 {{chaincode package}} command includes some logic to filter packages that the ccenv includes. This means that older or newer versions of these packages (used during development) will not be included in the package that's installed to the peer.    As a developer, when the "auto-vendoring" process is performed, I would like my code to be included at all times.
Answer: 120888.0

User story: "This story is dedicated to the functionality of joining channels using the channel participation API.    If the orderer does not have a system channel defined, it should be able to join application channels.    If the orderer does have a system channel defined, it should not be able to join any other channels.    If the orderer does not have any channels defined, it should be able to join any channel, including the system channel.    The orderer should be able to join as a cluster member (included in the consenters set) or as a follower (not included in the consenters set).  The orderer should allow a transition from a cluster follower to a cluster member and vise-versa."
Answer: 664793.0

User story: "With FAB-15708 and FAB-15709 implemented, an orderer can start without any genesis method, or any channels defined, but does nothing.      We need an API to be able to:    * Join this OSN to a new or an existing channel,  * Remove this OSN from an existing channel,  * List the channels this OSN is a member of.    This story is dedicated to the detailed design and implementation of the REST API of this feature, with the underlying behavior described in epic FAB-17712 and associated RFC. The REST API implementation will accept the queries defined and will transfer them to an abstract interface of the underlying implementation.    The first product of this task is a design document.    The REST API design is [HERE|https://docs.google.com/document/d/1kYoicS_Z59gNvmuuB7VFZ6WsOL31C34dWMeOFQiIygA/edit?usp=sharing]."
Answer: 580086.0

User story: "Today, if the orderer does not have any channels defined, it panics because it cannot find the system channel.  This story is to remove those startup checks to allow the orderer to start successfully, even though it will not be in a position to accomplish anything.  This should also block channel creation requests if no system channel is defined to route them to."
Answer: 221685.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: "Today, the orderer may be given one of two genesis methods 'Provisional' or 'File'.  In the 'Provisional' case (useful only for testing) the orderer generates a genesis block based on a configtx.yaml file, while in the 'File' case, the orderer loads a file from the filesystem.    In order to ultimately allow the orderer to start without chains defined, we need to allow a genesis method which does not attempt to do anything.  This genesis method should be called 'None', and should not trigger loading of the genesis file, nor generation of a genesis block.    ----    If you supply None as the genesis method for an orderer that has not been bootstrapped, the orderer should panic.  If you supply None as the genesis method for an orderer that has already been bootstrapped and the genesis file is not available, it should start normally.  "
Answer: 211665.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*: Raft clusters use *TLS* pinning to authenticate nodes. *TLS* uses standard *x509* validation for certificates which dictates a certificate is only valid between its *NotBefore* and *NotAfter* attributes.    Thus, the operators need to periodically change *TLS* certificates by:   * Issuing config updates to all channels that change the *TLS* certificates of the nodes.   * Restarting the nodes with the new *TLS* certificates.    *Disclaimer*: to be clear, this is done one at a time, and this JIRA shouldn't be used as a guide to administer a Raft cluster.    *Problem*: When half or more of the *TLS* certificates of the Raft cluster members expire, it is no longer possible to do config updates due to loss of quorum, so the Blockchain is then stuck forever.    *Observation*: The Golang *TLS* config has a pluggable *time.Time* function that if set (not nil) it overrides the real time used when verifying *TLS* certificates at time of *TLS* handshake.  {code:java}   // Time returns the current time as the number of seconds since the epoch.   // If Time is nil, *TLS* uses time.Now.   Time func() time.Time  {code}  Relevant snippet from the code:  {code:java}     opts := x509.VerifyOptions{      Roots:         c.config.RootCAs,   // ------------------------------------------------------------------------                            CurrentTime:   c.config.time()    // ------------------------------------------------------------------------      DNSName:       c.config.ServerName,      Intermediates: x509.NewCertPool(),     }       for i, cert := range certs {      if i == 0 {       continue      }      opts.Intermediates.AddCert(cert)     }     c.verifiedChains, err = certs[0].Verify(opts)  {code}       *Proposal*: To add a config option in the orderer config (it will be hidden but documented) that essentially "brings back time" *T* hours to the past.   With this config option, if a network has a failed Raft cluster with expired certs, the administrators can then agree to manually override the time of the *TLS* handshakes (just for the consensus listeners) and this would buy them a configurable amount of time to recover the cluster by doing config updates and rotate *TLS* certificates.     So, the config option to bring back the cluster 1 day would be something like "General.Cluster.TLSHandshakeTimeShift", e.g. in orderer config override:    ORDERER_GENERAL_CLUSTER_TLSHANDSHAKETIMESHIFT="24H"         [~<USER> [~<USER> [~<USER> [~<USER> [~<USER> [~<USER> what do you think?
Answer: 77636.0

User story: "See release note text in original Jira FAB-7559."
Answer: 441044.0

User story: "The peer package contains a number of package level variables that act as an object. We have started to merge this into a peer.Peer in support of FAB-14324. As the goal of that item is to remove CredentialSupport, the remainder of the work will be tracked here.  "
Answer: 44979.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: Even when logging level is set to a level other than DEBUG (such as FABRIC_LOGGING_SPEC=WARNING), log message formatting (e.g. Sprintf things) for debug logs is always executed.    Due to this behavior, peer's logging mechanism consumes 10.5% of peer's CPU usage in my experiment. I implemented a patch to suppress unnecessary log message formatting, and achieved 21% TPS improvement. Please see attached files for details.     The function in {{vendor/go.uber.org/zap/sugar.go}} prepares a log message from a given format. The {{Enabled(lvl)}} checks the log level to decide whether this message is written or not.  {code:java}  func (s *SugaredLogger) log(lvl zapcore.Level, template string, fmtArgs []interface{}, context []interface{}) {   // If logging at this level is completely disabled, skip the overhead of   // string formatting.   if lvl < DPanicLevel && !s.base.Core().Enabled(lvl) {    return   }     // Format with Sprint, Sprintf, or neither.   msg := template   if msg == "" && len(fmtArgs) > 0 {    msg = fmt.Sprint(fmtArgs...)   } else if msg != "" && len(fmtArgs) > 0 {    msg = fmt.Sprintf(template, fmtArgs...)   }     if ce := s.base.Check(lvl, msg); ce != nil {    ce.Write(s.sweetenFields(context)...)   }  }  {code}  However, {{Enabled(lvl)}} in Fabric always returns true, and log message formatting is always executed. This change was introduced to implement logging based on logger's names.    [https://gerrit.hyperledger.org/r/c/fabric/+/27273]    To work around the performance issue of this change, I implemented a patch that enables logging decision based on logger's names at {{Enabled(lvl)}}. My patch introduces some complication, but I think 20%+ TPS improvement justifies it.
Answer: 4588.0

User story: "Raft orderers need TLS for internal Raft communication. And they can make Raft communication on a different port than client facing port.     However it is not possible to enable TLS only for Raft port but not for client facing port. It would be nice to have this feature.    In our case we are running everything in a Kubernetes cluster so internal TLS is not requirement for us. Even later when some nodes are exposed to outer world, since we use a central Ingress for TLS termination, internal TLS wont be still a requirement.    *Edit:* As mentioned in the email list, in our case, enabling TLS globally has also another huge impact, we lost transparent load balancing for peer and orderer nodes. Please see TLS section in our [GitHub repo|https://github.com/APGGroeiFabriek/PIVT#limitations].          "
Answer: 86618.0

User story: "// ECDSAGoPublicKeyImportOpts contains options for RSA key importation from rsa.PublicKey  type RSAGoPublicKeyImportOpts struct {   Temporary bool  }"
Answer: 456639.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: "Legacy and new lifecycle will have to co-exist for at least one release till the legacy one is removed. During this time, it may be desirable for SDKs to be able to query the new lifecycle and receive aggregate information from both legacy and new implementations. This FAB tracks the necessary work to enhance queries."
Answer: 66252.0

User story: "func RunQuery(n *nwo.Network, orderer *nwo.Orderer, peer *nwo.Peer, channel string) int    does not use parameter `orderer`"
Answer: 679436.0

User story: "We can enable golang's pprof profiling mechanism by setting environment variables  CORE_PEER_PROFILE_ENABLED and ORDERER_GENERAL_PROFILE_ENABLED    [https://golang.org/pkg/runtime/pprof/#Profile]    However, we can't adjust pprof's parameters for block and mutex profiles for now. To enable and control profiling frequencies, we need to call runtime functions runtime.SetBlockProfileRate and runtime.SetMutexProfileFraction.   * https://golang.org/pkg/runtime/#SetBlockProfileRate   * https://golang.org/pkg/runtime/#SetMutexProfileFraction    Block and mutex profiles are very convenient tools to analyze performance issues related to locks and I/O waits.  I'd like to have configuration options in core.yaml and orderer.yaml to adjust those parameters.    Corresponding environment variable names will be:   * ORDERER_GENERAL_PROFILE_BLOCKPROFILERATE   * ORDERER_GENERAL_PROFILE_MUTEXPROFILEFRACTION   * CORE_PEER_PROFILE_BLOCKPROFILERATE   * CORE_PEER_PROFILE_MUTEXPROFILEFRACTION    The default values of these parameters are set to 0.  It means block/mutex profiles are turned off.     "
Answer: 1249.0

User story: "Refactoring InitGossipService function in gossip_service.go     !image-2019-05-24-12-20-35-215.png|width=833,height=113!         This should be removed now, and InitGossipService function can be removed as well.      "
Answer: 1.0

User story: "A recent change to master resulted in minor changes to all generated .pb.go files."
Answer: 8683.0

User story: "Thanks in advance."
Answer: 480351.0

User story: "In the core/ledger package, lockbasedtxmgr current uses a new instance of CouchDB for every single test executed. Instead we should use one Couch container, and instead initialize new ledgers in the same DB.    This will provide two benefits:    The first is we reduce the likelyhood of a timeout occurring on CouchDB startup. Currently there are over 30 instances of Couch starting and any one can cause unit tests to fail. Using only one instance greatly reduces our exposure to failures.    The second benefit is a greatly reduced time period for conducting tests in this package. Each container takes 10 seconds to start. Reducing to a single container will save nearly 5 minutes off of unit test run time."
Answer: 4328.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 PTE uses a very old version of marbles private Chain code from fabric-test. PTE must be updated to use newer version of marbels02_private chaincode, which uses transient maps. Consider using the copy in fabric/integration/chaincode/marbles_private instead of using the one in fabric-samples repo. Or, consider copying the latest version into fabric-test/chaincodes/ for more stability.   * Update pte to accept any parameters needed for custom chaincodes.   * Update testInput file to accept the transient vars.   * Update the operator to read them and pass to pte.   * Update/create marbles02_private testcase to use the operator and use this new testInput file format with newer version marbles02_private (which uses the transient vars), and add to the systest test suite."
Answer: 371536.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 following operations are provided on the peer admin service:    {code}  // Interface exported by the server.  service Admin {      rpc GetStatus(common.Envelope) returns (ServerStatus) {}      rpc StartServer(common.Envelope) returns (ServerStatus) {}      rpc GetModuleLogLevel(common.Envelope) returns (LogLevelResponse) {}      rpc SetModuleLogLevel(common.Envelope) returns (LogLevelResponse) {}      rpc RevertLogLevels(common.Envelope) returns (google.protobuf.Empty) {}      rpc GetLogSpec(common.Envelope) returns (LogSpecResponse) {}      rpc SetLogSpec(common.Envelope) returns (LogSpecResponse) {}  }  {code}    Of those:  - {{GetStatus}} simply returns a constant value of "STARTED". This has minimal value.  - {{StartServer}} simply returns a constant value of "STARTED". This has no value.  - {{GetModuleLogLevel}} gets the current log level for a name. This functionality overlaps with the http operations service and does not match the concepts of named loggers.  - {{SetModuleLogLevel}} activates a new log spec by appending a module=level segment. This functionality overlaps with the http operations service.  - {{RevertLogLevels}} restores the log level to the value captured during process initialization. This overlaps with the http operations service and can be accomplished by operators querying the spec before modifying so they can restore it.  - {{GetLogSpec}} gets the current log spec and overlaps with the http operations service.  - {{SetLogSpec}} sets the current log spec and overlaps with the http operations service.    In summary, the only two operations that are consistent with where we are going are GetLogSpec and SetLogSpec. If having those available to an "admin" instead of an "operator" is desired, we can reduce the scope of the service to those two items. If, instead, we want to use the operations infrastructure, we can remove the service entirely.    Changes in this space will impact the peer cli. In particular, getting and setting the log spec will no longer be possible  signing an admin request with an admin cred, enveloping, and submitting to the grpc service.  Further, since operations was explicitly modeled as distinct from admin, a separate TLS client certificate would be required to support these operations.    So, in summary, if we remove this service entirely, we'll also be removing get/set logging from the peer CLI as the peer CLI should probably not grow to consume ops services.
Answer: 27259.0

User story: Currently, admins are identified by explicit X509 certificates.  The X509 MSP already has the ability to set NodeOUs to identify client and peer roles.  We should also allow an OU to be used to identity admins as well.    For "local" MSPs, this should simply require the customer to upgrade the peer; I do not believe we need to hide this behind a capability.    For channel MSPs, we will need to hide this behind a capability.
Answer: 299808.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 many failing test cases in fabric-test/feature files used in daily behave test suite that fail due to various reasons; many appear as IO errors or TLS failures, but there are others too.    * Create specific bugs for each type of error.  * Disable the failing testcases; keep the jira bugs open.  * Later return to fix each one (if it is deemed necessary because the test coverage is not duplicated elsewhere)."
Answer: 121081.0

User story: "The chaincode shim includes a number of logging operations that do nothing more than write to stderr. The implementation of these logging interfaces is based on op/go-logging - the library we removed from the fabric core in 1.3.    Removing the logging interfaces from the shim would allow us to stop carrying the op-logging dependency and make clear our position that logging from chaincode is the responsibility of a chaincode developer and that there's no magic integration between chaincode and the peer.    This would also allow us to remove additional viper dependencies in the code base.    Chaincode developers that use the logging interfaces would need to adopt their own logging facade and direct output to stdout or stderr as appropriate."
Answer: 67026.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: *Chaincode*: [https://github.com/hyperledger/fabric-samples/blob/release-1.4/chaincode/marbles02_private/go/marbles_chaincode_private.go]     *Collections files:* Please see below  {code}   Private data dissimenation is not working with "requiredPeerCount": 1 in collections file:  {code}     Please see attached screen shot.    *Extract from peer command:*    {code}  peer chaincode invoke -o 169.46.208.135:31276 -C channel1 -n marbles_chaincode_private --tls --cafile /Users/chandra/Desktop/json/orderermsp/admin_msp/tlscacerts/tlscert.pem -c '{"Args":["initMarble"]}' --transient "\{\"marble\":\"${MARBLE1}\"}"     Error: endorsement failure during invoke. response: status:500 message:"Failed disseminating 1 out of 2 private RWSets"   {code}    *peer container logs*  {code}  2019-04-29 16:56:36.123 UTC [couchdb] CreateDatabaseIfNotExist -> INFO 329 Created state database channel1_marbles_chaincode_private$$pcollection$marbles   2019-04-29 16:56:36.174 UTC [couchdb] CreateDatabaseIfNotExist -> INFO 32a Created state database channel1_marbles_chaincode_private$$hcollection$marbles   2019-04-29 16:56:36.183 UTC [peer.chaincode.dev-jdoe-marbles_chaincode_private-1] func2 -> INFO 32b - end init marble   2019-04-29 16:56:36.184 UTC [endorser] callChaincode -> INFO 32c [channel1][8a321ffd] Exit chaincode: name:"marbles_chaincode_private" (22647ms)   2019-04-29 16:56:36.185 UTC [gossip.privdata] func1 -> ERRO 32d Failed disseminating private RWSet for TxID 8a321ffd21965ddac66c2f0a50a1bae1542bc48ad9c3cc0d406a6623d6d006e6 , namespace marbles_chaincode_private collection collectionMarblePrivateDetails : Requested to send to at least 1 peers, but know only of 0 suitable peers   2019-04-29 16:56:36.187 UTC [gossip.service] DistributePrivateData -> ERRO 32e Failed to distributed private collection, txID 8a321ffd21965ddac66c2f0a50a1bae1542bc48ad9c3cc0d406a6623d6d006e6 channel channel1 due to Failed disseminating 1 out of 2 private RWSets   2019-04-29 16:56:36.188 UTC [comm.grpc.server] 1 -> INFO 32f unary call completed    {"grpc.start_time": "2019-04-29T16:56:13.535Z", "grpc.service": "protos.Endorser", "grpc.method": "ProcessProposal", "grpc.peer_address": "10.121.12.190:10551", "grpc.code": "OK", "grpc.call_duration": "22.653100119s"}  {code}    If I change *requiredPeedCount* to *0* in collection file, I don't see errors above and transaction is successfully committed to the ledger.  
Answer: 1733.0

User story: "Now that Raft is the ordering service of choice, it's time to stop publishing the Zookeeper and Kafka images.  Supported versions should be documented and ideally tests will use images from Dockerhub (perhaps the Confluent community images).    CouchDB now publishes official library images as well and those should be used rather than publishing an image."
Answer: 371002.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 gossip unit tests should be improved in two aspects    Currently gossip unit tests fail around 2-3 times a day. Failures are intermittent and occur in a variety of tests.    Tests fail more often in the CI environment. This is probably due to the more constraint resources available in CI that lead to various timing effects the tests are vulnerable to.                    "
Answer: 313085.0

User story: "Type endpoint.TLSKeyPair is used in two contexts: as a TLS client identity, and as a user signing identity. TLSKeyPair should be renamed to reflect this.    Also, endpoint.TLSConfig just holds a key material in PEM format. The name should reflect the usage."
Answer: 5.0

User story: "Is there any way using SDK function or an API to query a single or multi-org channel that would return list of orderers on a channel at given point in time?"
Answer: 383206.0

User story: "There are a number of places in the code, especially {{common/mocks}} which contain hand-written (and maintained) mocks.  This is burden to maintain and saps development resources and should be removed.    We should begin by fixing tests package by package which reference these common mocks, and, once no packages depend on them, remove them from the code."
Answer: 78721.0

User story: 1 - Create network input yaml file with all inputs that NL supports and kubernetes cluster related section    2 - Add function to NL to take network input yaml file and read in values from input file    3 - Add ability to read kubeconfig file, to specify and use k8s instead of local network    4 - Generate all config files needed to create pvc, services, yaml to launch fabric. (This and following items will be called by NL. NL already creates docker compose file and configtx yaml file, so it will be similar method to that)    5 - Create pvc and copy certs    6 - Launch network    7 - Query for health of pods (peers, orderers) before returning "success"    8 - Generate connection profile    For example:   cd fabric-test/tools/NL  go run networkLauncher.go -i "path of networkSpec.yaml file" -k "path of Kube config file"    
Answer: 181701.0

User story: Add to fabric-samples  first-network  a demonstration of how to create a channel with a subset of orderers. That is, run the     bq. /byfn.sh up -o etcdraft     to start a 5 node network. Then create a new script     bq. ./raftop.sh up    that creates a new channel "mychannel2" with 3 orderers only.  
Answer: 93717.0

User story: "Implementing some lessons learned from some recent support interactions."
Answer: 88167.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: "Existing release process required manual intervention to trigger release and mulitarch jobs. This required Jenkins permissions to a user to trigger these jobs manually but as per the Linux Foundation team, they don't want to give permissions to anyone outside of LF team.    Proposed Solution:    Create a pipeline script in Jenkins to publish images and binaries from merge job after a Release CR is merged. To do this, we need to add a flag in Makefile to identify a release CR and push images and binaries to nexus and DockerHub. This is applicable to all the releases like fabric, fabric-ca, fabric-chaincode-java, fabric-chaincode-node. This avoids publishing release artifiacts manually and creates a seamless release process.    We can achieve this with Jenkins pipeline flow.    We can include the above approach with what [~<USER> was proposing on multibranch strategy."
Answer: 191639.0

User story: In v1.x, chaincode could not Init() with private data since the collection policy was not yet committed. An error like the following was returned:    "private data APIs are not allowed in chaincode Init"    With new lifecycle, this restriction can be lifted.
Answer: 47209.0

User story: "Now that implicit collections have an endorsement policy, it makes sense to introduce an endorsement policy for normal (static) collections as well"
Answer: 331731.0

User story: "Examples of attack scenarios we need to test/code against:   * define _lifecycle when the network is on 1.4   * define an implicit collection when the network is on 1.4   * ..."
Answer: 50135.0

User story: "Currently, there is no way to do a simple 'delState()' for any objects put on-chain while trying out the high throughput example.  I would like to create a simple delStandard() function to alleviate this issue."
Answer: 60467.0

User story: "This will allow a basic interop test to run in CI that uses the JavaSDK, NodeSDK, and CLI with the different java, nodejs, and golang chaincode environments."
Answer: 408988.0

User story: Other queries under consideration:   * "That said, we plan to add another query that takes only the sequence number as arguments and returns the full info about the definition with that sequence number, including the list of orgs that have approved it." [https://gerrit.hyperledger.org/r/c/fabric/+/30340/1/core/chaincode/lifecycle/lifecycle.go#228]
Answer: 301011.0

User story: "Migrate an existing kafka-based ordering service to a raft-based ordering service.      This epic includes:   * Design & implement the mechanism in the orderer node   * Provide tools that automate the process   * Provide documentation and guidelines    Design document: [Google Drive|https://docs.google.com/document/d/1I7zWBomEPsgxgDYiYwE7ZPaT_Htll996nM2Y5A4xY-8/edit?usp=sharing], or see attached PDF.    Revised design of previous task: https://jira.hyperledger.org/browse/FAB-12777"
Answer: 140249.0

User story: "This story is about introducing the relative protobuf and interfaces to support integration of tokens in lifecycle."
Answer: 350294.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "We should enforce {{ElectionTimeout}} to be at least 10x greater than {{HeartbeatTimeout}} to avoid flakiness caused by user misconfiguration."
Answer: 99241.0

User story: "Allow java chaincode javaenv and node chaincode baseimage to be at different version level than Fabric, by changing the javaenv and baseimage versions to 'latest' in core.yaml instead of specifying the Fabric version.    This will allow Fabric to work with different versions of chaincodes.  For example with this change Fabric v1.4.1-rc1 and v1.4.1 could work with javaenv v1.4.0. Similarly Fabric v1.4.1 could work with a newer javaenv or baseimage if there was a newer java or Node.js fixpack that was needed.    The only downside is that if a user forgets to pull the latest version of javaenv or baseimage, they could be using older versions without knowing it, and these older versions at some point may become incompatible.    Note that because the javaenv and baseimage version is defined in core.yaml, it can still be overridden with environment variables to specify an exact version.    Similar updates were made for v2.0 in FAB-11096:  https://gerrit.hyperledger.org/r/#/c/27491/33/sampleconfig/core.yaml"
Answer: 87231.0

User story: "Refer to Matt's comment:     [https://gerrit.hyperledger.org/r/#/c/28302/18/token/client/tx_submitter.go@90]"
Answer: 431078.0

User story: "Consolidate integration tests to avoid unnecessary resource allocation and bootstrap"
Answer: 357474.0

User story: "Currently, you must transfer exact same quantity as the quantity in token ids. This causes usability issue because client will have to subtract to get the remaining quantity and include it in the transfer share.    Update transactor.go to automatically calculate the remaining quantity and include it in the token transaction.      "
Answer: 9080.0

User story: QueryInstalledChaincode and QueryChaincodeDefinition should return "404 Not Found" to distinguish between a true error and simply that the desired chaincode/chaincode definition was not found.
Answer: 325.0

User story: "As an org with channel Reader permission, I should be able to invoke chaincode that queries channel ledger data.    Currently you must have channel Writer permission to invoke a chaincode that only queries (reads) channel ledger data.  This does not make sense and has caused problems for many users.    We should either check access control based on the actual chaincode operations performed (e.g. Puts vs Gets), or we should make this explicit and introduce a read-only Invoke that can only do Gets (no Puts) that channel Readers can call.  "
Answer: 195553.0

User story: "Currently the only timeout that would prevent an unresponsive endpoint (ordering/endorsing) from stalling a CLI invocation forever is the long grpc connection timeout. We should instead supply a context with a timeout as part of the invocation, and expose a timeout."
Answer: 432570.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: "Using go sdk I send a channel create request with channel ID nileshIBPICPZdemo0 and it failed due to below error.    2019-03-26 17:42:22.835 UTC [orderer.common.broadcast] ProcessMessage -> WARN 03f [channel: nileshIBPICPZdemo0] Rejecting broadcast of config message from 10.1.92.0:1404 because of error: initializing configtx manager failed: bad channel ID: channel ID 'nileshIBPICPZdemo0' contains illegal characters      I retried with a channel Id with all lower case in the name and it worked.    Can channel IDs with capital letters be supported please.     "
Answer: 435113.0

User story: "_lifecycle should handle some input validation on the server-side and return meaningful error messages when the inputs are invalid.    For example, we should validate input for chaincode names, versions, collection names, etc."
Answer: 93323.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 our solution, at the time of adding a private data on the ledger, we do not know the sub-set of peers it will need to be shared with. Hence, all new private data will be written to a single peer collection. The membership information is known only over time and then we need to share the private data with other peer(s) dynamically.    The expected effect (for that private data) is similar to expanding a collection membership with additional peers (i.e., new peers see the existing private data w/o any explicit txns performed by chaincode).    Option 1: 1 Collection created dynamically per key   T1: Create CollectionK1 (peerA), Write K1 to CollectionK1   T2: Create CollectionK2 (peerB), Write K2 to CollectionK2   T3: Change Membership(CollectionK1) = peerA,peerB   T4: Change Membership(CollectionK2) = peerA,peerB,peerC    K1 is visible to peerA and peerB. K2 is visible to peerA, peerB and peerC    Each collection will contain only 1 kv pair   Cons: Management & Scalability?     With millions of state variables, will need to create 1 collection per kv pair.     Need to perform a chaincode instantiate/upgrade every time we change a collection membership (causing chaincode version bump and associated MVCC failures for unrelated in-flight txns)      i.e., Millions of collections, Millions of collection spec changes.    Option 2: Pre-defined collections and Transfer private data across them.   CollectionA (peerA)   CollectionAB (peerA,peerB)   CollectionABC (peerA,peerB,peerC)   CollectionBC (peerB,peerC)    T1: Write K1 to CollectionA   T2: Write K2 to CollectionA   T3: Transfer K1 from CollectionA to CollectionAB <-- peerB has access to K1   T4: Transfer K2 from CollectionA to CollectionABC <-- peerB & peerC have access to K2   T5: Transfer K1 from CollectionABC to CollectionBC <-- peerA looses access to K1     "
Answer: 443209.0

User story: "The tricky part is that followers don't have the knowledge of active nodes in the network, so this info needs to be retrieved from leader."
Answer: 210797.0

User story: "RequestIssue currently returns an empty token transaction when the tokens are nil or empty, however, it should return an error.    Moreover, when no valid inputs are submitted also an error should be returned.  "
Answer: 17410.0

User story: "As opposed to passing dependencies through init (and ensuring that they are always referring to the latest channel config), we should generate appropriate dependencies and supply them to each invocation of the Validation function of the plugins.         See [https://gerrit.hyperledger.org/r/#/c/30123/2/core/policy/application.go@90] and discussion"
Answer: 193386.0

User story: "Currently, the prover peer returns a list of unspent tokens where quantities are encoded in hex format. To simplify the life of the client-sdks, the quantities will be returned in decimal format.    Notice, that this does not affect the way quantities are stored in token transactions."
Answer: 438206.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: "See [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736] and [https://docs.docker.com/engine/release-notes/#18092]."
Answer: 152861.0

User story: "I'll use the concrete example that sparked this. I'm sure there are others.    A fabric network defines the maximum permissible message size at creation time.     As a client - regardless of SDK - a user ought to be able to determine the maximum message size allowed by this network so they can configure my client access methods appropriately.    Currently this is left to the individual SDK implementations rather than being specified by the network owner. It would be far more convenient if it were returned by a network configuration call so clients can act on it - and set their own connection values - appropriately.    This is especially true when the network is managed by a third party and access to configuration is limited.     "
Answer: 455460.0

User story: "Pass a more restricted interface to Fabric operations instead of the full TxSimulator interface.  This will allow control over what functions Fabric Operations have access to."
Answer: 456630.0

User story: "Update github.com/pkg/errors dependency to 0.8.1."
Answer: 2552.0

User story: "The goal is to provide a sample network, like the one used in the *first network* example, where to use how to use the Token CLI to drive fabtoken."
Answer: 443648.0

User story: "The serialized operation message must produce the same bytes across endorsers.    [https://developers.google.com/protocol-buffers/docs/encoding#order]    This is likely already the case given that the Operation message from the chaincode (in Go, Java, Node, etc.) is unmarshalled on the endorser peer and always marshalled in Go before being added to the read/write/operation set.         Tasks    1) look in Go source for protocol buffer marshalling to ensure bytes produced are always the same.    2) do we have to be concerned about different versions of the peer. At this point, protocol buffer serializing is likely stable between versions.    3) Consider converting Operation message to DER encoded ASN.1 on the peer.     [https://golang.org/pkg/encoding/asn1/]    We would not want to expose this API to chaincode writers, but may be ok to keep on the peer side and ensure bytes produced are always the same.         4) Consider custom serialization based on proto serialization rules. See FAB-11418 and FAB-11419.          "
Answer: 460848.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "If the removal of leader would cause the loss of quorum, raft protocol requires it to be connected after the removal, until other nodes commit this conf change. For more details, see Raft thesis 4.2.2 section.    when leader is being removed in a 2-node cluster, if communication leader is reconfigured too early before follower commits the config change, the system non-functional, even after reboot (because ex-leader finds it self not among consenters, therefore not started).    We should do following:  - On leader: transfer leadership when leader is removed/rotated, this should be retried till success. (It cannot service channel during/after this transition anyway)  - On Follower: wait for leadership transfer for a period of time, and configure communication. (it's fine not to wait indefinitely on followers, because at this point, it already picks up the config change  - When an orderer is started, it should still start the raft chain even if it's not among consenter set, when the last block is config block and removes itself.    First two are easy, but the third changes bootstrap logic considerably. Short term solution would be tackling FAB-14714"
Answer: 177360.0

User story: "Since, we are at v1.4, and this was introduced as 'production' release (or at least closer than previous releases) we have to compile our Fabric binaries for production too. This involves that, when compiling with GO, we must take into account the following details:   * Compile binaries without DWARF debugging information. We can *use the [{{-s}} and {{-w}} linker flags|https://golang.org/cmd/link/]* to strip the debugging info   * We may also want to use UPX style packers too    Check out this post for better understanding: [https://blog.filippo.io/shrink-your-go-binaries-with-this-one-weird-trick/]     "
Answer: 462874.0

User story: The CLI currently only supports signature policies when it should support both signature policies and channel config policy references.          Create new flags "signature-policy" and "channel-config-policy" (and remove the old, generic "policy" flag). 
Answer: 33249.0