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: "ConnectionEstablished messages are needed to be confirmed to having derived from members of a blockchain network. One way to authenticate such messages is that the peer checks the signature against all channel MSPs/readers. Another way would be that there is an automated way of updating some central MSPManager structure. Last but not least, we could allow for ConnectionEstablished messages go unauthenticated till the scope of the messages they include is revealed."
Answer: 22390.0

User story: "Within this item we target on enhancing MSPPrincipal validation function (SatisifesMSPPrincipal) with signature-based options. This would automatically enable us to support admin policies vs. admin identities within an MSP, and expose it to the developer leveraging MSP functionalities. "
Answer: 10202.0

User story: "We need documentation on good practices associated to MSPs and their use.  The mapping between an MSP and organization of the system, admin-policies, revocation lists, etc."
Answer: 103203.0

User story: "This item refers to the implementation to a policy of type MSP. This indicates policies defined within an MSP infrastructure for the latter to assess MSP reconfiguration rights/requests."
Answer: 1555796.0

User story: "Within this item we aim to offer the ability to support policies that authorize identities based on the organization units an identity belongs to.  This task can be broken down into the following parts:   - ensure that definition of MSPPrincipals using OrganizationUnit is sound   - implement the getOrganizationUnit method of MSP identities   - enhance the language we use to describe access policies to support organization-unit-based classification of MSP identities      "
Answer: 10747.0

User story: "A new version of the GRPC library was released - v1.1.x    Recommend that all of the SDKs for languages which use the C core update to this version.  That includes both NodeJS and Python SDKs"
Answer: 43619.0

User story: "* Since there is no system wide common time, we can use the timestamp of the submitted transaction for now (in the payload.header.ChannelHeader)."
Answer: 82363.0

User story: "GetHistoryForKey should indicate key deletions as well as key modifications."
Answer: 82363.0

User story: "For reference, see: https://github.com/hyperledger/fabric/blob/923bf3a8e774249344b09c535b726799aec865bd/core/chaincode/chaincode_support.go#L318"
Answer: 1557603.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: I am trying to port some chaincode from v0.6 to v1.0.  I am running my v1.0 tests against the recent Docker images from the Hyperledger Hackfest.  It seems that the ReadCertAttribute() method has moved from the usual "shim" package to "github.com/hyperledger/fabric/accesscontrol/impl".  However this package is not included in the chaincode base image and so this "impl" package and a couple of other required packages from the Hyperledger Fabric source needs to be vendored into the chaincode directory in order to deploy.    {code:none}  $ grep -R ReadCertAttribute .  ./accesscontrol/api.go: ReadCertAttribute(attributeName string) ([]byte, error)  ./accesscontrol/impl/chaincode.go://ReadCertAttribute is used to read an specific attribute from the transaction certificate, *attributeName* is passed as input parameter to this function.  ./accesscontrol/impl/chaincode.go://  attrValue,error:=stub.ReadCertAttribute("position")  ./accesscontrol/impl/chaincode.go:func (shim *AccessControlShim) ReadCertAttribute(attributeName string) ([]byte, error) {  ./examples/chaincode/go/asset_management_with_roles/asset_management_with_roles.go: callerRole, err := impl.NewAccessControlShim(stub).ReadCertAttribute("role")  ./examples/chaincode/go/asset_management_with_roles/asset_management_with_roles.go: callerAccount, err := impl.NewAccessControlShim(stub).ReadCertAttribute("account")  ./examples/chaincode/go/authorizable_counter/authorizable_counter.go: val, err := impl.NewAccessControlShim(stub).ReadCertAttribute("position")  $ tar tf build/goshim.tar.bz2 | grep accesscontrol  $  {code}  
Answer: 882115.0

