+ Make the tests more portable and make more of them (improve testing and thus improving troubleshooting), this will include writing dummy tests for MegaDistro. + A general improvement of the code will occur as I go over it again, while working on it, as well as, by applying many of the new things I have learned over the course a year in the community. + The [main] MegaDistro configuration (currently handled in MegaDistro::Config), will be rewritten to use configuration, or "conf" objects. The currently set or default values will then be read from a configuration file, perhaps using the YAML format. After which, this same schema will be applied to the package-building configurations as well. * Eventually it may become unnecessary to have package-building or package-building specific configurations, at the very least they could all become part of one configuration file (the YAML format should be this relatively easy). + Create a schema, similar to the one mentioned for the MegaDistro configuration file, but use this to extend the MegaDistro modules list, such that it will incorporate a YAML-style listing, therefore allowing it to maintain [some] module or distribution specific configurations (e.g. a module which may require an external dependency may then be configured to bypass the tests which would otherwise cause it to fail, if the dependencies are not present, or, in which a given module could be specifically configured such that when tested passes specific information for the local test environment, bypassing any dependencies that may be otherwise required to satisfy the build-test process). * Implement the ability to have the MegaDistro software recursively satisfy dependencies, as opposed to specifying them, explicitly, and have all required dependencies included in the resultant package. This should be an option, perhaps a flag for it will exist in the MegaDistro configuration file. One good thing from last year's experience, working with such great people, mentors and peers, is that I was able to get in contact with the author of the CPANPLUS module (suite), which I heavily utilize in my software, I was then better able to guide my project along. Fortunately, as my software changes, so does CPANPLUS; I have made it a point to keep up with the changes and point out any issues or areas of interest I have or may have noticed while playing with certain aspects of it. Eventually, I hope for MegaDistro to be used to package many of the most-used modules to form a "megadistro" for mass-distribution. Moreover, separate predefined module-lists could be created, and categorically divided; e.g. a person could get the "megadistro" for Databases, and say, another one for Java.