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: MSPPrincipal proto message as defined in the previous task is extended to include an additional classification type, e.g.,  {code:java}  // message MSPPrincipal {           enum Classification {          ROLE = 0;  // Represents the one of the dedicated MSP roles, the          // one of a member of MSP network, and the one of an          // administrator of an MSP network          PROPERTY = 1; // Denotes a finer grained (property-based)          // groupping of entities, per MSP affiliation          // E.g., this can well be represented by an MSP's          // Organization unit          IDENTITY  = 2;    // Denotes a principal that consists of a single          // identity          COMBINED = 3; // Denotes a combined principal      }           // Classification describes the way that one should process      // Principal. An Classification value of "ByOrganizationUnit" reflects      // that "Principal" contains the name of an organization this MSP      // handles. A Classification value "ByIdentity" means that      // "Principal" contains a specific identity. Default value      // denotes that Principal contains one of the groups by      // default supported by all MSPs ("admin" or "member").      Classification principal_classification = 1;           // Principal completes the policy principal definition. For the default      // principal types, Principal can be either "Admin" or "Member".      // For the ByOrganizationUnit/ByIdentity values of Classification,      // PolicyPrincipal acquires its value from an organization unit or      // identity, respectively.      bytes principal = 2;    }  {code}            Where classification “COMBINED” would lead principal to be deserialised as an array of principals.  {code:java}  // CombinedPrincipal governs the organization of the Principal    // field of a policy principal when principal_classification has    // indicated that a combined form of principals is required    message CombinedPrincipal {           // Principals refer to combined principals      repeated MSPPrincipals principals = 1;    }  {code}   
Answer: 189003.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: "Identity Mixer supports anonymous identities. Therefore, a way to tell apart anonymous MSP identities from nominal needs to be introduced.     In order to do so, the following method is introduced in the MSP Identity interface:    {code:java}   // Anonymous returns true if this is an anonymous identity, false otherwise   Anonymous() bool  {code}    The x509-based MSP Identities will always be nominal.    In order to allow the policy framework to reason about the anonymity of an identity, a new MSP Principal classification is introduced as follows:    {code:java}      enum Classification {          ROLE = 0;  // Represents the one of the dedicated MSP roles, the          // one of a member of MSP network, and the one of an          // administrator of an MSP network          ORGANIZATION_UNIT = 1; // Denotes a finer grained (affiliation-based)          // groupping of entities, per MSP affiliation          // E.g., this can well be represented by an MSP's          // Organization unit          IDENTITY  = 2;    // Denotes a principal that consists of a single          // identity                 ANONYMITY = 3; // Denotes a principal that can be used to enforce an identity to be anonymous or nominal.      }  {code}    When the ANONYMITY classification is used, the MSPPrincipal#Principal must be the serialisation of the following protobuf message:  {code:java}  // MSPIdentityAnonymity can be used to enforce an identity to be anonymous or nominal.  message MSPIdentityAnonymity {        enum MSPIdentityAnonymityType {          NOMINAL = 0; // Represents a nominal MSP Identity          ANONYMOUS = 1; // Represents an anonymous MSP Identity      }        MSPIdentityAnonymityType anonymityType = 1;    }  {code}  "
Answer: 189006.0

User story: "It makes life easier for Fabric operators if orderer parameters are printed at boot time"
Answer: 7734.0

User story: "Fabric supports vendor pkg in chaincode now.    Suggested by [~<USER>:    We will add some notes on vendoring steps in [https://hyperledger-fabric.readthedocs.io/en/release/chaincode4ade.html#housekeeping]."
Answer: 17174.0

User story: "Additional comments were made during review and need to be addressed.  See CR for details."
Answer: 181376.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 def/fabapi package currently has two responsibilities instead of one.    1) Creates default factories   2) Contains the SDK code that creates instances from the factories    The SDK code (2) should be a standalone package (like pkg/fabsdk); and def/fabapi simply injects its factories into that impl (1). This allows other curated package factories to exist under def (e.g., a default that uses a PKCS11 cryptosuite, for example) vs the current default that limits itself to sw.    Currently you couldn't do this properly since def/fabapi actually contain the SDK code... which ironically defeats the idea of a default directory.    The README should be updated to give SDK users guidance on what these two packages are for (and to start there). The GoDocs should also direct users to these packages and be fleshed out better for these two packages, in particular.    On a related (but separate) topic, individual clients should be created from their own packages with appropriate support from the SDK package (rather than the SDK containing constructors for each).      "
Answer: 59107.0

User story: "Add an additional test that verifies that at the ledger level, it is allowed to use an iterator and issuing deletes while iterating."
Answer: 96295.0