User story: There is a general shortcoming in the current architecture related to the configuration of external paths.  Consider a yaml key like "foo.bar.path = path/to/foobar".  This pattern is currently used for things like x509 certificates, etc.  The problem is when any code tries to utilize the key using standard techniques (e.g. os.Open(viper.GetString("foo.bar.path")) this will only succeed if the path is relative to the $CWD of the peer binary.    This has generally worked to date because we were only supporting and operating with software built from and run within the fabric.git repository, where those paths happened to exist.  Fast forward to the near future when we want to install the peer and its config using Linux Standards Base-esq techniques (e.g. config in /etc, binary in /usr/bin, etc) and this quickly becomes awkward.  We could work-around things by setting the peer $CWD to the path of the configuration, but that is hacky.  A better solution is to formally support the notion of config-relative paths with a substrate layer that can be used throughout the code base.    for example:    func GetConfigPath(key string) (string, error)    where "GetConfigPath("foo.bar.path") would return "/etc/hyperledger/fabric/peer/path/to/foobar" if the config were located in /etc/hyperledger/fabric/peer and the key equated to "path/to/foobar".  Of course, absolute paths would be passed untouched.
Answer: 116596.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: Add basic performance tests to daily CI.  First add some "dummy" scripts, which will fail when invoked from Jenkins daily runs.  Then add all the actual test scripts as they are written; refer to testplan doc for details:  https://docs.google.com/spreadsheets/d/1_IdXCuYMKkqXr3Za0pVnFP3sP1jBcNbYnTJGV-nSkxI/edit#gid=1813008746  
Answer: 149775.0

User story: "Finalize error handlng, logging, tracing for v1."
Answer: 577363.0

User story: "Move the block storage related code from fabric/core/peer/ledger to /fabric/common package so that this can be reused by both Peer (for peer ledger) and Orderer (orderldeger)"
Answer: 4688.0

User story: As discussed at Hackfest, would be useful to have "fabric-documentation" component on JIRA for tracking documentation requests/bugs/improvements. "Quality" is misleading and may not be the most appropriate component.
Answer: 365558.0

User story: "As discussed at Fabric Documentation breakout at Hackfest...    On http://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/devenv/, attention is paid to Windows environments in some sections; however, all commands are listed with *nix conventions (variables as $variable instead of %variable%, native use of scp). It would be useful to expand these sections (Cloning the Fabric Project comes to mind) with Windows commands/utilities."
Answer: 1307801.0

User story: "The current configtx scheme is a collection of signed configuration items.  This has the benefit of being very flexible, allowing a submitter to collect signatures from one set of parties for one set of items, a second set of signatures from a second set of parties for a second set of items, and then glue them together, and submit a valid reconfiguration.    However, this flexibility comes at the expense of requiring more signatures, and the added complexity does not seem worth the added flexibility.  This CR moves the signatures to the envelope level, but maintains the per item policy evaluation."
Answer: 33115.0

User story: "Per FAB-1700 and FAB-1699, the chain hashing parameters are now included in the chain configuration.  However, for the v1 release it was not practical to actually utilize these values, so instead they are required at a fixed size until they can be implemented.    The chainconfig.Descriptor carries these values, but no one is currently consuming them.    This additionally includes implementing a Merkle tree for the block data structure."
Answer: 1562626.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "When the orderer container is unable to connect to the kafka broker containers (in this case the hostname was not resolving), the orderer panics after attempting to connect 20 times unsuccessfully.     While an exit after a critical error makes sense, it would be better if it were not a panic.    ```  orderer_1    | 2017-01-30 20:02:24.779 UTC [orderer/kafka] newChain -> DEBU 037 Starting chain with last persisted offset: -3  orderer_1    | 2017-01-30 20:02:27.779 UTC [orderer/kafka] newProducer -> DEBU 038 Connecting to Kafka cluster: [kafka1:9092 kafka2:9092 kafka3:9092]  ...  ...  orderer_1    | 2017-01-30 20:03:24.779 UTC [orderer/kafka] newProducer -> DEBU 04b Connecting to Kafka cluster: [kafka1:9092 kafka2:9092 kafka3:9092]  orderer_1    | panic: Failed to create Kafka producer: kafka: client has run out of available brokers to talk to (Is your cluster reachable?)  orderer_1    |   orderer_1    | goroutine 1 [running]:  orderer_1    | panic(0xa21e20, 0xc420381a20)  orderer_1    |  /opt/go/src/runtime/panic.go:500 +0x1a1  orderer_1    | github.com/hyperledger/fabric/orderer/kafka.newProducer(0xc4202dd0c0, 0x3, 0x4, 0x0, 0x9, 0x0, 0x1, 0xb2d05e00, 0xdf8475800, 0x0, ...)  orderer_1    |  /opt/gopath/src/github.com/hyperledger/fabric/orderer/kafka/producer.go:51 +0x5bd  orderer_1    | github.com/hyperledger/fabric/orderer/kafka.glob..func2(0xc4202dd0c0, 0x3, 0x4, 0x0, 0x9, 0x0, 0x1, 0xb2d05e00, 0xdf8475800, 0xc4202f5e00, ...)  orderer_1    |  /opt/gopath/src/github.com/hyperledger/fabric/orderer/kafka/orderer.go:58 +0x7d  orderer_1    | github.com/hyperledger/fabric/orderer/kafka.newChain(0xfeba40, 0xc4202e45a0, 0xfed9c0, 0xc4202e5ea0, 0xfffffffffffffffd, 0xc4202f8b50)  orderer_1    |  /opt/gopath/src/github.com/hyperledger/fabric/orderer/kafka/orderer.go:113 +0x2e7  orderer_1    | github.com/hyperledger/fabric/orderer/kafka.(*consenterImpl).HandleChain(0xc4202e45a0, 0xfed9c0, 0xc4202e5ea0, 0xc4202e96e0, 0x2, 0x2, 0x3, 0xc4202f5b80)  orderer_1    |  /opt/gopath/src/github.com/hyperledger/fabric/orderer/kafka/orderer.go:82 +0x67  orderer_1    | github.com/hyperledger/fabric/orderer/multichain.newChainSupport(0xc420318240, 0xc4203181a0, 0xc4202e8240, 0xfe4f00, 0x1029220, 0x1)  orderer_1    |  /opt/gopath/src/github.com/hyperledger/fabric/orderer/multichain/chainsupport.go:132 +0x565  orderer_1    | github.com/hyperledger/fabric/orderer/multichain.NewManagerImpl(0xfe51c0, 0xc420242680, 0xc4202e8240, 0xfe4f00, 0x1029220, 0x0, 0x0)  orderer_1    |  /opt/gopath/src/github.com/hyperledger/fabric/orderer/multichain/manager.go:128 +0x3cb  orderer_1    | main.main()  orderer_1    |  /opt/gopath/src/github.com/hyperledger/fabric/orderer/main.go:153 +0xd39  ```"
Answer: 70614.0

User story: "The unit tests require genesis materials for their chain, but this is currently a manual and hacky process.  This story is to fix this into a more automated flow."
Answer: 36419.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 ordering service parameters configured via core.yaml file, which includes information about orderers endpoints. This need to be changed to read endpoints information from the configuration transaction, moreover need to make sure to connect to the available orderer. In order to support this peer cli should introduce additional cli parameter to provide ordering endpoint."
Answer: 60099.0

User story: "As a matter of fact, we should also put some sanity check: we can only be asked to invoke LCCC or any normal chaincode, nothing else.."
Answer: 115861.0

User story: "Upon peer startup, if CouchDB is configured for state database, need to verify connection to CouchDB.  If can't connect to CouchDB provide a good error and halt peer startup.    Currently, it fails upon the first chain creation step:Creating KVLedger ledgerID=myc1.  Should check connection upon KVLedger provider creation."
Answer: 41152.0

User story: "Currently delivery client is created each time peer joins the channel, as a consequence peers opens new connection to the ordering service instead of re-using one which already opened.    Need to factor out the part of code which instantiate delivery client from the peer part into the gossip service, this especially makes sense in light of upcoming changes related to the gossip based per chain leader election.    "
Answer: 3382.0

User story: In trial environments, it is very difficult to update orderer configuration.  For example to change block cutting from 10s to 1s (might want to make this the default).    I had to update orderer.yaml, and then go through these instructions and recreate the chain:    Firehawk:hyperledger <USER> cd fabric/orderer/tools/  Firehawk:tools <USER> ls -l  total 0  drwxr-xr-x  3 <USER> staff  102 Jan 24 10:00 configtemplate  Firehawk:tools <USER> cd configtemplate/  Firehawk:configtemplate <USER> ls -l  total 8  -rw-r--r--  1 <USER> staff  1697 Jan 24 10:00 main.go  Firehawk:configtemplate <USER> go build   Firehawk:configtemplate <USER> ls -l   total 27536  -rwxr-xr-x  1 <USER> staff  14092908 Jan 28 13:47 configtemplate  -rw-r--r--  1 <USER> staff      1697 Jan 24 10:00 main.go  Firehawk:configtemplate <USER> ./configtemplate --help  Usage of ./configtemplate:    -outputFile string          The file to write the configuration templatee to (default "orderer.template")    Then:  cp orderer.template to $GOPATH/src/github.com/hyperledger/fabric/common/configtx/test
Answer: 57865.0

User story: "Address review comments in:  https://gerrit.hyperledger.org/r/#/c/4767/    Updates to logging and comments per Murali's feedback.    Change ExecuteQuery() to GetQueryResult() per Binh's feedback.    Fix handler.go result type (KV should be QueryRecord).    Tested that chaincode calls to GetQueryResult() work end-to-end."
Answer: 1648.0

User story: "See FAB-1349 for more."
Answer: 2298.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The current configuration tx scheme requires a global sequence number be specified.  This is problematic as a DoS attack vector if single signers are allowed for modification of items (like anchor peers, or MSP definitions).  It should be a relatively straightforward change to modify this to be MVCC+postimage to eliminate the DoS sequence number contention problem."
Answer: 61395.0

User story: "Because write access to config is scoped by configuration item, it does not make sense for all anchor peers to be writable by any organization.  Instead, we should have one configuration item per anchor peer, with a modification policy corresponding to that org."
Answer: 40143.0

User story: "There is an existing problem with syncing identity across channels.    # Application orgs cannot read the ordering system channel, so they cannot reasonably update their identity there.  # Application orgs cannot determine what channels they are a member of, so cannot easily script updates to their identity.  Further, because the identity may be at different levels and will definitely have different headers, one signature must be generated per channel.  # The orderer has no way to ensure that the MSP used in a channel creation request is up to date (except relative to the ordering system channel, which as already pointed out, is problematic to update).  # The orderer has no centralized place to get TLS certs from.  # The peer has no authoritative source for TLS certs or for local MSP data.  # If an application wishes to create a channel with an org they have no other channels with, it's not obvious how to retrieve their current MSP.    There are probably other benefits as well."
Answer: 1570871.0

User story: "{{mspConfigPath: /etc/hyperledger/fabric/msp/sampleconfig}} in core.yaml is causing grief to non-docker users who have to override this everytime. It is better to change standard docker-compose files to point to docker path than have users change the config every time (in core.yaml or as an ENV var)"
Answer: 118850.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 need a formal set of guidelines in regards to logging (e.g. what to log, what level to use for certain types of logging statements, what to use to set the log level for a module).    Some guidelines/tips to be included:    For Fabric developers:   * Don't use the fmt.Print functions for logging statements (CLI being an exception), use the logger for the file (or create a new one if the file isn't logging anything yet). See next point for syntax.   * All new logging.MustGetLogger() calls should instead use flogging.MustGetLogger(), which tracks logger module names defined in the system and allows for setting levels by regular expression and reverting all levels to the system's default (defined as the levels at the end of peer startup).   * To take advantage of setting log levels via regular expression (and for consistency), it is recommended to use a pattern of flogging.MustGetLogger("<module>/<submodule>").   * If in doubt of the general usefulness of a logging message to a majority of users, use logger.Debugf() to prevent flooding the logs with messages, especially if they are in code that is accessed often.   * Add an entry and exit logging statement for all major methods that includes any important entry/exit parameters:    {code:java}  logger.Debugf("Entry") // modify to include any input parameters  defer logger.Debugf("Exit")  {code}   * Don't hard-code the log level for a module logger; in most cases it should be inherited from the parent command's log level. If you desire to have it set differently from the parent command, set it to/create a new value in core.yaml or similar config file. We want to have a way to adjust the log level at startup without actually touching the code.   * For code running on a peer (after startup), you can use "peer logging setlevel <module-name> <log-level>" to dynamically set the logging level for a module. If you are unclear on what a module is, it's the name you pass when you create a logger, i.e. logging.MustGetLogger("<module-name>") and also the name that shows up in the log messages following the timestamp, e.g. 2017-02-09 00:05:53.532 UTC [ledgermgmt] initialize -> INFO 019 ledger mgmt initialized
Answer: 499549.0

