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: Hyperledger Fabric currently uses version 1.0.0 of the spf13/Viper package and is currently locked at an older revision for managing Fabric's configuration files. We want remove the dependency on Viper and introduces a codified solution for managing network configurations.    Viper used to support case-insensitive keys, despite the YAML specification calling for case-sensitivity. In mid-2016 Viper adopted a case-sensitive model (specifically adopting lowercase keys) to re-align itself with the YAML spec, and now, when keys are read into Viper, its Getter methods, which return the data in the configuration files, now return maps, where subsets of data are only returned if their respective keys are lowercase in the configuration file.    While parts of Fabric follow both the YAML and Viper spec's, there are also several parts, namely the Orderer, which have keys defined in PascalCase. When newer versions of Viper are used, these keys, and their subsets are not parsed and do not become part of the configuration object. Simply changing the config files to all lowercase is not enough to address this, as parts of the code assume these keys are defined in their original PascalCase, and calls to the Viper configuration return no results as the case-sensitive keys no longer match. Viper is now permanently locked at its current version, unless we re-architect our current implementation across all of Fabric.    Also of note is, currently in Fabric, the configuration file tells the network what model it's configuration file represents. There is no mechanism in code to define what a "valid" configuration file is. This allows users to define keys and values in the files which Fabric does not otherwise provide a mechanism for support. It also allows developers to use Viper to add and store data in the configuration objects which are not part of a "valid" configuration.    Because of these breaking changes, and our need to define what a valid configuration is, the end goal of this story is to decouple Fabric from Viper, and provide our own codified solution for managing the configuration internally.    At the conclusion of this story the following work should be completed:   - Fabric should only support one naming convention for configuration file keys, and all existing calls should be configured as such   - Starting a network should generate TopLevel structs, that defines the structure of the individual elements of the network configuration. As the child structs are initialized they are added to the parent struct for future use   - Fabric should remove all calls to Viper and replace them with calls to the configuration structs   - All utilities built around Viper should be reconfigured to use the native configuration structs, simplified as much as possible, and removed where possible   - The Fabric build process should provide some mechanism for generating valid configuration file templates based on the codified configuration data structure   - This process should also provide some mechanism for generating comments in the template file for each key, providing information on what that key is for and it's attributes, such as whether it is optional   - This process should also provide a mechanism for admins to hide attributes that are generated in the templates, that are both optional, and not easily configurable by the lay user    Ultimately Fabric's configuration should be defined by the code, Viper should be removed, and the configuration should be consumed in a read-only manner
Answer: 158268.0