User story: "*Need*    Organizations CISO (Chief Information Security Officer) with strong PKI policies refuse to allow self-signed CA and derived certificates to sign transactions.    CISO would like to use their validated Certificate Authority Provider (CA Provider) and validated internal procedures and tools for management of Fabric Certificates.         *Problem*    Fabric MSP could trust CA Provider root certificate but it would end up trusting all certificates issued by the CA Provider.    Current Fabric version supports segregation of Clients, Peers and Orderer on the OU field and could be used for this purpose.    But the OU field cannot be validated by standard Certificate Issuance procedures.     *Proposal 1*         The O (Organization) field can have  [ETSI|https://portal.etsi.org/TBSiteMap/ESI/TrustServiceProviders.aspx] validation procedure.    The MSP config.yaml file could have filtering configuration on the O (Organization field) to enable limited trust of child certificates.    Please see the detailed description:    [^FAB-OrganizationFilter-20180103-3.pdf]         *Proposal 2*    Various restrictions could be applied on fields other than the O (Organization) field. This would enable restrictions by Departments, or force specific naming pattern.    The MSP config.yaml file could have filtering pattern on any Distinguished Name component to enable limited trust of child certificates.    Please see the detailed description:    [^FAB-DNFilter-20180103-3.pdf]       h3. *^Proposition Comparison^*    ^Proposal 1 is easy to do and to test but is not very configurable.^    ^Proposal 2 is more configurable and future-proof but require more testing and might lead to security holes if the regex are not properly crafted.^          "
Answer: 1079025.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: From the code sample in [hyperledger/education|https://github.com/hyperledger/education/tree/master/LFS171x/fabric-material] fabric-material, the _tuna-app_ uses _basic-network_. The basic-network has a file `generate.sh` which uses the `.yaml` files to generate the content inside `_config/*_` and `_crypto-config/*_`. The git repository for education as well as [fabric-samples|https://github.com/hyperledger/fabric-samples/tree/release/basic-network/crypto-config] contains the certificates already.    Ideally these should be generated via the generate.sh process using the cryptogen, configtxgen and other tools. Clearing out the content from the two directories and recreating the certificates works perfectly.    After creating the network and registering the Admin user and a demo user, a query to the chaincode results in an error unable to verify as the certificate was signed by an unknown authority.  {code:java}  sendPeersProposal - Promise is rejected: Error: Failed to deserialize creator identity, err the supplied identity is not valid: x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "ca.org1.example.com"{code}       In general these certs and data shouldn't be committed, Is there a reason why this is being done? Am I doing something wrong here?    With the default certificates in the commit, the application works just fine.     
Answer: 1079203.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 code duplication at the certificates sanitization code, e.g.:    {code}  func (msp *bccspmsp) sanitizeCert(cert *x509.Certificate) (*x509.Certificate, error) {   if isECDSASignedCert(cert) {    // Lookup for a parent certificate to perform the sanitization    var parentCert *x509.Certificate    if cert.IsCA {     // at this point, cert might be a root CA certificate     // or an intermediate CA certificate     chain, err := msp.getUniqueValidationChain(cert, msp.getValidityOptsForCert(cert))     if err != nil {      return nil, err     }     if len(chain) == 1 {      // cert is a root CA certificate      parentCert = cert     } else {      // cert is an intermediate CA certificate      parentCert = chain[1]     }    } else {     chain, err := msp.getUniqueValidationChain(cert, msp.getValidityOptsForCert(cert))     if err != nil {      return nil, err     }     parentCert = chain[1]    }      // Sanitize    var err error    cert, err = sanitizeECDSASignedCert(cert, parentCert)    if err != nil {     return nil, err    }   }   return cert, nil  }  {code}    following peace     {code}     chain, err := msp.getUniqueValidationChain(cert, msp.getValidityOptsForCert(cert))     if err != nil {      return nil, err     }  {code}    is repeated regardless of the if state condition. The sanitation check could be improved by simple refactoring to the following code:    {code}  func (msp *bccspmsp) sanitizeCert(cert *x509.Certificate) (*x509.Certificate, error) {   if isECDSASignedCert(cert) {    // Lookup for a parent certificate to perform the sanitization    var parentCert *x509.Certificate    chain, err := msp.getUniqueValidationChain(cert, msp.getValidityOptsForCert(cert))    if err != nil {     return nil, err    }      // at this point, cert might be a root CA certificate    // or an intermediate CA certificate    if cert.IsCA && len(chain) == 1 {     // cert is a root CA certificate     parentCert = cert    } else {     parentCert = chain[1]    }      // Sanitize    cert, err = sanitizeECDSASignedCert(cert, parentCert)    if err != nil {     return nil, err    }   }   return cert, nil  }  {code}    which preserves former logic, while avoids duplication."
Answer: 443.0

User story: "-FAB-6859- introduced V1_1_PVTDATA_EXPERIMENTAL    capability.  This work item adds it to the sample configtx.yaml    so that users know how to configure it."
Answer: 4213.0

User story: "This is a follow-up fix of -FAB-5319-    Right now the peer channel command has enabled the peer orderer TLS hostname override.    Similarly, the same thing should also be done with peer chaincode command"
Answer: 12516.0

User story: "The code for creating gRPC client connections is not consistent in the codebase.  There are utility functions across a few packages and some ugly ways of loading config via viper.    The goal for this task is to create a common gRPC client in the comm package which would be analogous to the existing comm.GRPCServer."
Answer: 13601.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 fabric baseimage tags the third party dependencies with base image tag at [https://github.com/hyperledger/fabric-baseimage/blob/master/Makefile#L128]         Whereas the fabric build pulls the third party images with PREV_TAG at [https://github.com/hyperledger/fabric/blob/master/Makefile#L118] which is built using PREV_RELEASE at [https://github.com/hyperledger/fabric/blob/master/docker-env.mk#L61]         Thus, the fabric-baseimage tags are not used in fabric build.         If we try to override the PREV_RELEASE in fabric build, the changelog will not be generated at [https://github.com/hyperledger/fabric/blob/master/Makefile#L225] because it uses PREV_VERSION variable.     "
Answer: 1090499.0

User story: "In current implementation, `peer` and `orderer` processes write all logs to `stderr`.    Even a user can redirect it to a file, it is better to provide an configuration option for writing logs to a user-specified file."
Answer: 2797.0

User story: "I find it confusing that any time an error occurs the usage/help message gets displayed, even when the error has nothing to do with how the peer command is being called.    Help messages are useful to communicate to the user the correct usage of a command when their input isn't conform to what is supported and cannot be interpreted. Displayed for any other error they simply mislead the user into believing they made a mistake in how they called the command when that's not the case.     "
Answer: 171332.0

User story: "The txid is currently computed as H(nonce || creator). This approach was chosen (among other reasons) to ensure that no two transactions could have the same txid. In particular, if H is a cryptographic hash function, two different creators cannot create two transactions with the same txid.    Theoretically however, Bob may force a txid collision on a txid from Alice (who uses cert_A as her creator certificate) as follows: Bob contacts its CA and attempts to generate a certificate cert_B that has as a suffix the bytes of cert_A (e.g. cert_B := prefix || cert_A) which is valid under its MSP. Then assume that Alice chooses a nonce N_A and creates    txid_A = H(N_A || cert_A)    Also assume that N_A := N_A' || prefix    Then Bob can pick as its nonce N_A' and force a collision on the txid since    H(N_A || cert_A) = H(N_A' || prefix || cert_A) = H(N_A' || cert_B)    This scenario is possible because we don't enforce any length checks on either field (nonce and creator). Note that Bob (who can naturally collude with its CA), may generate multiple certificates to increase his chances of success.    It is unclear whether it is actually possible to create this scenario in practice.    We propose to compute txid as H(H(nonce) || H(creator)). This approach follows security best-practices and would ensure that this theoretical scenario cannot occur."
Answer: 1096658.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: "Surprisingly enough the current documentation for contributors doesn't appear to contain any information about or even a single mention of our CI process. It merely includes a link to the main entry point at the top of the TOC.     "
Answer: 45670.0

User story: "The new tutorial on how to reconfigure your first network is a great addition because it fills in an important gap by answering the typical question people ask once they are done with the BYFN tutorial. However, following the new tutorial is strikingly more complex than following the BYFN tutorial. While this can be explained by the fact the process involved is indeed more complex it is also because very little help beside the documentation is provided.    We can make following the tutorial much easier by providing a script or set of scripts similar to the byfn.sh that people can use while following the tutorial and as a starting point for addressing their own specific use case."
Answer: 76406.0

User story: "Per comments in https://gerrit.hyperledger.org/r/#/c/16109/ we have some typos, but no reason to block progress.    This JIRA issue is opened as a reminder to fix the typos. "
Answer: 451.0

User story: "Nodes currently restrict to TLS to version 1.2 but we can also improve security a but by using HIGH encryption cipher suites by default.  My suggestion is:    {quote}  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,  TLS_RSA_WITH_AES_256_GCM_SHA256,  TLS_RSA_WITH_AES_128_GCM_SHA384  {quote}  "
Answer: 5339.0

User story: "The current error message prints as    Unsupported 'SignKey' provided [&{[237 8 193 7 146 17 154 244 196 115 53 125 171 228 43 181 103 186 160 174 24 107 63 97 39 6 161 237 249 128 193 94] 0xc42035ad60}]    Change it to display similar to:    Unsupported 'SignKey' provided [*ecdsaPublicKey]"
Answer: 1099131.0

User story: "RSCC constants API constants names are declared within {{aclmgmt}} package, which might potential bring the dependency cycle if anyone would try to refer those constant from other packages which for example depends on {{peer}} package. I'd suggest to refactor and extract those constant into separate package to mitigate the risk on dependency cycle creation."
Answer: 10243.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: "Since FAB-6911 exposed the {{ab.AtomicBroadacast}} service on peer in order to leverage it as a replacement for events service, namely to reuse {{Deliver}} API as source hub for block events. New implementation of {{AtomicBroadcast}} service has been added while the {{Broadcast}} API remained not implemented since this is not required for peer.    {code}  // Broadcast is not implemented/supported on a peer  func (s *server) Broadcast(srv ab.AtomicBroadcast_BroadcastServer) error {   return srv.Send(&ab.BroadcastResponse{    Status: common.Status_NOT_IMPLEMENTED,   })  }  {code}    while during the initialization broadcast handle still initialized and not used anywhere:    {code}  // NewAtomicBroadcastServer creates an ab.AtomicBroadcastServer based on the  // ledger Reader. Broadcast is not implemented/supported on the peer.  func NewAtomicBroadcastServer(timeWindow time.Duration, mutualTLS bool) ab.AtomicBroadcastServer {   s := &server{    dh: deliver.NewHandlerImpl(DeliverSupportManager{}, policies.ChannelReaders, timeWindow, mutualTLS),    bh: broadcast.NewHandlerImpl(nil),   }   return s  }  {code}    Therefore redundant initialization of {{bh: broadcast.NewHandlerImpl(nil),}} could be omitted."
Answer: 10434.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: "Some code is the msp package is un-used.  "
Answer: 8087.0

User story: "Since new API ledger API was introduced in order to support FAB-1151, e.g.     {code}   // CommitWithPvtData commits the block and the corresponding pvt data in an atomic operation   CommitWithPvtData(blockAndPvtdata *BlockAndPvtData) error  {code}    and production code path stopped to use previous {{Commit}} API, following code of the committer is no longer needed and could be removed:    {code}  // Commit commits blcock to into the ledger  // Note, it is important that this always be called serially  func (lc *LedgerCommitter) Commit(block *common.Block) error {   // Do validation and whatever needed before   // committing new block   if err := lc.preCommit(block); err != nil {    return err   }     // Committing new block   if err := lc.PeerLedger.CommitWithPvtData(&ledger.BlockAndPvtData{Block: block}); err != nil {    return err   }     // post commit actions, such as event publishing   lc.postCommit(block)     return nil  }  {code}    As well as following {{TODO}} labels in the committed code no more relevant, since resolved:    {code}   // TODO: Need to validate the hashes of private data with those in the block  {code}    and     {code}          // TODO: Need to create filter based on chaincode collections policies  {code}"
Answer: 12579.0

User story: "implement chain code deploy and upgrade"
Answer: 73055.0

User story: The method InitTLSForPeer falls back on an empty root CA cert pool if the config option isn't specified.    {code}   if config.GetPath("peer.tls.rootcert.file") != "" {    var err error    creds, err = credentials.NewClientTLSFromFile(config.GetPath("peer.tls.rootcert.file"), sn)    if err != nil {     grpclog.Fatalf("Failed to create TLS credentials %v", err)    }   } else {    creds = credentials.NewClientTLSFromCert(nil, sn)  }  {code}    It doesn't make sense to do that, since we don't have any way of trusting a remote node in such a case.     
Answer: 1065.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: PTE currently does not accept absolute paths in the user input files or service credential files.   Since some files (crypto-related files, service credentials) can be located outside GOPATH,   PTE should run correctly when absolute paths are specified.    Failed example for SC file path:  {noformat}  $ cat /tmp/benchmark.json  {      "SCFile": [          {              "ServiceCredentials": "/tmp/sc_testorgschannel1.json"          }      ],  (snip)  $ node pte-main.js 0 /tmp/benchmark.json 0 0  info: [PTE 0 main]: input parameters: Nid=0, uiFile=/tmp/benchmark.json, tStart=0 PTEid=0  info: [PTE 0 main]: Nid: 0, chaincode_id: sample_cc_testorgschannel1, chaincode_ver: v0  info: [PTE 0 main]: TLS: ENABLED  info: [PTE 0 main]: channelName: testorgschannel1  info: [PTE 0 main]: channelOrgName.length: 3, channelOrgName: Org2,Org3,Org1  info: [PTE 0 main]: svcFile;  /tmp/sc_testorgschannel1.json  /opt/gopath/src/github.com/hyperledger/fabric-test/fabric-sdk-node/test/PTE/pte-main.js:89  if ( typeof(ORGS.gopath) === 'undefined' ) {                  ^    TypeError: Cannot read property 'gopath' of undefined      at Object.<anonymous> (/opt/gopath/src/github.com/hyperledger/fabric-test/fabric-sdk-node/test/PTE/pte-main.js:89:17)      at Module._compile (module.js:570:32)      at Object.Module._extensions..js (module.js:579:10)      at Module.load (module.js:487:32)      at tryModuleLoad (module.js:446:12)      at Function.Module._load (module.js:438:3)      at Module.runMain (module.js:604:10)      at run (bootstrap_node.js:383:7)      at startup (bootstrap_node.js:149:9)      at bootstrap_node.js:496:3  {noformat}
Answer: 8277.0

User story: "Currently, MSP administrators are named one by one at configuration time. It might be convenient, in certain cases, to able to identifies MSP administrators by using the Organisational Units they belong to without have to name them explicitly. Therefore, we propose to enhance the MSP configuration to allow to specify an OU that identity the administrators of that MSP. Namely, we propose to add the following new protobuf message:    {code:java}  message FabricAdminOUs {      // If true then an administrators are identities by their OUs, otherwise they need      // to be named one by one.      bool   Enable = 1;        // OU Identifier of the clients      FabricOUIdentifier adminOUIdentifier = 2;  {code}    to FabricMSPConfig. At setup time, if FabricAdminOUs.Enable is equal True then the MSP will enforce only identities carries the specified OU will be considered administrators of that MSP, otherwise, the previous behaviour is enforced.    [~<USER>, [~<USER>, [~<USER>, [~<USER>, please, have you say :)  "
Answer: 832583.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: "Running `go test ./bccsp/sw` from current master takes around 35s. By enabling test parallelization in this package, the execution time is reduced to around 9s."
Answer: 31984.0

User story: "Need to document peer commands, including usages and flag details."
Answer: 52761.0

User story: In file fabric/gossip/service/eventer.go Line 59,    the "intialized" should be "initialized".
Answer: 3378.0

User story: "FAB-6868 adds a utility method that extracts the TLS cert hash from the channel header of an envelope, and then compares it to the TLS cert hash of a gRPC context.    Since we need to do that for the events (which don't use the same envelopes),  it makes no sense to implement this again for a new protobuf message type.    What we should ideally have is that utility to accept a function that extracts the TLS cert hash from the protobuf message, and then it can be reused for all our protocol messages."
Answer: 15427.0

User story: "In file fabric/common/channelconfig/applicationorg.go  Line 66, there is a comment describe the function of method   {code:java}  func (aog *ApplicationOrgConfig) AnchorPeers() []*pb.AnchorPeer  {code}  the comment says  {code:java}  // AnchorPeers returns the list of valid orderer addresses to connect to to invoke Broadcast/Deliver{code}  But the real function of this method is to return the list of Anchor peers of this Organization, so the comment is WRONG.    I modify the comment as below  {code:java}  // AnchorPeers returns the list of anchor peers of this Organization  {code}   "
Answer: 4332.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "FAB-7114 outlines a proposal to have the resource tree and LSCC, as per v1, to coexist.    Moved by the following motivation:    _Duplicating the same information in the resource tree and LSCC adds complexity that may lead to security bugs if the synchronization is not done properly or does not happen in an atomic fashion,_    we propose to modify FAB-7114 in the following way:    * To use the resource tree to store under /resources/chaincodes an entry for chaincode deployment policy in the channel, defaults for ESCC, VSCC, and VSCC arguments, and  to store the rest of the information in LSCC like it happens already  (V1.0).  This channel wide chaincode deployment policy will be used by LSCC at validation of LSCC deploy transactions.     *  To support multi-signer chaincode deployment policies, we also propose to introduce the multi-sig process à la Ethereum.  Namely, LSCC can be modified to collect signatures on a given instantiation proposal/transaction. The instantiation is marked as 'pending' as long as the channel's deployment policy and chaincode's instantiation policy are not satisfied.  As soon as the instantiation policy (bound to the relative chaincode) and the channel’s deployment policy  (bound to the relative channel) is satisfied (meaning that enough signatures have been collected on the same instantiation), LSCC validation considers the chaincode as 'instantiated' (No post-execution is required).   Even if unlikely in the case of a permissioned network, it might happen that different subsets of the administrators (able to instantiate the chaincode) try to instantiate the same chaincode with different inputs. Then, one strategy to deal with this is to say that the first group that satisfies the instantiation policy will automatically invalidate all the other pending (and possibly conflicting) proposals.    Please, find [here |https://docs.google.com/document/d/18xH9b0Ze8-b_OeLb40lnd-9QrqIAPDzpBneB3QInPLw/edit?usp=sharing] the design document with more details.    Please, [~<USER> [~<USER> [~<USER> [~<USER> [~<USER> [~<USER> [~<USER> [~<USER>[~<USER> [~<USER> [~<USER> [~<USER>, have your say :)"
Answer: 131205.0

User story: "Line ending in vendored license is causing merge conflicts for in-flight changes"
Answer: 1150.0

User story: "improve CONTRIBUTING so that it provides step-by-step for first CR"
Answer: 1900.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 will check the endorsement policy for every namespace that is being written to by a transaction. This means that if a transaction only reads from a namespace (i.e. the rwset is present for the namespace but no writes are there), the peer will skip the validation of the endorsement policy. The rationale is to permit a group of peers to perform read-only cc2cc invocations for a chaincode for which they couldn't generate a valid endorsement set.    However this might not be desirable, and we might want to   * either change this behaviour (i.e. force endorsement policy checks for read-only invocations too)   * or introduce a new notion of read-only endorsement policy    This FAB should be used to form consensus around either of these options (or new ones);"
Answer: 1111082.0

User story: "Integrating fabric-prototype to fabric-test"
Answer: 306649.0

User story: "The system behave framework needs to allow for the testing of config updates to a channel. This includes both system channel and application channel updates. In theory, there are 2 ways that a user would update a channel - using configtxlator and using the SDKs. The SDK implementations are not complete at the time of opening this issue, so the focus will be on using configtxlator.    The following are the possible updates that may occur on a channel:  * add an organization  * remove an organization  * add a policy (Different policies for system and application channels)  * modify a policy (Different policies for system and application channels)  * change batch size  * change channel restriction  * change orderer consensus type    Backend process:  * channel fetch of the block -> saved to a file (pb format)  * start configtxlator  * POST to configtxlator to convert to json  * Figure out what portion of the config data needs to be updated  * A diff between updated config and original config will be needed and sent to configtxlator in order to generate a new config block -> saved to file (pb format) (can we get json output instead so we don't have to convert back to json?)  * ??? POST to configtxlator to convert to json  * Add envelope headers  * POST to configtxlator to generate block file -> saved to a file (pb format)  * peers should sign the block  * channel should be updated with signed block    http://hyperledger-fabric.readthedocs.io/en/latest/channel_update.html"
Answer: 316869.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 I deployed Fabric Blockchains over Kubernetes, there was  problem which continuously persisted that, after the peers has joined the channel on Kubernetes, the next was to create a chaincode container which will carry out the transactions. Now, we can't control this chaincode container creation, and it will be created over docker itself.     So, what I want to suggest is, whatif we could control this part of Blockchain deployment, and provide a choice to deploy a chaincode POD in Kubernetes other than chaincode container in Docker. With this feature, the dependency to share docker endpoints with Kubernetes Peer Pods will be diminished. "
Answer: 868515.0

User story: Comment in fabric/gossip/state/state.go Line:706, should be "Select peer to ask for blocks" rather than "Select peers to ask for blocks", since it just selects one peer, so "peers" in this comment will be misleading. 
Answer: 165.0

User story: "In Makefile as of current master branch (c44491a74ad1dd751497c211a446189ec20cb8e3, 2017-12-08), `clean-all` target has redundant dependencies: `release-clean` and `unit-test-clean`. The first dependency, `clean` depends on these targets.    `Makefile`   {code}  .PHONY: clean  clean: docker-clean unit-test-clean release-clean   -@rm -rf build ||:    .PHONY: clean-all  clean-all: clean gotools-clean dist-clean release-clean unit-test-clean   -@rm -rf /var/hyperledger/* ||:  {code}  "
Answer: 3966.0

User story: "Now that the FileLedger's signaling logic no longer uses the ReadyChan() method and its underlying signal channel, the interface and implementations should be reworked to remove this function entirely.     Comments from the CR (https://gerrit.hyperledger.org/r/c/16009/) that led to this item, which cover the goals of this task:   1. Removes ReadyChan() from the blockledger/ledger.go interface -- it is not used anywhere anymore  2. Removes the implementation of ReadyChan() from the other ledger implementations, including the file ledger  3. Removes this fileLedger definition (https://gerrit.hyperledger.org/r/c/16009/3/core/peer/peer.go#66), and instead, simply creates a new FileLedger wrapper the ledger definition above anytime the Reader() call is invoked.  "
Answer: 361882.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 API should have been a replacement for the event hub service. It's lacking in at least two ways over this previous API. There is no means to know the services is ready and connected until it receives the first block. Current EH API first delivered as Status block with a success to make sure the connection is fully established and from the then on would start receiving blocks. This allowed SDK to easily make this synchronous.    Second this API does not offer an option to return the next block is sees added, but always returns the last block on the ledger regardless if that block may be a year old. This also has the consequences that if for example bad network connections result in reestablishment of the connection it will see that same block repeatedly if there were no new blocks added.    It was first suggested that to me that the SDKs should address these short comings. I don't think each SDKs should have to do this. I plan for the JSDK to expose it for what it is. Let applications deal with this behavior.    Given a chance to vote I'd go back to the old API as I think it was better suited for an eventing service. It only lacked one needed feature that would allow it to start receiving blocks from a specific block number."
Answer: 1117856.0

User story: "Right now cryptogen tool can only be used to initialize the crypto artifacts, however we have some requirements for adding new peer/orderer/user/org. To support that, we add a extend command to generate new artifacts on existing crypto directory."
Answer: 8527.0

User story: "Transactions of types common.HeaderType_CONFIG and common.HeaderType_PEER_RESOURCE_UPDATE should be:   * validated by the validator (in ./core/committer/txvalidator/validator.go)    * committed (if valid) after validation, following the pattern that exists for common.HeaderType_ENDORSER_TRANSACTION transactions    The current implementation is not consistent with respect to that. Indeed:   * common.HeaderType_CONFIG are validated and committed in ./core/committer/txvalidator/validator.go   * common.HeaderType_PEER_RESOURCE_UPDATE are neither validated nor committed in ./core/committer/txvalidator/validator.go    The approach should be aligned so that the code is modular and can easily be maintained."
Answer: 864736.0

User story: "The current peer code contains a check for compliance of the proposal against the `aclmgmt.LSCC_GETDEPSPEC` policy that is executed before a chaincode invocation is executed. This check is there because    * if cc lifecycle is in LSCC, LSCC is invoked to retrieve the deployment spec, and the check is inlined in the LSCC invocation   * if cc lifecycle is in the config tree, the check was introduced to mirror the legacy code path.    The purpose of this JIRA is twofold:   # remove the invocation of aclmgmt.LSCC_GETDEPSPEC if the cc lifecycle is in the config tree   # remove the invocation of aclmgmt.LSCC_GETDEPSPEC if the cc lifecycle is managed through LSCC    [~<USER>"
Answer: 1119426.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 sample delivery client for the orderer ([https://github.com/hyperledger/fabric/tree/release/orderer/sample_clients/deliver_stdout)] can be reused as-is to connect to the deliver service on a peer. However, it will be more user friendly if it is moved/copied into fabric/examples and has a few names changed to make it clear that it is compatible with the peer. It should also work with TLS enabled and have a readme to describe the basic functionality.     "
Answer: 193008.0

User story: "When the peer receives a bad status (i.e UNAVAILABLE) from an ordering service node that it connects to, it disconnects from it and tries another ordering service node.    FAB-5006 introduced an optimization for v1.1 that makes the peer *temporarily* black-list ordering service nodes that send a bad status (i.e UNAVAILABLE) in order for the peer to prioritize selection of other OSNs, instead of connecting to them with the same probability.         This might be problematic in cases where the OSNs are behind a LB/NAT where only 1 endpoint is actually known to the peer, but in practice - several endpoints exist behind.    This would result the peer in always disabling immediately *all* OSNs because it only knows 1 endpoint.         We can easily overcome this if we don't black-list an endpoint if it is the last one remaining."
Answer: 650.0

User story: "Document key concepts. Certain topics have some conceptual documentation in currents docs. These need to be improved.     *Current vision for topics include:*     *Identity    *Membership    *Peers    *Ledgers    *Orderers    *Chaincode/Smart Contracts    *Organizations    *Consortia    *Principals"
Answer: 906547.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 sarama client library embedded in the Kafka consensus implementation does not support Kafaka 0.11 or 1.0.    Actual fabric support of Kafka 0.11 or 1.0 to be determined as a separate issue (no issues expected)."
Answer: 9236.0

User story: Currently CC install API just returns SUCCESS with an the text String "OK" as bytes.  None of the current SDK I know actually looks at that string/byte.  They just validate it's SUCCESS.         The API should be be change add a byte encode protobuf.    This is more flexible and can be add to in the future.         For v1.1 it should have     message CCInstallResponse \{      string ID = 1;   // The ID aka hash for the CC.  }         old peer response could be check if it's just "OK" and release this needs to be ignored as the peer probably does not support the new CC life cycle.
Answer: 208779.0

User story: "As consortium admin/member, we may allow he get some network topology information, e.g.,   * Channels in the network, including creator, joiner, time, etc;   * Orgs in the network, and creating/joining channels, peers, chaincodes, etc.    The only way to provide such complete information can be from the orderer part.    Hence we may add some query API at orderer.         Welcome everyone to help drop ur thoughts, thanks!"
Answer: 1129845.0

User story: "Refer to [https://wiki.hyperledger.org/projects/fabric/proposedv1_1] and the New Feature JIRA blocking this.    Start by using fabric v1.0.* and fabric-SDK v1.0. *Ensure network is stable, secure, and able to correctly handle transactions while upgrading fabric SDK network component from v1.0.* to v1.1. Then upgrade the fabric to v1.1.    Also: repeat tests, first upgrading the fabric and then the fabric-SDK."
Answer: 871999.0

User story: "Introduce a proposed governance model wrt to new features/improvements to fabric system.         Acknowledgement:        originator: [~<USER>"
Answer: 1130571.0

User story: "The fabric-samples repo needs to be mounted into vagrant if it exists, just like fabric-ca and fabric-test.     "
Answer: 77389.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 development feature is still in development. It will affect v1.1, but the feature fix-version is not assigned to v1.2 yet, so for now this is just a placeholder and this test work can be deferred.    I am putting this in our v1.1 systest epic, but probably it will be moved to backlog or to v1.2 systest epic after one is created."
Answer: 876887.0

User story: "Recent decision: this is NOT a v1.1 feature.    FYI:  -Release 1.1 will be delivered with existing 1.0 lifecycle behavior. Target 1.1 Alpha in January.  -We do nothing to break clients in 1.1, or otherwise make fixing lifecycle more difficult for ourselves or painful for our users in the future.  -Fix a couple relatively minor security bugs in 1.1, which can be done without breaking applications.  -Implement the improved endorsement-based lifecycle with multi-sig in 1.2 (or potentially call that release 2.0 to indicate that there are changes)."
Answer: 876896.0

User story: "Some helpful env vars when testing:    - CORE_PEER_TLS_ENABLED=true  - CORE_PEER_TLS_CERT_FILE=/data/tls/server_wild_vme_sk_dev.pem  - CORE_PEER_TLS_KEY_FILE=/data/tls/server_wild_vme_sk_dev-key.pem  - CORE_PEER_TLS_ROOTCERT_FILE=/data/tls/ca_root.pem    - CORE_PEER_TLS_CLIENTAUTHREQUIRED=true  - CORE_PEER_TLS_CLIENTROOTCAS_FILES=/data/tls/ca_root.pem  - CORE_PEER_TLS_CLIENTCERT_FILE=/data/tls/client_fabric-dev.pem  - CORE_PEER_TLS_CLIENTKEY_FILE=/data/tls/client_fabric-dev-key.pem"
Answer: 879689.0

User story: "[https://gerrit.hyperledger.org/r/#/c/19945/] addresses all these subtasks testcases:   * FAB-7251   * FAB-7252   * FAB-7253   * FAB-7254   * FAB-7255   * FAB-7256   * FAB-7263   * FAB-7264   * FAB-7265   * FAB-7266   * FAB-7267   * FAB-7268   * FAB-7269   * FAB-7270   * FAB-7271   * FAB-7272"
Answer: 296051.0

User story: "Refer to [https://wiki.hyperledger.org/projects/fabric/proposedv1_1] and the New Feature JIRA blocking this.    First verify steps to upgrade fabric-CA by itself.    Next: by using fabric v1.0.* and fabric-CA v1.0.*, *Ensure network is stable, secure, and able to correctly handle transactions while upgrading fabric CA network component from v1.0.* to v1.1. Then upgrade the fabric to v1.1.    Also: repeat tests, first upgrading the fabric and then the fabric-CA."
Answer: 876934.0

User story: "There is a datatype defined in {{coordinator.go}}, which no longer in use and could be omitted:    https://github.com/hyperledger/fabric/blob/master/gossip/privdata/coordinator.go#L240    {code}  type dataSources map[rwSetKey][]*peer.Endorsement  {code}  "
Answer: 1416.0

User story: "This function returns chaincode endpoint and error. But we should do all the necessary checks of chaincode endpoint during the node start-up phase. Therefore there's no need to use a function to pass chaincode endpoint value."
Answer: 1132335.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 BCCSP sw and pkcs11 implementations are actually duplicate some ECDSA-related code and the MSP package is importing the sw package just to use these function as well.    We propose to mode this common ECDSA-related code under the bccsp/util package to streamline the use of it."
Answer: 2177.0

User story: "It may be useful to log the client's ip address in the endorser just like gossip or the orderer's deliver and broadcast services do."
Answer: 321.0

User story: "The orderer/common/util only contains 1 file (net.go) that contains only 1 function (ExtractRemoteAddress).    This function can be used by any gRPC service, and therefore its place should be in common/util    "
Answer: 324.0

User story: "You cannot currently run `go test github.com/hyperledger/fabric/core/comm` directly.  Unfortunately, there are a couple of tests which require the testenv.  "
Answer: 21563.0

User story: Currently, when chaincode is instantiated, the pulling of baseos is explicitly set to false.  We should add a new configuration option under the docker section which allows one to   force the pulling of baseos. By default, it is set to false which maintains current behaviour.    this change may help address situations where a base image is updated to patch vulnerabilities  and a peer cluster is using a generic tag for baseos such as "latest".
Answer: 14496.0

User story: "We've been using a model where we track the downloads for a given release with a specific bootstrap-<version>.sh script in the scripts/ directory. One for each release.    This could be improved if we simply made the version an argument and pass that in to a generic script, which would default to the current version.    Thus, we can have a single goo.gl short url for tracking all downloads that people can use to download any version we've published.     "
Answer: 7133.0

User story: Given I am a channel admin of channel "A"    And I have configured permissions to control block information    When a transaction is broadcasted in channel "A"    Then I wish for clients to be notified of the transaction in channel "A"    And receive block information based on the configuration               Acknowledgement:        originator: [~<USER>
Answer: 1139350.0

User story: "fabric and fabric-ca both currently use govendor for 3rd party dependency management.  While govendor has served it's purpose, there are other tools which should be evaluated.    [dep|https://github.com/golang/dep] seems to be the leading candidate to become the standard Go dependency mgmt tool so it should be the top alternative we consider."
Answer: 160382.0

User story: "Kakfa 1.0.0 is released, hope we can support it soon.     [http://www-us.apache.org/dist/kafka]"
Answer: 212947.0

User story: "Attempting to follow instructions at [http://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/devenv.html] may fail on macOS when running  {code:java}  make dist-clean all  {code}  if Libtool has not been installed. The doc should include Libtool under the prereqs."
Answer: 15446.0