User story: "The peer should include a facility to optionally display any docker container output upon request/configuration.  As it stands right now, runtime failures in docker containers are very difficult to diagnose."
Answer: 5243.0

User story: "Currently the DSL for policies has the following format    AND(A, B)    but it would be much more consumable if it were    A AND B    We should change the parser to at least accept the latter (and potentially also the former)"
Answer: 1572589.0

User story: "There is an inconsistency between type of GetAttributeProof ([]byte) and VerifyAttributes ([][]byte) in msp Identity interfaces. Both need to be []byte.  "
Answer: 8215.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 recent change to the makefile made Dockerfile outputs first class.  However, the build is seeing them as implicitly intermediate and therefore cleaning them up with other intermediates.  This is likely to cause undo churn for iterative builds.    The solution is to do something like:    .SECONDARY: build/image/%/Dockerfile"
Answer: 8067.0

User story: "At least one customer has asked for separate audit logs from the fabric.  The requirement is that we can produce an audit log that include at least the following actions: add/modify/delete user, deploy chaincode, create/modify/delete subchannel. They also want to include the start/stop node .    I opened this against quality squad, but it will hit multiple areas, so I can move or open additional Jira items as needed."
Answer: 1319260.0

User story: "At least one customer has asked for separate audit logs from the fabric.  The requirement is that we can produce an audit log that include at least the following actions: add/modify/delete user, deploy chaincode, create/modify/delete subchannel. They also want to include the start/stop node .    I opened this against quality squad, but it will hit multiple areas, so I can move or open additional Jira items as needed."
Answer: 1319259.0

User story: "We need a tool that parses strings like    outof(1, outof(1, 'org0.member'))    and converts them into policy objects that cauthdsl can handle."
Answer: 113279.0

User story: "Simplify boolean expression in kvledger"
Answer: 24061.0

User story: "Orderer traffic driver which acts as a manager, to drive the orderer functional tests, should launch the network with multiple configurations, start/stop the components of the network, send multiple broadcast transactions and receive deliveries, and retrieve results/counts/duration. Some tests can then be written and executed from CI."
Answer: 136981.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: "It is desirable to have a chaincode calls other chaincodes during simulation. Other chaincodes (callees) may be in the same channel or different channels with the caller. The call may be read-only (query) or write.    This feature can be very complex, especially when involving writes, which is quite similar to multi-phase commit in relational databases.     We will divide the work into 3 phases:  1) Read-only  2) Write on same channel  3) Write on different channels    h3. Phase 1: Read-only  A chaincode may call other chaincodes on any channels in the same transaction context, where each callee may return a [Response](https://github.com/hyperledger/fabric/blob/master/protos/peer/proposal_response.proto) object. The caller is responsible for interpreting the object in the chaincode logic, and this object is not part of the MVCC unless the caller chaincode writes it to the ledger (ie using putState). Since the call is within the same transaction context, the security check will be based on the transactor but against the callee's channel. So if the transactor doesn't have reader access to the callee's channel, the call will fail.    h3. Phase 2: Write on same channel  The callees establish their own individual rw-sets within the caller's transaction context, so committing this transaction will involve multiple chaincode's rw-sets on 1 MVCC check; that is, if exists any key-version check failure from any involved chaincodes, the whole transaction will fail.     h3. Phase 3: Write on different channel  In this case, we can't use the same transaction context since the w-sets are on different channels (ledgers). The caller has to create sub-transactions (aka child or nested transactions) on behalf of the transactor to record the rw-sets on each associated channel. However, since there are potentially multiple sub-transactions, we need a transaction monitor to atomically coordinate the commit -- either all fail or all succeed.      "
Answer: 1364384.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: "Make the kafka image we build conform to the 'standards' used in fabric for other images."
Answer: 682.0

User story: "Store the results of the most recent `CreateNextBlock()` and `WriteBlock()` calls in the mock `ConsenterSupport` structure so as to make these values easier to retrieve (and some tests easier to write).    "
Answer: 4993.0

User story: "The peer currently uses the dangerous and deprecated method of manually inspecting configuration blocks for configuration.  This has a multitude of security and correctness problems, but also produces a lot of redundant and unnecessary code.  The peer should be converted to utilize the existing configtx.Manager code which does proper configuration transaction validation and provides a simple interface for users of that configuration."
Answer: 17426.0

User story: "There are several components which spin up GRPC servers.  Now that we have the common GRPC server, it's time to replace all GRPC servers used in the fabric with this common component.    This will then allow us to proceed to having a common way of handling TLS as well"
Answer: 118571.0

User story: "In composite key, we have used (0x00) as key delimiter and (0x01) as the lastKeyIndicator. These two ascii code can be present in the chaincode name. In that case, we would have problems in constructCompositeKey() and splitCompositeKey). Hence, we need to introduce an escape character for these delimiters. Further, we need to escape the every occurrences of escape character already present in the chaincode name. "
Answer: 37699.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Add a configuration item which will let the peers know in `JoinChannel` which orderer addresses may be connected to."
Answer: 20045.0

User story: "A consensus implementation may need to read the ledger and extract metadata from it during operation (most likely when booting up).    As an example, the Kafka-based orderer, reads the offset of the last envelope it placed into a block *and* wrote to the local ledger, and uses that value to resume consumption of chain's partition."
Answer: 8548.0

User story: "Remove unused args, variables, methods"
Answer: 1584856.0

User story: "When chaincode is deployed, it fills the peer debug log with many megabytes of binary dumps, making it difficult to troubleshoot through the noise."
Answer: 918.0

User story: "The orderer debugging output is not as helpful as it ought to be, in particular it doesn't mention which policy is not being evaluated correctly, or that startup actually completes, etc.  This should be fixed."
Answer: 21502.0

User story: "This story is to start working on the tools necessary for admins to work with configuration transactions, not only creating them, but also inspecting and signing them.    There are four principal components to this issue.    1. Bidirectional proto <=> deep JSON translation:  This is at the heart of the issue, and provides both a human readable, and human editable version of the configuration.  Because the configuration embeds other message types, like {{Envelope}} it is most natural to make this a generic proto <=> deeply unmarshaled JSON.  This means that the output should, to the extent possible, contain no binary marshaled fields.  For instance, a {{Block}} should show nested {{Envelope}} messages in its data, and these messages should show {{Payload}} messages, which should in tern show the unmarshaled version of the {{Data}} field, etc.  Correspondingly, it is important that this mapping be able to be returned into the native proto form.  Note, that the bidirectional marshaling can preserve meaning only, not literal bytes, as proto marshaling is non-deterministic.    2. A Config + Config -> ConfigUpdate utility:  This will allow the user to submit an original config and a modified config to produce a config update.  This will combine naturally with (1), so that the user may view the configuration in a human readable way, edit it, compute the update, and then see the update in a human readable form.    3. A REST API which exposes (1) and (2).    4. A CLI which exposes (1) and (2)    Finally, we may wish to add one additional API to (3)/(4), namely the ability to submit a Config, a Config Update, and have the server do a simulation of the result (including any errors produced because of insufficient signatures, or bad form).    For those interested in getting a jump on interacting with the deep JSON representation, please see a (unusually verbose) config update message attached as output_pretty.txt."
Answer: 197833.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 Validate does not exactly do validation, it rather marks invalid transactions using the bitmap.  There's a case for renaming the method so that the new name conveys better what the method does.    [~<USER> : I've assigned this to you given that you created the interface, I didn't want to change the name w/o consulting you first."
Answer: 573057.0

User story: "core/common/ccprovider/ccprovider.go contains generic interfaces arguments and return values to avoid importing the chaincode package to reference CCContext. We should move CCContext into core/common/ccprovider/ to remove the generic interface ugliness"
Answer: 124968.0

User story: "Replace often used sequences/patterns throughout the tests with wrapper functions."
Answer: 472.0

User story: "A purely cosmetical change. Most of the logic in the `kafka` package resides in `main.go`. I want to avoid any connotations with `main` which in Go pretty much implies a binary, hence the rename to `orderer.go`, which is more expressive anyway."
Answer: 513.0

User story: "See Jason's the comments at [https://gerrit.hyperledger.org/r/#/c/3813/4/orderer/orderer.yaml@31]    Either change the units of the bytes size configuration properties to KB or MB, or figure out a way to let the user specify the units."
Answer: 4196.0

User story: "The orderer configuration items have been added one by one as needed, so some commonalities have been ignored, and some names are inconsitent or misleading.  This story is to normalize those names."
Answer: 25853.0

User story: "Setup Continuous Integration job to setup v1.0 below tests    - Create Cron job to run end-to-end tests  - Create Daily Job to run Automation tests suites of orderer, ledger, endorser tests  - Create Weekly Job to run Automation test suites of orderer, ledger, endorser tests"
Answer: 252184.0

User story: "Development of a new chaincode with complex transactions for driving performance tests"
Answer: 150819.0

User story: "* Drive concurrent end-to-end transactions using single chaincode with ccchecker tool  * Drive concurrent end-to-end transactions using multiple chaincodes with ccchecker tool"
Answer: 1590850.0

User story: "Generate a performance benchmark test for v1.0.  The test includes latency, stress, long run, concurrency run, complex etc."
Answer: 1311405.0

User story: "Make commit block method from rawledger interface to ledger interface"
Answer: 17419.0

User story: "The orderer is currently hackily copying code from the orderer bootstrapper to generate the new chain request.  This is not a real path, as this needs to be supplied by the orderer, this story should address that."
Answer: 2912.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 used to only be one peer binary which linked in all of the code.  However, in the v1 architecture, the orderer has been introduced, which means that certain components (like MSP, BCCSP, etc.) need to be linked by both the orderer and the peer.    Having the orderer link into {{fabric/core}} is dangerous because it might develop import cycles or pull in large amounts of code it didn't intend to.  This decreases build speed, increases testing time, and generally makes the code more difficult to understand.    Instead, we propose the following conventions.      * {{fabric/vendor}} # Used as it is today  * {{fabric/orderer}} # May link to anything in fabric/common, fabric/vendor, fabric/protos, and itself  * {{fabric/peer}} # May link to anything in fabric/common, fabric/vendor, fabric/protos, and itself   * {{fabric/protos}} # May not reference anything but itself   * {{fabric/common}} # May reference fabric/protos and itself    This is going to require a lot of cleanup across the codebase, but should be a significant improvement."
Answer: 656263.0

User story: "As [~<USER>said actually underlying interface need uint64, so change int, int64 to uint64 directly in struct, interface, args will reduce type conversion.    [~<USER>[~<USER>Any special case need notice?"
Answer: 324103.0

User story: "The deliver API will support signatures after FAB-1573, so it then needs to actually respect these signatures and only allow readers which are authorized by policy for a given chain."
Answer: 5758.0

User story: "The deliver message currently has no authentication associated with it.  Rather than invent yet another signing scheme, we should adapt the Envelope message to be used to send SeekInfo requests."
Answer: 5819.0

User story: "The error handling framework needs to be modified to allow easy internationalization of text in the future.     i18n4go (https://github.com/maximilien/i18n4go) seems like a good package to utilize for this. Does anyone have any other suggestions for packages to internationalize in Golang? Please add any comments/concerns below.     If the community agrees on this package, the work to prepare the error handling framework should primarily consist of getting rid of the concept of the error map as that will be handled by i18n4go and simply using a message string to store the error message.    Once that is done, we'll be set up for internationalization via i18n4go while also getting the benefits of the error handling framework (callstacks and error codes).    Wiki for the error handling framework (currently only updated for initial design - will be updated as current work is finalized):   https://wiki.hyperledger.org/error-handling"
Answer: 80561.0

User story: "The framework to filter incoming transactions exist, as does the framework to manage policies, but currently the filtering framework does no policy enforcement on incoming broadcast messages, this needs to be fixed."
Answer: 6043.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 would be a library that leverages at the chaincode side access to chaincode SHIM (transient-data) and the already implemented BCCSP to decrypt encrypted incoming (to the chaincode) data, and encrypt chaincode state data (uniformly across same chaincode executions)."
Answer: 397563.0

User story: "This item is associated to the update of CRLs of the COP based MSP.  This may be considered as part of the MSP reconfiguration aspects, or not. We need to discuss, conclude on this and implement what is needed for the decided method.    Discussion also among [~<USER>."
Answer: 54801.0

User story: "At new chain setup time, a peer is requested to parse a JoinChannel request that contains a chain genesis block. The peer then needs to process this genesis block, and use configuration items listed within it to setup the security context of that chain:  - the MSPManager of the chain consisting of the VerifierMSPs of all the organizations of the chain  - the chain readers/writers and admins of the chain to enforce chain access control    In this work item we require that this enablement is achieved with the use of Configuration Manager (work that [~<USER> has been working on)."
Answer: 14173.0

User story: "This work item relates to the integration of MSP functionality for identity validity, signature generation / verification to define and evaluate policies.     Infrastructure wise, policies are needed at endorsement phase/committment phase, at evaluation of reconfiguration blocks. This is a collaborative work with [~<USER>."
Answer: 10207.0

User story: "The goal os this FAB is to remove completely the package fabric/core/crypto and all its dependencies.   Call to cryptographic algorithms should be redirected to BCCSP. Configuration of the algorithms to be used and their parameters should be demanded to the component that uses them.        "
Answer: 14366.0

User story: "There are many duplicated codes in this package and IDE warning"
Answer: 26353.0

User story: "Currently while deploying new chaincode, there is no way to query for LCCC data, since chaincode is not deployed yet. This is chicken and egg problem, where there is solution proposed in FAB-1422. This item it to track the availability of general solution as it blocks/relates to FAB-1038."
Answer: 807198.0

User story: "1- Scheduled purge… cron job’esk calls delete for sensitive data value automatically according to policy sort of definition. Ex. Key associated that has timestamp associated, deleted post at this time. Schedule job and deletes appropriate transaction    2- delete explicitly call the delete of the sensitive data    Must have evidence of the deletion.     Relates to FAB-1151"
Answer: 439027.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 noted in https://gerrit.hyperledger.org/r/#/c/3279/5/bddtests/environments/orderer-1-kafka-1-tls/configureTLSForKafka.md@41    Currently using -keyalg RSA when creating the certs using for Kafka TLS bddtests. See if we can use EC instead. We would need to see how to do so for both keytool and openssl.     A possible starting point would be http://stackoverflow.com/questions/12303079/java-7-keytool-elliptic-curve-encryption"
Answer: 53815.0

User story: "update contributing.md"
Answer: 141153.0

User story: "In addition to seeing the history of key values, we should be able to see the full transaction details for every update to the key.  This will require defining a new transaction structure to be returned."
Answer: 1604427.0

User story: cchecker was introduced to test chaincode under concurrent invokes in https://jira.hyperledger.org/browse/FAB-1475. In addition to sending load concurrently, it also allows chaincode to be tested for consistency and correctness (did the ledger commits match expected state values ?) using a "shadow" CC validator (typically written by the chaincode developer or a tester). This helps to fix chaincode issues before production.    This story is for doing the following tasks to move the chaincode checker to the top level   * add logging support  * add UT for the ccchecker  * add documentation  
Answer: 411627.0

User story: https://gerrit.hyperledger.org/r/#/c/2365 adds protobuf support for Policies. We can now serialize those policies and store them with the LCCC at the time of with the deploy/upgrade of chaincode and use them at VSCC validation in the committer.    This will be done over several tasks  * accept a serialized policy and have the CLI send an at-least-1-signature  * have VSCC validate a tx using that policy  * have the CLI accept a "policy" to accept a complex policy 
Answer: 145630.0

User story: "From the list of gossip jira issues for possible tests, develop specific steps for generating behave tests.    *Output:* A list of scenario test cases/possible scenarios that will be discussed with a developer/owner, and identify test utilities needed. These test scenarios will be saved (and possibly reformatted) for use as the feature files.  "
Answer: 781706.0

User story: Go through JIRA and find what stories with the "fabric-peer", "fabric-baseimage", "fabric-devenv", "fabric-gossip", and "fabric-membersrvc" components and corresponding labels have been completed. (API tests will cover the SDK components, not behave/functional tests.)     Compare as to whether there are feature files and scenarios for each story if needed. (may not be in the hyperledger/fabric repository under the bddtests directory)  If it seems that a scenario is needed, write a general description of the scenario (not steps) and the associated owner/assignee of the story.  A scenario is a one line test description.    *Output:* A list of scenarios or possible scenarios that will be discussed with a developer/owner.
Answer: 7469.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: "Only hashes of transactions (that maintain confidentiality) reside to the public ledger and details associated to it."
Answer: 1622047.0

User story: Currently the "return" processing from chaincode is clouded on error paths  * is the error from chaincode or from the fabric ?  * if error from chaincode, is this a unexpected/infrastructure error (e.g, "cannot read file") vs business logic error ("invalid account # specified by user")  * if error from chaincode, should we proceed with endorsement or halt    Clearly, the return value from chaincode invocation has to be used to decide the above. However the current return value ([]byte, error) is ill-suited for interpretation. A simple, conventional, integer error code based approach will be more suitable implement this cleanly.    The proposal is to modify the return values for "Invoke" and "Init" interfaces with a Response structure with an errorCode in it.    So something like   {quote}  type Chaincode interface          Init(stub ChaincodeStubInterface) *Response*          Invoke(stub ChaincodeStubInterface) *Response*  {quote}    Where Response could be something like  {quote}  Response     retCode  int     payload    []byte  {quote}    The endorser can then decide treatment of response based on the retCode value where 0 < retCode <= 500 are reserved by fabric  * retCode == 0 || retCode == 200 => success and payload will be interpreted as response  * retCode > 500 => error, payload will be interpreted as error but will proceed to endorsement  * 0 < retCode <= 500 => error, payload will be interpreted as error and endorsement will fail    The work will affect all chaincodes :  system chaincodes and examples    [~<USER>,   [~<USER>,  [~<USER>, [~<USER>
Answer: 293703.0

User story: "Parameterizing `unit-test/run.sh` to optionally pass in the package(s) you want to test rather than running unit tests for the whole fabric will make local development and test more palatable    So generally I build and test all my changes natively on my host (i.e. I just run `go test` directly on my host system)  and then when things look good I then run `make unit-tests` locally (although I do forget sometimes) before submitted by patch for review    There are of course times when `go test` runs fine locally but then when run in the context of `make unit-tests` it fails for one reason or another.   `make unit-tests` takes a while to run so this is a pain (as others have stated).    So one thing I've been doing locally is modifying `unit-test/run.sh` locally to only run the unit tests for the package(s) I've changed to quickly ensure that things work."
Answer: 15742.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 test writer should be able to write feature tests using backend utilities to drive the tests such that any new test scenario can utilize the APIs while keeping the modification of the backend to a minimum.    *Output:* back-end utility functionality that drives the feature files. These utilities will include (but not limited to):    * docker_util    * remote_util   * grpc_util   * shell_util  "
Answer: 701325.0

User story: Go through JIRA and find what stories with the "fabric-endorsers" component have been completed. Compare as to whether there are feature files and scenarios for each story if needed. (may not be in the hyperledger/fabric repository under the bddtests directory)    If it seems that a scenario is needed, write a general description of the scenario (not steps) and the associated owner/assignee of the story.    A scenario is a one line test description.    Output: A list of scenarios or possible scenarios that will be discussed with a developer/owner.  
Answer: 8578.0

User story: "In order to allow for simple writing of feature tests, the behave backend should use common language for execution of steps for the feature files. Once the language is determined, the utilities can be written such that any new component can utilize the tests while keeping the modification of the backend to a minimum.    *Output:* Based on test steps generated, a standard language for feature file tests should be established that can be used across components. "
Answer: 181560.0

User story: Go through JIRA and find what stories with the "ledgers" label and "fabric-ledgers" component have been completed. Compare as to whether there are feature files and scenarios for each story if needed. (may *not* be in the hyperledger/fabric repository under the bddtests directory)    If it seems that a scenario is needed, write a general description of the scenario (not steps) and the associated owner/assignee of the story.    A scenario is a one line test description.    *Output:* A list of scenarios or possible scenarios that will be discussed with a developer/owner.   
Answer: 8622.0

User story: "Go through JIRA and find what stories with the consensus label and fabric-consensus component have been completed. Compare as to whether there are feature files and scenarios for each story if needed.     If it seems that a scenario is needed, write a general description of the scenario (not steps) and the associated owner/assignee of the story.  "
Answer: 8676.0

User story: "Catchup phase: Examine stories completed to date in each component area to identify missing feature tests, and work with developers to identify use-cases and write baseline feature file tests using gherkin language.     Backend utilities for functions that drive the feature files will be identified and written as needed.    Components for focused testing of configuration and operation may include (but may not be limited to) the following:  * COP  * Orderer  * Endorser   * Gossip  * MSP  * Peer  * Ledgers  "
Answer: 18900.0